
<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div>Hi all,</div><div><br></div>Thanks for your feedbacks.<div>My intuition did not follow the language semantic on undefined behavior :).</div><div><br></div><div>Cheers,</div><div>-Quentin<br><div><br><div><div>On Oct 19, 2014, at 9:43 AM, Sanjay Patel <<a href="mailto:spatel@rotateright.com">spatel@rotateright.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr"><div>Hi all -<br><br>Can we do more than just generate an undef to inform the customer that their program will go off the rails here? <br>A warning? An illegal instruction?<br>Is this better handled in the front-end or in the optimizers?<br><br>I filed <a href="http://llvm.org/bugs/show_bug.cgi?id=21093">http://llvm.org/bugs/show_bug.cgi?id=21093</a> for the related case of a broken libcall. <br><br></div><div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 17, 2014 at 8:11 PM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote"><span>On Fri, Oct 17, 2014 at 6:49 PM, Richard Smith <span dir="ltr"><<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span>On Fri, Oct 17, 2014 at 5:17 PM, Quentin Colombet <span dir="ltr"><<a href="mailto:qcolombet@apple.com" target="_blank">qcolombet@apple.com</a>></span> wrote:<br></span><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word">Hi Sanjay,<div><br></div><div>I do not think this change is correct.</div><div>I have attached a test case with (before.ll) and without (after.ll) that change and the related C file (test.c).</div></div></blockquote><div><br></div></span><div><span style="font-family: 'Courier New', Courier, monospace; font-size: 14px; white-space: pre-wrap;">signed short a = 8*8*8*548.54 - 3.14; // <-- the value of a is undef.</span><br></div><div><span style="font-family: 'Courier New', Courier, monospace; font-size: 14px; white-space: pre-wrap;"><br></span></div>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.</blockquote><div><br></div></span><div>I think it would be good to make the LangRef much more clear about this. I think "produces an undef value" is more concrete?</div><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> It would be correct to treat this as poison, not just as undef, from a language semantics perspective.</blockquote></span></div><div class="gmail_extra"><br></div>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.<br></div></div>

<br>_______________________________________________<br>

llvm-commits mailing list<br>

<a href="mailto:llvm-commits@cs.uiuc.edu" target="_blank">llvm-commits@cs.uiuc.edu</a><br>

<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>

<br></blockquote></div><br></div></div></div>

</blockquote></div><br></div></div></body></html>