[llvm-dev] how to simplify FP ops with an undef operand?

[Sanjay Patel via llvm-dev]

For reference, some patches based on this discussion:
https://reviews.llvm.org/D44258
https://reviews.llvm.org/D44216
https://reviews.llvm.org/D44308
https://reviews.llvm.org/D44318

Thanks to all for your help cleaning this up.


On Tue, Mar 6, 2018 at 2:27 PM, Stephen Canon <scanon at apple.com> wrote:

>
>
> On Mar 6, 2018, at 4:25 PM, Chris Lattner via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>
>
> On Mar 6, 2018, at 7:23 AM, Sanjay Patel via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> I need to review the last thread about undef/poison (or someone who knows
> current status of that can reply), but this would seem to come down to
> whether undef applies to the entire value or the individual bits?
> Ie, in your example the sign bit will never be set unless all of the
> exponent bits are also set. Each bit individually is unknown, but taken
> together we know that some sequences are impossible.
>
>
> The “on the ground” reason we made undef be a bit-level concept for
> integers was specific problems with C bitfields: when initializing a
> mem2reg’d bitfield, you end up doing or’s into undef values, and those bits
> have to be defined.
>
> I’m not aware of a similar concept that makes sense for fp values.  We
> could choose to do fine grain tracking (e.g. so ldexp and friends would
> work to set the exponent??) but I don’t see any practical reason for doing
> so.
>
>
> I agree. Tracking the signbit might be interesting sometimes, but it’s a
> second-order effect.
>
> – Steve
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180309/05819459/attachment.html>