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

[Cameron McInally via llvm-dev]

On Fri, Jun 14, 2019 at 8:36 PM Eli Friedman <efriedma at quicinc.com> wrote:

> > -----Original Message-----
> > From: Cameron McInally <cameron.mcinally at nyu.edu>
> > Sent: Friday, June 14, 2019 4:02 PM
> > To: Eli Friedman <efriedma at quicinc.com>; LLVM Developers Mailing List
> <llvm-
> > dev at lists.llvm.org>
> > Cc: Craig Topper <craig.topper at gmail.com>; Kaylor, Andrew
> > <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> > 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/20190615/6812b4f4/attachment.html>