[llvm-dev] Endianness for multi-word types

[Tim Shen via llvm-dev]

On Tue, Dec 1, 2015 at 11:52 AM Gao, Yunzhong <
yunzhong_gao at playstation.sony.com> wrote:

> Actually, I think the smart signbit here is not correct. For the fneg
> case, you need to
>
toggle the sign bits of both components of a ppc_fp128: negate(d1 + d2)
> should
> produce (-d1 - d2) instead of (-d1 + d2). It probably indicates that this
> pass is wrong
> for both big-endian and little-endian ppc64 targets, but existing test
> cases were not strong
> enough to catch such cases. For the fabs case, you can test positivity
> using only one
> signbit, but to negate the number, you still need to toggle both sign bits.
>

Sure, I didn't pay much attention on crafting the signbit.


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


> In that case it
> would be a better idea to handle the ppc_fp128 DAG combiner cases
> somewhere under
> llvm::PPCTargetLowering::PerformDAGCombine() instead of in the
> target-independent
> DAGCombiner.cpp,
>

It will work, but it seems doubling the maintenance for floating point
combiners. I wonder if there is any better solution to make both combiners
and endianness less painful - the problem sounds not as hard as what we
have now.

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? ISD::BITCAST itself doesn't swap the registers anymore. In such
case:
(exchange_hi_lo (ISD::BITCAST (fabs x)) is transformed to:
(exchange_hi_lo (and (ISD::BITCAST x) (not signbit)), which is correct. I'm
not sure if exchange_hi_lo exists or not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151201/398cf751/attachment.html>