RFR: 8320725: C2: Add "requires_strict_order" flag for floating-point add-reduction [v5]

Bhavana Kilambi bkilambi at openjdk.org
Mon Apr 15 10:56:47 UTC 2024


On Mon, 15 Apr 2024 06:58:32 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/aarch64_vector.ad line 2861:
>> 
>>> 2859:   // example, this rule can be reached from the VectorAPI (which allows for non-strictly ordered
>>> 2860:   // add reduction).
>>> 2861:   predicate(Matcher::vector_length(n->in(2)) == 2 && !n->as_Reduction()->requires_strict_order());
>> 
>> Would it make sense to change `reduce_add2F_neon` to something like `reduce_non_strict_order_add2F_neon`, just so that it is a bit clearer when one reads the opto-assembly output?
>
> Similarly, I would put `strict_order` for the cases where that applies.

Hi, thank you for your comments. I will make these changes in the next PS. Maybe it's a good idea to add "non_strict_order" as not everyone might check the ad file to read comments and for a quick glance in an opto assembly output for example, it might be helpful to understand what these instructions mean.

>> src/hotspot/share/opto/vectorIntrinsics.cpp line 1739:
>> 
>>> 1737:   Node* init = ReductionNode::make_identity_con_scalar(gvn(), opc, elem_bt);
>>> 1738:   Node* value = opd;
>>> 1739: 
>> 
>> Suggestion:
>> 
>> 
>>   assert(mask != nullptr || !is_masked_op, "Masked op needs the mask value never null");
>
> This would restore the assert mentioned above.

Thanks. Makes sense. I will update this in the next PS.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18034#discussion_r1565582824
PR Review Comment: https://git.openjdk.org/jdk/pull/18034#discussion_r1565586373


More information about the hotspot-compiler-dev mailing list