[llvm-dev] Constrained integer DIV (WAS: Re: Planned change to IR semantics: constant expressions never have undefined behavior)

[Kaylor, Andrew via llvm-dev]

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.

I’m not against introducing a way to handle that case, but I would be against making it look like the constrained FP intrinsics.

-Andy

From: Cameron McInally <cameron.mcinally at nyu.edu>
Sent: Saturday, June 15, 2019 7:04 AM
To: Eli Friedman <efriedma at quicinc.com>
Cc: LLVM Developers Mailing List <llvm-dev at lists.llvm.org>; Craig Topper <craig.topper at gmail.com>; Kaylor, Andrew <andrew.kaylor at intel.com>
Subject: Re: Constrained integer DIV (WAS: Re: [llvm-dev] Planned change to IR semantics: constant expressions never have undefined behavior)

On Fri, Jun 14, 2019 at 8:36 PM Eli Friedman <efriedma at quicinc.com<mailto:efriedma at quicinc.com>> wrote:
> -----Original Message-----
> From: Cameron McInally <cameron.mcinally at nyu.edu<mailto:cameron.mcinally at nyu.edu>>
> Sent: Friday, June 14, 2019 4:02 PM
> To: Eli Friedman <efriedma at quicinc.com<mailto:efriedma at quicinc.com>>; LLVM Developers Mailing List <llvm-
> dev at lists.llvm.org<mailto:dev at lists.llvm.org>>
> Cc: Craig Topper <craig.topper at gmail.com<mailto:craig.topper at gmail.com>>; Kaylor, Andrew
> <andrew.kaylor at intel.com<mailto:andrew.kaylor at intel.com>>
> Subject: [EXT] Constrained integer DIV (WAS: Re: [llvm-dev] Planned change to
> IR semantics: constant expressions never have undefined behavior)
>
> On Fri, Jun 14, 2019 at 6:24 PM Eli Friedman via llvm-dev
> <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org> <mailto:llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> > wrote:
>
> I don't mean to steal your thunder, Eli, but I'd like to propose that
> we add constrained intrinsics for integer DIV (and maybe REM). Some
> architectures, like x86, can trap on integer div-by-zero. I'd like to
> have some way to access that behavior, even if the C/C++ Standards say
> it's undefined behavior.
>
> We have a few dusty deck codes in-house that depend on this, so I'm
> motivated to push our local changes upstream. That said, if no one else
> finds value in this, we can keep it local.

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.

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.:

#include <stdio.h>
#include <signal.h>

void handle_sigfpe(int fpe)
{ printf("Caught signal %d\n", fpe); }

int main (void) {
  signal(SIGFPE, handle_sigfpe);

#if TRAP
  int x = 1/0;
#else
  raise(SIGFPE);
#endif

  return 0;
}

In this pathological case, the RF flag differs so we'll see an infinite loop.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190617/8b446996/attachment.html>