[llvm-dev] Endianness for multi-word types

[Hal Finkel via llvm-dev]

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