[llvm-commits] patch: codegen non-exiting calls as tail, even if not tail in IR

[Duncan Sands]

Hi Nick,

On 15/10/12 05:44, Nick Lewycky wrote:
> This patch teaches the LLVM codegen layer to try emitting calls to
> 'terminal' functions as tail calls, even if they aren't marked tail calls in the
> IR. The motivation is to minimize the amount of extra instructions emitted by
> clang's -fcatch-undefined-behavior flag (and other tools like asan/msan/tsan, if
> run in a mode where they don't turn off tail calls due to the loss of stacktrace
> info).
>
> Why not mark them 'tail' in the IR? Because the IR definition states that a tail
> call is one does not access any allocas or varargs in the caller. This is good
> because it's defining an IR concept in terms of other IR concepts, and I don't
> want to change it. BasicAA uses this for example, by assuming that a call with
> 'tail' doesn't touch any alloca'd memory.
>
> What's a terminal function? One that is noreturn + nounwind. A function that
> calls longjmp() will be marked nounwind by clang, and I can't tell whether this
> is correct due to a lack of precision in the definition of 'nounwind' in the
> language reference.
>
> At the machine level, it's safe to tail call to a function that accesses its
> caller's stack, as long as we plan to never return.

is this really true?  Imagine that you pass the callee pointers to variables on
the caller's stack, and the callee reads/writes those variables via the
pointers.  Imagine also that the callee declares some stack variables of its
own, and these get placed on top of the caller's variables.  Then writing to the
caller's variables can modify the callee's variables and vice versa, causing the
callee to malfunction.  The fact that the callee doesn't return isn't relevant
in this scenario.

Ciao, Duncan.

>
> Please review! The two cases that I'm concerned about are when the callee calls
> longjmp(), and when the call is varargs. I think both of these cases are fine
> without special handling, but I'd appreciate someone double-checking that.
>
> Nick
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>