[LLVMdev] Add a 'notrap' function attribute?

[Pekka Jääskeläinen]

On 11/01/2013 01:48 PM, Hal Finkel wrote:
> The large complication that you end up with a scheme like this is
> maintaining control dependencies. [...]

Good point.

> 2. Assert that !notrap cannot be used where its validity might be affected
> by control dependencies.

Thus, I propose that if this ends up being per-instruction property,
its semantics would include this restriction.

> 3. Represent the control dependencies explicitly in the metadata. [...]

This could work but might get quite complex (especially its maintenance)
for the received benefit.

> Given that the common use case for this seems like it will be for some
> language frontend to add !notrap to *all* instances of some kind of
> instruction (divisions, load, etc.), I think that adding a new flag (like
> the nsw flag) may be more appropriate for efficiency reasons. Even easier,
> add some more fine-grained function attributes (as you had suggested).
>
> Also, I think that being able to tag a memory access as no trapping could
> be a big win for C++ too, because we could tag all loads/stores that come
> from C++ reference types as not trapping. Because of the way that iterators
> are defined, I suspect this would have a lot of positive benefits in terms
> of LICM and other optimizations.

True. So, it seems there would be benefit from per-instruction
flags or metadata. Which one (an instruction flag or MD) is better,
I'm not sure. Is the flag too intrusive (it affects the bitcode format,
doesn't it?).

The MD seems more trivial. The main drawback I see is maintaining it
across optimizations.

The question is whether the basic metadata principle applies: Optimizations
that do not maintain it (and thus might drop it), or do not understand
its semantics, should not break.

A problem is that the notrap has two use cases: to communicate to the
optimizations that an instruction instance does never trap (known from
the language or static analysis), thus it's safe to speculate it.

The second meaning (my original one) is that the language (or maybe
a compiler switch) dictates that any instruction instance _should_ not
trap (is undefined if it does or use NaN propagation). In this
case the instructions might trap unless hardware is instructed not
to (switch off FP exceptions, use a special dummy signal handler for
divbyzero) before executing the instruction (or function).

If the latter is implemented using MD and some optimization drops it,
it might break programs that assume (due to the language/switch) that
there are no traps, but propagate NaNs from illegal fp operations,
because the instructions work as intended only if the FP exceptions
are switched off.

So, perhaps both, a function attribute, and an MD (that can be
safely removed) are called for as their use cases and applicability
are different.

-- 
Pekka