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

[Philip Reames via llvm-dev]

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.

Philip