[LLVMdev] Integer divide by zero

[dag at cray.com]

Chandler Carruth <chandlerc at google.com> writes:

> You're actually asking for the formal model of the LLVM IR to be
> *parameterized*. In one mode, an instruction would produce undefined
> behavior on division, and in another mode it would produce a trap.
> Then you are asking for the optimizer stack to support either semantic
> model, and produce efficient code regardless.
>
> This is completely intractable for LLVM to support. It would make both
> the optimizers and the developers of LLVM crazy to have deep
> parameterization of the fundamental semantic model for integer
> division.

You're making this *way* too complicated.  We have plenty of examples of
options to turn off optimizations.  Most compliers provide options to
preserve traps.

The division would still semantically have undefined behavior.  The
implementation would simply make the behavior a trap instead of
returning some random garbage value.  Sure, it *may* change how other
code is optimized but that is the choice the implementor makes when
choosing to use the option to preserve traps.  LLVM developers not
concerned with preserving traps need not give it a second thought.

> The correct way to support *exactly* reproducing the architectural
> peculiarities of the x86-64 integer divide instruction is to add a
> target-specific intrinsic which does this. It will have defined
> behavior (of trapping in some cases) as you want, and you can emit
> this in your FE easily.

You can't do that if the FE doesn't see the constant expression.
Optimization may reveal it later.

> Cameron, you (and others interested) will certainly need to provide
> all of the patches and work to support this if you think this is an
> important use case, as the existing developers have found other
> trade-offs and solutions. 

Certainly.

A software test+trap is theoretically possible and the target optimizer
could theoretically get rid of it, but I share Cameron's concern about
the work required to turn theory into reality.  He's not asking to
redefine the LLVM IR.  He's asking for an option to control the
implementation of that IR.

Preserving traps is a real-world need.  LLVM itself doesn't currently
provide a way to do it.  It seems like it should have one and not rely
on particular frontends.  It's supposed to be an independent set of
libraries, right?

                              -David