[llvm-dev] [GlobalISel] A Proposal for global instruction selection

[Philip Reames via llvm-dev]

You should also add test cases for both EarlyCSE and GVN which cover 
this case.  I had a patch I was working on for EarlyCSE just a couple of 
weeks ago which would have utterly broken this assumption.  I ended up 
rejecting it for other reasons, but still.

On 01/13/2016 06:34 AM, Hal Finkel via llvm-dev wrote:
> ----- Original Message -----
>> From: "James Molloy via llvm-dev" <llvm-dev at lists.llvm.org>
>> To: "Daniel Sanders" <Daniel.Sanders at imgtec.com>, "Quentin Colombet" <qcolombet at apple.com>
>> Cc: "llvm-dev" <llvm-dev at lists.llvm.org>
>> Sent: Wednesday, January 13, 2016 6:00:01 AM
>> Subject: Re: [llvm-dev] [GlobalISel] A Proposal for global instruction	selection
>>
>>
>> Ok, sounds good.
>>
> Hrmm... this however, could be considered a bug we should fix. Please add a comment in the relevant place to make sure no one "fixes" this.
>
>   -Hal
>
>> On Wed, 13 Jan 2016 at 11:49, Daniel Sanders <
>> Daniel.Sanders at imgtec.com > wrote:
>>
>>
>>> Hi Philip,
>>>
>>>> I think after reading your link I'm actually more confused. This
>>>> might just be a wording problem, but let me ask a couple of
>>>> clarifying questions.
>>> Sorry about that :( Every time I explain this I get slightly more
>>> embarassed because it is indeed weird and ugly (but was certainly
>>> the least ugly solution).
>>>
>>>> 1) After compiling the code sequence below (from that page), does
>>>> the in memory bit pattern differ? The page seemed to contradict
>>>> itself.
>>>> %0 = load <4 x i32> %x
>>>> %1 = bitcast <4 x i32> %0 to <2 x i64>
>>>> store <2 x i64> %1, <2 x i64>* %y
>>> Yes. The memory pattern differs. This is the first diagram on the
>>> right at: http://llvm.org/docs/BigEndianNEON.html#bitconverts )
>>>
>>>> If so, does this mean that performing dead-store-elimination is
>>>> illegal for ARM?
>>> Yes, for vector types whose corresponding load differs from the
>>> store type.
>>>
>>> %0 = load <4 x i32> %x
>>> store <4 x i32> %0, <4 x i32>* %x
>>>
>>> is still fine. I should go and check that DSE doesn't do bad things
>>> for big-endian NEON actually...
>> I just had a quick look and I think we're ok for this case at least.
>> DSE is checking that the value operand of the StoreInst is a
>> LoadInst. In this case it will be a BitCastInst and therefore the
>> StoreInst won't be deleted.
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>