<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">On Fri, Jun 14, 2019 at 8:36 PM Eli Friedman <<a href="mailto:efriedma@quicinc.com">efriedma@quicinc.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">> -----Original Message-----<br>
> From: Cameron McInally <<a href="mailto:cameron.mcinally@nyu.edu" target="_blank">cameron.mcinally@nyu.edu</a>><br>
> Sent: Friday, June 14, 2019 4:02 PM<br>
> To: Eli Friedman <<a href="mailto:efriedma@quicinc.com" target="_blank">efriedma@quicinc.com</a>>; LLVM Developers Mailing List <llvm-<br>
> <a href="mailto:dev@lists.llvm.org" target="_blank">dev@lists.llvm.org</a>><br>
> Cc: Craig Topper <<a href="mailto:craig.topper@gmail.com" target="_blank">craig.topper@gmail.com</a>>; Kaylor, Andrew<br>
> <<a href="mailto:andrew.kaylor@intel.com" target="_blank">andrew.kaylor@intel.com</a>><br>
> Subject: [EXT] Constrained integer DIV (WAS: Re: [llvm-dev] Planned change to<br>
> IR semantics: constant expressions never have undefined behavior)<br>
> <br>
> On Fri, Jun 14, 2019 at 6:24 PM Eli Friedman via llvm-dev<br>
> <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a> <mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> > wrote:<br>
> <br>
> I don't mean to steal your thunder, Eli, but I'd like to propose that<br>
> we add constrained intrinsics for integer DIV (and maybe REM). Some<br>
> architectures, like x86, can trap on integer div-by-zero. I'd like to<br>
> have some way to access that behavior, even if the C/C++ Standards say<br>
> it's undefined behavior.<br>
> <br>
> We have a few dusty deck codes in-house that depend on this, so I'm<br>
> motivated to push our local changes upstream. That said, if no one else<br>
> finds value in this, we can keep it local.<br>
<br>
Do you really need a special way to represent this in IR?  If you need a SIGFPE, the frontend can generate the equivalent of "if (x==0) raise(SIGFPE);", which is well-defined across all targets.  If you really need a "real" trap, I guess we could expose the x86 idiv as an intrinsic. <br></blockquote><div><br></div><div>A real trap would be preferred. I suspect that it would be difficult/expensive to set all the flags correctly (if that's even possible). E.g.:</div><div><br></div><div><div>#include <stdio.h></div><div>#include <signal.h><br></div><div><br></div><div>void handle_sigfpe(int fpe) </div><div>{ printf("Caught signal %d\n", fpe); }</div><div><br></div><div>int main (void) {</div><div>  signal(SIGFPE, handle_sigfpe);</div><div><br></div><div>#if TRAP</div><div>  int x = 1/0;</div><div>#else</div><div>  raise(SIGFPE);</div><div>#endif</div><div><br></div><div>  return 0;</div><div>}</div></div><div><br></div><div>In this pathological case, the RF flag differs so we'll see an infinite loop.</div></div></div></div></div>