[9] RFR (S): 8152179: C2: Folding of unsigned loads is broken w/ @Stable

[Vladimir Ivanov]

On 3/24/16 2:15 AM, Vladimir Kozlov wrote:
> I don't understand changes in is_mismatched_access(). It does not
> guarantee/check that loads have masking. If there are no masking then
> short[] and char[] loads should mismatch. Right?
There's no way to distinguish between a mismatched access and a load 
fused w/ a mask, except MemNode::is_mismatched_access() flag. And it is 
set for mismatched accesses in LibraryCallKit::inline_unsafe_access().

fold_stable_ary_elem() call is guarded by 
MemNode::is_mismatched_access() and is_mismatched_access() is used only 
from fold_stable_ary_elem() which does the masking.

But I decided to refactor the code:
   http://cr.openjdk.java.net/~vlivanov/8152179/webrev.01

Do you find it clearer?

Best regards,
Vladimir Ivanov

> On 3/23/16 9:56 AM, Vladimir Ivanov wrote:
>> http://cr.openjdk.java.net/~vlivanov/8152179/webrev.00/
>> https://bugs.openjdk.java.net/browse/JDK-8152179
>>
>> Byte and short loads with small masks are converted to unsigned loads.
>> Constant folding logic for array elements doesn't respect unsigned
>> loads and replace them with signed values.
>>
>> It usually happens when a small mask is applied to the value produced
>> by a signed load (see AndINode::Ideal [1]):
>>
>>    byteArr [i] & 0x000F;  // AndI (LoadB 0x000F) => AndI (LoadUB 0xF)
>>    shortArr[i] & 0x000F;  // AndI (LoadS 0x000F) => AndI (LoadUS 0xF)
>>
>>    byteArr [i] & 0x00FF;  // AndI (LoadB 0x00FF) => LoadUB
>>    shortArr[i] & 0xFFFF;  // AndI (LoadS 0xFFFF) => LoadUS
>>
>> Field loads aren't affected since they are constant folded during
>> parsing.
>>
>> Testing: regression tests, hotspot/compiler/stable, JPRT
>>
>> Thanks!
>>
>> Best regards,
>> Vladimir Ivanov
>>
>> PS: while experimenting with the fix, I found that constant folding of
>> @Stable loads doesn't always happen. Filed 8152590 [2].
>>
>> [1]
>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/d9d0a63499ce/src/share/vm/opto/mulnode.cpp#l483
>>
>>
>> [2] https://bugs.openjdk.java.net/browse/JDK-8152590