RFR(S): 8136473: failed: no mismatched stores, except on raw memory: StoreB StoreI

[Berg, Michael C]

Roland I had a look too, the code looks good.

-Michael

-----Original Message-----
From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Roland Westrelin
Sent: Monday, September 21, 2015 2:03 AM
To: hotspot compiler
Subject: Re: RFR(S): 8136473: failed: no mismatched stores, except on raw memory: StoreB StoreI

Thanks for the review, Vladimir.

Roland.

> On Sep 21, 2015, at 3:32 AM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
> 
> This is good. Thank you for extending the test.
> 
> Vladimir
> 
> On 9/18/15 11:03 PM, Roland Westrelin wrote:
>>>>> Hmm, so you just relaxed the assert. You may need to fix EA too because it also checks for matching types(memory sizes).
>>>>> I remember we had problem with RAW accesses back when jsr292 was implemented. So EA gave up on RAW access and marks allocations as escaping. Also may be superword/vectorization will be affected.
>>>>> 
>>>>> In general it is very bad for C2 to have different memory on the same non-RAW memory.
>>>> 
>>>> It already happens with vectorization. Do you see another solution (rather than relaxing the assert)? Putting a MemBarCPUOrder before and after the unaligned store?
>>> 
>>> MemBarCPUOrder are definitely will help and it is simplest solution but, I think, it is too drastic.
>>> It affect control flow and other memory slices.
>>> We can try to mark such memory accesses or/and mark objects which have such accesses (if it is possible) and prevent vectorization and scalarization for them only.  We should be able execute optimization on other memory slices then.
>> 
>> Here is a new change:
>> 
>> http://cr.openjdk.java.net/~roland/8136473/webrev.01/
>> 
>> Unaligned accesses are explicitly marked as such.
>> 
>> I added a test case with a non escaping allocation and it works fine. I also added test case with vectorization and if the accesses are effectively unaligned vectorization doesn't happen. One of the test cases causes an assertion to fire when the allocation is expanded: the logic in InitializeNode::complete_stores() is confused by the unaligned store so I made sure unaligned stores are not captured by the initialization.
>> 
>> Roland.
>>