[LLVMdev] Add a 'notrap' function attribute?

[Pekka Jääskeläinen]

On 11/01/2013 10:26 PM, Nick Lewycky 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!

Thanks for the link. I'm not sure if you meant to merge the 'speculatable'
with 'notrap' or just take it in account when implementing optimizations
based on 'notrap'.

The notrap attribute(s) will not work as a replacement for the 'speculatable'
to be able to speculatively call the function itself, but would work for
optimizations inside the function itself.

"Speculatable" implies also more of the semantic information of the
program's logic (e.g. the halting problem mentioned in the above thread).
Also, 'speculatable' does not imply 'notrap' because the function itself
might have instructions that should not be speculated separately. That is,
it won't trap if the original control dependencies are respected, but
might trap in case of some (illegal) speculative execution is done inside
the function (for example tests for special cases in FP computation or
NULL ptr checks).

The connection here is that optimizations based on 'notrap' might
make a previously 'speculatable' function 'non-speculatable' unless the 
'notrap' is respected (by the runtime so it disables exceptions). It
should be ok, the notrap should just not be dropped. This also indicates
that it should be an attribute, not MD.

On the question whether there should be one or more fine grained
'notrap' attributes: If there is a single 'notrap' only, it would state
that none of the instructions inside the function cause traps regardless
of how they were speculatively executed. This can be true because of
the hardware (e.g. one that does not implement the exceptions the
first place or does not have an MMU/mem protection) or if the exceptions
can be and are switched off before calling the function.

E.g., a load inside a NULL pointer check can be hoisted above
the check, etc. Creepy looking optimizations for memory protected
envs that trap on illegal access. If there were more fine grained attributes,
one could just state the non-trapping property for a subset of cases.
It's future proof in a sense that a monolithic 'notrap' implies it is possible
switch off any type of potential exception, which it might not be for
some platform while the finer granularity ones assume only partial support.

It should be emphasized that 'no*trap' attirubtes would be a contract:
it does not state that it is known that the instructions do not trap,
but tells that inside the function there might be speculated instructions
that do trap in case the trap(s) are not switched off.

-- 
Pekka