This is an archive of the discontinued LLVM Phabricator instance.

[SelectionDAG] Support 'bit preserving' floating points bitcasts on computeKnownBits/ComputeNumSignBits
ClosedPublic

Authored by RKSimon on Oct 25 2017, 7:16 AM.

Details

Summary

For cases where we know the floating point representations match the bitcasted integer equivalent, allow bitcasting to these types.

This is especially useful for the X86 floating point compare results which return all/zero bits but as a floating point type.

Diff Detail

Repository
rL LLVM

Event Timeline

RKSimon created this revision.Oct 25 2017, 7:16 AM
efriedma added inline comments.Oct 25 2017, 11:26 AM
lib/CodeGen/SelectionDAG/SelectionDAG.cpp
2233 ↗(On Diff #120248)

Not sure why you're checking hasBitPreservingFPLogic; from its documentation, it specifically applies to the behavior of FABS/FNEG. BITCAST should always preserve all bits.

RKSimon added inline comments.Oct 26 2017, 3:45 AM
lib/CodeGen/SelectionDAG/SelectionDAG.cpp
2233 ↗(On Diff #120248)

@spatel might be able to give more details but I understood that hasBitPreservingFPLogic's scope was to cover all bit operations on floating point data? The FABS/FNEG are just explicitly mentioned as they're the typical uses of signbit masking/XORing.

I'm happy to simplify this if you think it safe.

spatel added inline comments.
lib/CodeGen/SelectionDAG/SelectionDAG.cpp
2233 ↗(On Diff #120248)

FABS/FNEG were the motivation for the hook (D19391), but it could apply to something other than that, so I should improve that comment.

I don't know anything about the targets that inspired the hook, so I'd feel safer keeping the check. (cc @escha @scanon
).

Bitcast works "as if the value was stored to memory with one type and loaded from the same address with the other type." That doesn't imply that bits must be preserved? Eg, I could imagine something like any NAN bit pattern getting set to a fixed NAN value by the hardware.

efriedma edited edge metadata.Oct 26 2017, 12:47 PM

In IR, we generally assume a store+load preserves the exact bit-pattern (for example, GVN depends on this). I guess that could be wrong if we lower a "load" instruction to an x87 "fld" (which transforms SNaN->QNaN), but as as far as I know no other architecture has that particular quirk.

The hasBitPreservingFPLogic hook is supposed to detect cases where fneg is lowered to a floating-point subtraction; it has nothing to do with any property of the underlying registers.

RKSimon updated this revision to Diff 120586.Oct 27 2017, 6:49 AM

Drop hasBitPreservingFPLogic

This revision is now accepted and ready to land.Oct 27 2017, 3:49 PM
This revision was automatically updated to reflect the committed changes.