[LLVMdev] Add a 'notrap' function attribute?

[Hal Finkel]

----- Original Message -----
> 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?).

I think this depends on whether or not we have any free bits in the relevant instructions.

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

Depending on how this is done, it is either more intrusive or less intrusive than the alternative. If we encode control dependencies into the MD, then it is less intrusive (although it could be slow and bloat the IR size); if we explicitly try to maintain it everywhere, then we might as well have a flag.

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

It would need to be engineered that way, otherwise we can't use MD.

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

I don't think that, in general, we're SNAN-safe.

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

Agreed.

 -Hal

> 
> --
> Pekka
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory