[LLVMdev] Add a 'notrap' function attribute?

[Pekka Jääskeläinen]

Hi Nadav,

On 10/31/2013 08:53 PM, Nadav Rotem wrote:
> 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.

Yeah. This is the separate (old) discussion and not strictly related to
the problem at hand. Better if-conversion benefits more than OpenCL C
work-item loops.



[For reference, here's an email in the thread from Spring. This discussion 
lead to the parallel loop metadata to mark the data-parallel loops:

http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-January/058710.html

The current status of this work is that there's now also effectively
loop interchange functionality in pocl so the inner (sequential) loops
in the OpenCL C kernels are interchanged with the implicit parallel
work-item (outer) loops when it's semantically legal. After this the
inner loop vectorizer can be used efficiently also for kernels with
sequential loops.]

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

The original idea was that if the function is marked notrap, it only
loosens the previous restrictions for the optimizations. Thus, if the
old code still assumes trapping semantics, it should be still safe (only
worse optimizations might result).

Anyways, this has at least one problem that I see: functions that have
the notrap attribute cannot be safely inlined to functions without that
attribute. Otherwise a function which has possibly been optimized with the
assumption of not trapping (and speculate an instruction that might trap),
might again trap due to dropping the attribute (and the runtime not
knowing it has to switch off the trapping behavior). Thus, perhaps
notrap should simply always imply noinline to avoid this issue.

The another way is to add 'notrap' metadata to all possibly trapping
instructions. This should be safe and perhaps work across inlining,
but it requires more maintenance code and it might not work very
well in practice: the runtime might want to (or be able to) switch
the trapping semantics of e.g. the FP hardware on function basis, not
per instruction. If that's not the case, the code generator has
to support the instructions separately, injecting instructions that
switch on/off the trapping behavior.

The metadata approach has a benefit that there can be optimizations,
unrelated to the input language, that intelligently prove whether a
particular instruction instance can trap or not. E.g., if it's known
from code that a divider of a division is never zero, one can set
this metadata to a single DIV instruction, perhaps helping later optimizations.

IMHO, the attribute approach is easier and makes more sense in
this particular case where the trapping behavior is dictated
by the input language, but OTOH the metadata approach seems to go
better along how it has been done previously (fpmath) and might
open the door for separate non-language-specific optimizations.

BR,
-- 
--Pekka