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

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>

On Mon, Jun 17, 2019 at 4:05 PM Kaylor, Andrew <andrew.kaylor at
intel.com>
wrote:
> 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.
>
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:

  // X / 0 -> undef
  // X % 0 -> undef
  // We don't need to preserve faults!
  if (match(Op1, m_Zero()))
    return UndefValue::get(Ty);

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.

> I’m not against introducing a way to handle that case, but I would be
> against making it look like the constrained FP intrinsics.
>
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190617/fec06b92/attachment.html>

> But it would be nice if there was some way to access this behavior in an
IEEE conformance mode.

Bah, FP traps on the brain. Obviously not an IEEE-754 issue...

On Mon, Jun 17, 2019 at 5:57 PM Cameron McInally <cameron.mcinally at
nyu.edu>
wrote:
> On Mon, Jun 17, 2019 at 4:05 PM Kaylor, Andrew <andrew.kaylor at
intel.com>
> wrote:
>
>> 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.
>>
>
> 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:
>
>   // X / 0 -> undef
>   // X % 0 -> undef
>   // We don't need to preserve faults!
>   if (match(Op1, m_Zero()))
>     return UndefValue::get(Ty);
>
> 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.
>
>
>> I’m not against introducing a way to handle that case, but I would be
>> against making it look like the constrained FP intrinsics.
>>
>
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190617/a90cfa9f/attachment.html>