[LLVMdev] Add a 'notrap' function attribute?

[Nadav Rotem]

Hi Pekka, 

The motivation for the ’notrap’ bit is clear.  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 ?  

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