[llvm-dev] Endianness for multi-word types
Hal Finkel via llvm-dev
llvm-dev at lists.llvm.org
Tue Dec 1 15:20:21 PST 2015
----- 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
> 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
> 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.
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory
More information about the llvm-dev