[LLVMdev] Add a 'notrap' function attribute?

[Nadav Rotem]

Nick, 

I like the simplicity of the attribute approach. However, one of the problems of using the attribute approach is that you lose them when you inline the function.  I am not sure if this problem disqualifies this approach for the proposed uses or not. 

Thanks,
Nadav

On Nov 1, 2013, at 1:26 PM, Nick Lewycky <nlewycky at google.com> wrote:

> FYI, see also the previous discussion about "speculatable":
> 
>   http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-July/064426.html
> 
> I think such an attribute should be added.
> 
> In the thread which lead up to that thread, I proposed using more fine-grained attributes and Michael rightly pointed out the problem with that: you'd need one for every possible form of undefined behaviour. You listed "nofptrap", "nodivtrap" and "nomemtrap", but you didn't say "nounreachabletrap". Whoops!
> 
> Nick
> 
> 
> On 31 October 2013 07:38, 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131104/679fe367/attachment.html>