<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Tue, Dec 1, 2015 at 2:00 PM Tim Northover <<a href="mailto:t.p.northover@gmail.com">t.p.northover@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 1 December 2015 at 13:41, Tim Shen via llvm-dev<br>
<<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
> As a simple solution, when see a LLVM IR bitcast, instead of generating<br>
> (ISD::BITCAST x), can we generate (exchange_hi_lo (ISD::BITCAST x)) instead?<br>
<br>
An LLVM bitcast is defined to be equivalent to a store/load pair.<br>
Changing that for ISD::BITCAST would be very surprising, and  I<br>
wouldn't recommend it. It's a very useful invariant for reasoning<br>
about what should happen.<br>
<br>
When we had to work around similar endian nightmares in ARM I think we<br>
ended up creating AArch64ISD::NVCAST to represent a true nop cast.<br></blockquote><div><br></div><div>This works as well, so:</div><div>(bitcast (fabs x)) -> (exchange_hi_lo (and (nvcast x) (not signbit))).</div><div><br></div><div>Should I move AArch64ISD::NVCAST to ISD?</div></div></div>