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

[Eli Friedman via llvm-dev]

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