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