<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">On Mon, Jun 17, 2019 at 4:05 PM Kaylor, Andrew <<a href="mailto:andrew.kaylor@intel.com">andrew.kaylor@intel.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">





<div lang="EN-US">
<div class="gmail-m_-2583249333543193925WordSection1">
<p class="MsoNormal">This is fundamentally different than the problems we’re trying to handle with the constrained FP intrinsics. The constrained FP intrinsics were necessary because LLVM IR otherwise assumes that FP instructions do not have side effects. In
 the case of integer divide-by-zero, the optimizer generally recognizes this as a possibility and avoids introducing it (through speculation, for instance). But if we’re optimizing it away as undefined behavior I guess that’s another story.</p></div></div></blockquote><div><br></div><div>Eli and I (and others) had this conversation about 5 years ago. I haven't dug through the C/C++ Standards (or drafts) since then, but I'll assume that not much has changed (someone please correct me if I'm mistaken). It's clear that the C/C++ Standards treat integer div-by-zero as undefined behavior. So the compiler can do whatever it wants with it (e.g self-immolation). And LLVM currently does whatever it wants. Here's InstSimplify for example:</div><div><br></div><div><div>  // X / 0 -> undef</div><div>  // X % 0 -> undef</div><div>  // We don't need to preserve faults!</div><div>  if (match(Op1, m_Zero()))</div><div>    return UndefValue::get(Ty);</div></div><div><br></div><div>Since X86 (IA-32/IA-64 IIRC) has a protocol for handling integer div-by-zero, I'd really like the compiler to leave it alone and let the hardware do what it will. I understand that this affects a very small part of the community, so I don't expect that to happen. But it would be nice if there was some way to access this behavior in an IEEE conformance mode.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div class="gmail-m_-2583249333543193925WordSection1">
<p class="MsoNormal">I’m not against introducing a way to handle that case, but I would be against making it look like the constrained FP intrinsics.</p></div></div></blockquote><div><br></div><div>It's not really that much different. We're trying to preserve a trapping side-effect, but it just happens to be integer and not FP. But yeah, I agree, it doesn't have to be rolled into the constrained FP intrinsics project.</div></div></div></div></div>