RFR: 8283894: Intrinsify compress and expand bits on x86 [v2]
Jatin Bhateja
jbhateja at openjdk.java.net
Mon May 16 15:26:03 UTC 2022
On Mon, 16 May 2022 15:18:26 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:
>> src/hotspot/share/opto/intrinsicnode.cpp line 155:
>>
>>> 153: return new AndLNode(compr, src->in(1));
>>> 154: }
>>> 155: }
>>
>> I think a further rule for `compress(m, m)` could be in order.
>>
>>
>> compress(m, m) = m==-1 ? m : (1L << PopCount[IL](m))-1
>>
>>
>> This should be its own path through `Ideal`, not special logic at this particular point.
>>
>> Don't use it unless `Matcher::match_rule_supported(Op_PopCount[IL])` is true.
>
> This is a special case when both source and mask are same and we cannot take this call from C2Compiler::is_intrinsic_supported method. So currently if target does not support compress/expand bits then we do not create intrinsic in the first place.
>
>> Can you update the jtreg tests:
>>
>> 1. Modify `CompressExpandTest` to run with and without the intrinsic enabled
>> 2. Disable (by default) `CompressExpandSanityTest`
>> ?
>
> By disable you mean move it to ProblemList.txt.
> I think a further rule for `compress(m, m)` could be in order.
>
> ```
> compress(m, m) = m==-1 ? m : (1L << PopCount[IL](m))-1
> ```
>
> This should be its own path through `Ideal`, not special logic at this particular point.
>
> Don't use it unless `Matcher::match_rule_supported(Op_PopCount[IL])` is true.
This is a special case when both source and mask are same and we cannot take this call from C2Compiler::is_intrinsic_supported method. So currently if target does not support compress/expand bits then we do not create intrinsic in the first place.
-------------
PR: https://git.openjdk.java.net/jdk/pull/8498
More information about the hotspot-compiler-dev
mailing list