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

[Hal Finkel via llvm-dev]

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