[llvm-dev] Constrained integer DIV (WAS: Re: Planned change to IR semantics: constant expressions never have undefined behavior)
Philip Reames via llvm-dev
llvm-dev at lists.llvm.org
Mon Jun 17 10:45:59 PDT 2019
On 6/14/19 5:36 PM, Eli Friedman via llvm-dev wrote:
>> -----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.
This sounds a lot like the approach we took to implicit null checks in
LLVM. At the IR level, we represent them as explicit control flow. In
the backend, we pattern match into a side table of which is used by the
signal handler to redirect control flow to the appropriate handler. The
mechanisms already in place could be easily reused for idiv.
More information about the llvm-dev