Tim Northover via llvm-dev
2015-Dec-01 22:00 UTC
[llvm-dev] Endianness for multi-word types
On 1 December 2015 at 13:41, Tim Shen via llvm-dev <llvm-dev at lists.llvm.org> wrote:> As a simple solution, when see a LLVM IR bitcast, instead of generating > (ISD::BITCAST x), can we generate (exchange_hi_lo (ISD::BITCAST x)) instead?An LLVM bitcast is defined to be equivalent to a store/load pair. Changing that for ISD::BITCAST would be very surprising, and I wouldn't recommend it. It's a very useful invariant for reasoning about what should happen. When we had to work around similar endian nightmares in ARM I think we ended up creating AArch64ISD::NVCAST to represent a true nop cast. Cheers. Tim.
On Tue, Dec 1, 2015 at 2:00 PM Tim Northover <t.p.northover at gmail.com> wrote:> On 1 December 2015 at 13:41, Tim Shen via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > As a simple solution, when see a LLVM IR bitcast, instead of generating > > (ISD::BITCAST x), can we generate (exchange_hi_lo (ISD::BITCAST x)) > instead? > > An LLVM bitcast is defined to be equivalent to a store/load pair. > Changing that for ISD::BITCAST would be very surprising, and I > wouldn't recommend it. It's a very useful invariant for reasoning > about what should happen. > > When we had to work around similar endian nightmares in ARM I think we > ended up creating AArch64ISD::NVCAST to represent a true nop cast. >This works as well, so: (bitcast (fabs x)) -> (exchange_hi_lo (and (nvcast x) (not signbit))). Should I move AArch64ISD::NVCAST to ISD? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151201/6e79b3e5/attachment.html>
----- Original Message -----> From: "Tim Northover" <t.p.northover at gmail.com> > To: "Tim Shen" <timshen at google.com> > Cc: "Yunzhong Gao" <yunzhong_gao at playstation.sony.com>, "Hal Finkel" <hfinkel at anl.gov>, llvm-dev at lists.llvm.org, > "Nemanja Ivanovic" <nemanja.i.ibm at gmail.com> > Sent: Tuesday, December 1, 2015 4:00:15 PM > Subject: Re: [llvm-dev] Endianness for multi-word types > > On 1 December 2015 at 13:41, Tim Shen via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > As a simple solution, when see a LLVM IR bitcast, instead of > > generating > > (ISD::BITCAST x), can we generate (exchange_hi_lo (ISD::BITCAST x)) > > instead? > > An LLVM bitcast is defined to be equivalent to a store/load pair. > Changing that for ISD::BITCAST would be very surprising, and I > wouldn't recommend it. It's a very useful invariant for reasoning > about what should happen.Changing the semantics of ISD::BITCAST seems unfeasible.> I have a feeling that you will run into more cases in the DAG > combiner where you want > to add special handling codes for ppc_fp128, and I also feel that > this type is peculiar > enough that other backend owners upon trying to add more DAG combiner > passes are > likely to miss adding the special handling codes as they probably > should. > > > This is what I was worrying about. >This is a concern, but it is not new, nor unique to ppc_fp128. When writing code in DAGCombine (or any other part of the common code generator) you need to be aware of the requirements of parts of the IR used only by other targets. ppc_fp128 is not even the only custom FP type for which we have special handling (we have x86_fp80 too). While I agree that having some abstraction over these custom types could make things easier (if designed correctly), ppc_fp128 is part of the IR as it stands, and everyone needs to be aware of it when working with FP code that makes assumptions about the FP representation. Luckily, there are not actually a lot of such places. -Hal -- Hal Finkel Assistant Computational Scientist Leadership Computing Facility Argonne National Laboratory
----- Original Message -----> From: "Tim Shen" <timshen at google.com> > To: "Tim Northover" <t.p.northover at gmail.com> > Cc: "Yunzhong Gao" <yunzhong_gao at playstation.sony.com>, "Hal Finkel" <hfinkel at anl.gov>, llvm-dev at lists.llvm.org, > "Nemanja Ivanovic" <nemanja.i.ibm at gmail.com> > Sent: Tuesday, December 1, 2015 5:00:24 PM > Subject: Re: [llvm-dev] Endianness for multi-word types > > On Tue, Dec 1, 2015 at 2:00 PM Tim Northover < > t.p.northover at gmail.com > wrote: > > > On 1 December 2015 at 13:41, Tim Shen via llvm-dev > < llvm-dev at lists.llvm.org > wrote: > > As a simple solution, when see a LLVM IR bitcast, instead of > > generating > > (ISD::BITCAST x), can we generate (exchange_hi_lo (ISD::BITCAST x)) > > instead? > > An LLVM bitcast is defined to be equivalent to a store/load pair. > Changing that for ISD::BITCAST would be very surprising, and I > wouldn't recommend it. It's a very useful invariant for reasoning > about what should happen. > > When we had to work around similar endian nightmares in ARM I think > we > ended up creating AArch64ISD::NVCAST to represent a true nop cast. > > > > This works as well, so: > (bitcast (fabs x)) -> (exchange_hi_lo (and (nvcast x) (not > signbit))). > > > Should I move AArch64ISD::NVCAST to ISD?No; and how does this even help? As was pointed out, there are actually two sign bits to flip. -Hal -- Hal Finkel Assistant Computational Scientist Leadership Computing Facility Argonne National Laboratory