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

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

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>

----- 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
> 
-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory