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

[Cameron McInally via llvm-dev]

On Fri, Jun 14, 2019 at 6:24 PM Eli Friedman via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> See https://reviews.llvm.org/D63036
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D63036&d=DwMFAg&c=slrrB7dE8n7gBJbeO0g-IQ&r=O_4M49EtSpZ_-BQYeigzGv0P4__noMcSu2RYEjS1vKs&m=yNP3delmjr47oSR0YAN8JwlGJEao8M6vTDRiKybxrG8&s=SdJmeI8rbeC0xfZfTawSCri0U3GDrJyUzTA-U5SJKoA&e=>
> for the full patch and description. Essentially, the Constant::canTrap API
> is going away.  To make this work, the semantics of division and remainder
> constant expressions are changing slightly, so division by zero produces
> poison, not undefined behavior.  (The corresponding instructions still have
> undefined behavior.)  This change should make writing and understanding IR
> optimizations easier.
>

This is a good change. Thanks for working on it.

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.

-Cam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190614/8361ff44/attachment.html>