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

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

-Eli

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>

On 6/14/19 5:36 PM, Eli Friedman via llvm-dev 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.
This sounds a lot like the approach we took to implicit null checks in 
LLVM.  At the IR level, we represent them as explicit control flow.  In 
the backend, we pattern match into a side table of which is used by the 
signal handler to redirect control flow to the appropriate handler.  The 
mechanisms already in place could be easily reused for idiv.

Philip

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>