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

[Cameron McInally via llvm-dev]

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