[llvm] r219542 - Return undef on FP <-> Int conversions that overflow (PR21330).

[Quentin Colombet]

Hi all,

Thanks for your feedbacks.
My intuition did not follow the language semantic on undefined behavior :).

Cheers,
-Quentin

On Oct 19, 2014, at 9:43 AM, Sanjay Patel <spatel at rotateright.com> wrote:

> Hi all -
> 
> Can we do more than just generate an undef to inform the customer that their program will go off the rails here? 
> A warning? An illegal instruction?
> Is this better handled in the front-end or in the optimizers?
> 
> I filed http://llvm.org/bugs/show_bug.cgi?id=21093 for the related case of a broken libcall. 
> 
> 
> On Fri, Oct 17, 2014 at 8:11 PM, Chandler Carruth <chandlerc at google.com> wrote:
> 
> On Fri, Oct 17, 2014 at 6:49 PM, Richard Smith <richard at metafoo.co.uk> wrote:
> On Fri, Oct 17, 2014 at 5:17 PM, Quentin Colombet <qcolombet at apple.com> wrote:
> Hi Sanjay,
> 
> I do not think this change is correct.
> I have attached a test case with (before.ll) and without (after.ll) that change and the related C file (test.c).
> 
> signed short a = 8*8*8*548.54 - 3.14; // <-- the value of a is undef.
> 
> This line has undefined behavior; both C and C++ are very clear about this. The transformation is correct at the language semantics level. And it appears correct at the IR level too, whether you interpret "the results are undefined" as meaning undefined behavior or (strictly weaker) an undef value.
> 
> I think it would be good to make the LangRef much more clear about this. I think "produces an undef value" is more concrete?
>  
> It would be correct to treat this as poison, not just as undef, from a language semantics perspective.
> 
> I don't think there is any utility in thinking about poison here.... undef seems a good way to model this. I'm increasingly of the opinion we can all the optimizations we would ever want from undef alone.
> 
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20141020/305de1f1/attachment.html>