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

See https://reviews.llvm.org/D63036 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.

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

> On Jun 14, 2019, at 3:24 PM, Eli Friedman via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> See https://reviews.llvm.org/D63036 <https://reviews.llvm.org/D63036>
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.
Is anyone interested and willing to make a more profound change to llvm’s
constants?  We should really remove all the trapping operators.  The only reason
they exist in the first place is to allow use of Constant::get() as a high level
constant folding API.  We could replace that, eliminate the trapping operators,
and thus eliminate a ton of complexity and bugs…

-Chris


-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190614/1d9f3a18/attachment-0001.html>

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>

On Fri, Jun 14, 2019 at 6:58 PM Chris Lattner via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
>
>
> On Jun 14, 2019, at 3: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=DwMFaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=O_4M49EtSpZ_-BQYeigzGv0P4__noMcSu2RYEjS1vKs&m=HPH8LbjOYmP3G9p6HJYKLtOFGQQJ0aWeEc7QU46PkOw&s=Q-PK-STEJTkFgcTQeOjIR7RY4e_iIHz191Qk_8syQlA&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.
>
>
> Is anyone interested and willing to make a more profound change to llvm’s
> constants?  We should really remove all the trapping operators.  The only
> reason they exist in the first place is to allow use of Constant::get() as
> a high level constant folding API.  We could replace that, eliminate the
> trapping operators, and thus eliminate a ton of complexity and bugs…
>
Hi Chris,

If I'm understanding your proposal correctly, the constrained FP intrinsic
work could make use of that code -- in the future. Eventually we'll want to
optimize the constrained FP intrinsics and being able to constant fold
non-trapping instructions is important.

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

> -----Original Message-----
> From: Cameron McInally <cameron.mcinally at nyu.edu>
> Sent: Friday, June 14, 2019 4:02 PM
> To: Eli Friedman <efriedma at quicinc.com>; LLVM Developers Mailing
List <llvm-
> dev at lists.llvm.org>
> Cc: Craig Topper <craig.topper at gmail.com>; Kaylor, Andrew
> <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>
> 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.

-Eli