Ok, sounds good.<br><div class="gmail_quote"><div dir="ltr">On Wed, 13 Jan 2016 at 11:49, Daniel Sanders <<a href="mailto:Daniel.Sanders@imgtec.com">Daniel.Sanders@imgtec.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> Hi Philip,<br>
><br>
> > 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.<br>
><br>
> 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).<br>
><br>
> > 1) After compiling the code sequence below (from that page), does the in memory bit pattern differ?  The page seemed to contradict itself.<br>
><br>
> > %0 = load <4 x i32> %x<br>
> > %1 = bitcast <4 x i32> %0 to <2 x i64><br>
> >      store <2 x i64> %1, <2 x i64>* %y<br>
><br>
> Yes. The memory pattern differs. This is the first diagram on the right at: <a href="http://llvm.org/docs/BigEndianNEON.html#bitconverts" rel="noreferrer" target="_blank">http://llvm.org/docs/BigEndianNEON.html#bitconverts</a>)<br>
><br>
> > If so, does this mean that performing dead-store-elimination is illegal for ARM?<br>
><br>
> Yes, for vector types whose corresponding load differs from the store type.<br>
><br>
> %0 = load <4 x i32> %x<br>
> store <4 x i32> %0, <4 x i32>* %x<br>
><br>
> is still fine. I should go and check that DSE doesn't do bad things for big-endian NEON actually...<br>
<br>
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.</blockquote></div>