<div dir="ltr"><br><div class="gmail_quote"><div dir="ltr">On Tue, Oct 18, 2016 at 3:46 PM Hubert Tong via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">Can IR (with/without your proposal) differentiate between C's "trap representations" and "unspecified values"?<br class="gmail_msg"></div></div></div></div></blockquote><div><br></div><div>Poison, with and without this proposal, is a good model for C's "trap representations" IMO. If there is a discrepancy there, I would be surprised and suspect an error somewhere.</div><div><br></div><div>Without the proposal, an "unspecified value" is hard or impossible to produce in LLVM. Best idea I have is a volatile store of undef followed by a load. The problem is precisely what "freeze" in the proposal fixes -- we need some way to pick a *single* unspecified value. So with the proposal "freeze(poison)" will produce an unspecified value.</div><div><br></div><div>-Chandler</div></div></div>