[llvm-dev] Constrained integer DIV (WAS: Re: Planned change to IR semantics: constant expressions never have undefined behavior)
Cameron McInally via llvm-dev
llvm-dev at lists.llvm.org
Mon Jun 17 14:57:26 PDT 2019
On Mon, Jun 17, 2019 at 4:05 PM Kaylor, Andrew <andrew.kaylor at intel.com>
> 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()))
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev