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