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

Daniel Sanders via llvm-dev llvm-dev at lists.llvm.org
Wed Jan 13 03:49:15 PST 2016


> 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.


More information about the llvm-dev mailing list