[PATCH] SelectionDAG: fold (fp_to_u/sint (u/sint_to_fp val)) when possible

[Chandler Carruth]

On Mon, Feb 9, 2015 at 2:44 PM, Mehdi Amini <mehdi.amini at apple.com> wrote:

> On Feb 9, 2015, at 2:26 PM, Quentin Colombet <qcolombet at apple.com> wrote:
>
>
> For the instcombine part:
>
> + if (FITy->getScalarSizeInBits() > SrcTy->getScalarSizeInBits())
> Shouldn’t we have some checks on the DstTy as well?
>
> e.g., what happens with:
> sitofp i32 to float
> fptoui float to i8
>
>
> We shouldn’t be able to simplify that with a s/zext, do we… Or maybe we
> can because it is undef??
>
>
> First not all i32 can fit in a float, it is checked in the outer enclosing
> test.
> Let’s consider instead:
>
> sitofp i16 to float
> fptoui float to i8
>
> The result is defined only for input value that will fit in the i8
> (Language Ref: " If the value cannot fit in ty2, the results are
> undefined.).
> If that mean that we are allowed to do the transform, then we have to
> generate a trunc right?
>
> It means also that we don’t really care checking that the input integer
> size can be represented in the floating point type since the same language
> reference quote applies, i.e. :
>
> sitofp i128 to float
> fptoso float to i128
>
> can be turned into a no-op.
>
> Chandler or someone else familiar with the details of InstCombine might be
> able to shed some light on what is / isn’t allowed to do when the language
> ref. talk about “undefined” results.
>

I think "undef" is the right thing to use when you have proven that the
operation has an undefined result.

If you're just using 'trunc' and not caring about the values discarded
because they would have resulted in undef, that also seems fine.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150209/474896ca/attachment.html>