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

[Cameron McInally via llvm-dev]

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>