search for: bigendianneon

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

...m.org> Sent: Wednesday, January 13, 2016 2:35:32 AM Subject: Re: [llvm-dev] [GlobalISel] A Proposal for global instruction selection Hi Philip, 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 ) I think that teaching the optimizer about big-Endian lane ordering would have been better. Inserting the REV after every LDR sounds very similar to what we do for VSX on little-Endian PowerPC systems (PowerPC may have a slight advantage here in that we don't need to do ins...

...bject: Re: [llvm-dev] [GlobalISel] A Proposal for global > instruction selection > > Hi Philip, > > > > > > 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 ) > > > I think that teaching the optimizer about big-Endian lane ordering > would have been better. Inserting the REV after every LDR sounds > very similar to what we do for VSX on little-Endian PowerPC systems > (PowerPC may have a slight advantage here in tha...

...; On 01/12/2016 05:55 AM, James Molloy via llvm-dev wrote: >> Hi, >> >> > I found this thinking quite difficult to explain. Does it make sense? >> >> It might help to link to the documentation on why bitcasts are weird on big-endian NEON: <http://llvm.org/docs/BigEndianNEON.html#bitconverts>http://llvm.org/docs/BigEndianNEON.html#bitconverts <http://llvm.org/docs/BigEndianNEON.html#bitconverts> >> >> Cheers, >> >> James >> >> On Tue, 12 Jan 2016 at 13:23 Daniel Sanders via llvm-dev <llvm-dev at lists.llvm.org <mail...

...;> > >> Hi Philip, > >> > >> > >> > >> > >> > >> 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 ) > >> > >> > >> I think that teaching the optimizer about big-Endian lane ordering > >> would have been better. Inserting the REV after every LDR sounds > >> very similar to what we do for VSX on little-Endian PowerPC systems > >&...

...osal for global >> instruction selection >> >> Hi Philip, >> >> >> >> >> >> 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 ) >> >> >> I think that teaching the optimizer about big-Endian lane ordering >> would have been better. Inserting the REV after every LDR sounds >> very similar to what we do for VSX on little-Endian PowerPC systems >> (PowerPC may have a slight...

Hi, > I found this thinking quite difficult to explain. Does it make sense? It might help to link to the documentation on why bitcasts are weird on big-endian NEON: http://llvm.org/docs/BigEndianNEON.html#bitconverts Cheers, James On Tue, 12 Jan 2016 at 13:23 Daniel Sanders via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi, > > > > I haven't found much time to look into the LLVM-IR-level optimizations yet > so I'm not sure how they handle bitcasts. With...

...Subject: Re: [llvm-dev] [GlobalISel] A Proposal for global instruction selection > > Hi, > > > I found this thinking quite difficult to explain. Does it make sense? > It might help to link to the documentation on why bitcasts are weird on big-endian NEON: http://llvm.org/docs/BigEndianNEON.html#bitconverts <http://llvm.org/docs/BigEndianNEON.html#bitconverts> > > Cheers, > > James > > On Tue, 12 Jan 2016 at 13:23 Daniel Sanders via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > Hi, > > I haven...

...>> > >> > >> > >> 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 ) > >> > >> > >> I think that teaching the optimizer about big-Endian lane > ordering > >> would have been better. Inserting the REV after every LDR > sounds > >> very similar...

...> > > >> > > >> > > >> > > >> > > >> 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 ) > > >> > > >> > > >> I think that teaching the optimizer about big-Endian lane ordering > > >> would have been better. Inserting the REV after every LDR sounds > > >> very similar to what we do for VSX on little-Endian P...

Hi Daniel, Thanks for the pointers, I wasn’t aware of the second thread you’ve mentioned. I may be wrong but I think LLVM-IR optimizations really treat bistcasts as no-op casts, in the sense of no instructions are required. Is there anyone that could chime in on that? However, it seems SelectionDAG sticks to the load/store semantic: "BITCAST - This operator converts between integer,