RFR: 8320725: C2: Add "requires_strict_order" flag for floating-point add-reduction [v8]
Bhavana Kilambi
bkilambi at openjdk.org
Mon May 13 10:27:14 UTC 2024
On Mon, 13 May 2024 05:58:17 GMT, Emanuel Peter <epeter at openjdk.org> wrote:
>>> I just realized that there is no regression test. And I think it would be nice to have one.
>>>
>>> Also, we should add some sort of message to the `dump` if the `ReductionNode` has the `requires_strict_order` on or off. I think that could be done in `dump_spec`.
>>>
>>> You could do it similar to:
>>>
>>> ```
>>> #ifndef PRODUCT
>>> void VectorMaskCmpNode::dump_spec(outputStream *st) const {
>>> st->print(" %d #", _predicate); _type->dump_on(st);
>>> }
>>> #endif // PRODUCT
>>> ```
>>>
>>> This would actually allow you to create a IR test!
>>>
>>> You would check that the AddReductionVNode is annotated correctly. You need some VectorAPI tests, and some SuperWord auto-vectorization tests.
>>>
>>> How does that sound? That would ensure that nobody can easily destroy your RFE, at least not in the IR.
>>
>> Hi @eme64 , thanks for the suggestion. I can add the `dump_spec` as suggested (which would print if the `_requires_strict_order` flag is enabled/disabled) but I am not sure if I fully understand what's expected in the JTREG tests. Should I be verifying the `-XX:+PrintIdeal` output to make sure the correct message is being printed for the `ReductionV*` nodes?
>
>> I am not sure if I fully understand what's expected in the JTREG tests. Should I be verifying the -XX:+PrintIdeal output to make sure the correct message is being printed for the ReductionV* nodes?
>
> Yes, the IR framework basically does regex matching against the PrintIdeal graph. For example: `counts = {IRNode.STORE_VECTOR, ">0"}` in the `@IR` rule executes the regex for the store vector, and checks if we find more than zero occurances.
>
> Maybe you can just use a regex string directly for your special IR rule. Alternatively, you could have them in the `IRNode` class, but not sure that's worth it.
@eme64 Thanks for the clarification. I understand the usage of `counts` in the IR tests. Just that I got a bit confused by some of your earlier statements. We do actually have a test to make sure AddReductionVF/VD and MulReductionVF/VD are not generated on aarch64 NEON machines - `test/hotspot/jtreg/compiler/c2/irTests/TestDisableAutoVectOpcodes.java`. I can modify this test to include UseSVE > 0 case as well and will also add a separate JTREG test for the VectorAPI tests. Hope that's ok..
-------------
PR Comment: https://git.openjdk.org/jdk/pull/18034#issuecomment-2107199006
More information about the hotspot-compiler-dev
mailing list