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

[James Molloy via llvm-dev]

Ok, sounds good.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160113/78ab917d/attachment.html>