[LLVMdev] Add a 'notrap' function attribute?

[Nick Lewycky]

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<http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131101/19bed835/attachment.html>