[LLVMdev] Add a 'notrap' function attribute?

[Hal Finkel]

----- Original Message -----
> Hi Pekka,
> 
> The motivation for the ’notrap’ bit is clear.

I'd also like to see this functionality.

>  Domain specific
> languages can set this bit to enable more aggressive optimizations.
>  I don’t think that the Loop Vectorizer is a good example because it
> is not designed to vectorize data-parallel languages which have a
> completely different semantics.  In OpenCL/Cuda you would want to
> vectorize the outermost loop, and the language guarantees that it is
> safe to so.
> 
> Function attribute is one possible solution.  Another solution would
> be to use metadata. I think that we need to explore both solutions
> and estimate their effect on the rest of the compiler.  Can you
> estimate which parts of the compiler would need to be changed in
> order to support this new piece of information ?  We need to think
> about what happens when we merge or hoist load/stores.  Will we need
> to review and change every single memory optimization in the
> compiler ?

My hope is that almost all of the benefit can be obtained only by changing isSafeToSpeculativelyExecute -- for memory functions, we already preserve TBAA metadata, and so auditing to preserve notrap seems like it should be reasonable. For floating-point, we preserve fpmath metadata, so that should not be too hard.

 -Hal

> 
> Thanks,
> Nadav
> 
> On Oct 31, 2013, at 7:38 AM, Pekka Jääskeläinen
> <pekka.jaaskelainen at tut.fi> wrote:
> 
> > Hello,
> > 
> > OpenCL C specifies that instructions should not trap (it is
> > "discouraged"
> > in the specs). If they do, it's vendor-specific how the hardware
> > exceptions are handled.
> > 
> > It might be also the case with some other (future) languages
> > targeting "streamlined" parallel accelerators in an heterogeneous
> > setting.
> > At least CUDA comes to mind. What about OpenACC and the new OpenMP,
> > does someone know offhand?
> > 
> > It would help several optimizations if they could assume certain
> > instructions do not trap. E.g., I was looking at the if-conversion
> > of
> > the loop vectorizer, and it seems to not support speculating
> > stores,
> > divs, etc. which could be done if we knew it's safe to
> > speculatively
> > execute them.
> > 
> > [In this particular if-conversion case proper predicated execution
> > (not speculative) would require predicates to be added for all LLVM
> > instructions so they could be squashed. I think this was discussed
> > several years ago in the context of a generic IR-level
> > if-conversion
> > pass, but it seems such a thing did not realize eventually.]
> > 
> > Anyways, "speculative" if-conversion is just one example where
> > knowing
> > that traps need not to be considered in the function at hand
> > would help the optimizations. Also other speculative code motion
> > optimizations, e.g., LICM, could benefit from it.
> > 
> > One way would be to introduce a new function attribute. Functions
> > (e.g.,
> > OpenCL C or CUDA kernels) could be marked with an attribute that
> > states
> > that the instructions can be assumed not to trap -- it's a
> > programmer's or
> > the runtime's mistake if they do. The runtime should change the fp
> > computation mode to the non-trapping one before calling such
> > a function (this is actually stated in the OpenCL specs). If such
> > handling is not supported by the target, then the attribute should
> > not
> > be added the first place.
> > 
> > The attribute could be called 'notrap' which would include the
> > semantics of any trap caused by any instruction.  Or that could be
> > split, just in case the hardware is known not to support one of the
> > features. Three could suffice: 'nofptrap' (no IEEE FP exceptions),
> > 'nodivtrap' (no divide by zero exceptions, undef value output
> > instead),
> > 'nomemtrap' (no mem exceptions).
> > 
> > What do you think of the general idea? Or is there something
> > similar
> > already that can accomplish this?
> > 
> > Thanks in advance,
> > --
> > Pekka
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 

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