[llvm-dev] Altering the return address , for a function with multiple return paths

John McCall via llvm-dev llvm-dev at lists.llvm.org
Wed Jul 24 07:42:44 PDT 2019


On 24 Jul 2019, at 1:46, Philip Reames wrote:
> We've also got some cases where returning a value in a flag might be 
> useful.  Our typical use case is we have a "rare, but not *that* 
> rare* slowpath which sometimes needs to run after a call from a 
> runtime function.  Our other compiler(s) - which use hand rolled 
> assembly for all of these bits - return the "take-rare" bit in ZF, and 
> branch on that after the call.  For our LLVM based system, we just 
> materialize the value into $rax and branch on that.  That naive 
> scheme has been surprisingly not bad performance wise.
>
> * The "not *that* rare" part is needed to avoid having exceptional 
> unwinding be the right answer.
>
> If we were to support something like this, you'd really want to be 
> able to define individual flags in the callee's calling convention 
> clobber/preserve lists.  It's really common to have a helper routine 
> which sets say ZF, but leaves others unchanged.  Or to have a 
> function which sets ZF, clobbers OF, and preserves all others.  But 
> if we were going to do that, we'd quickly realize that the x86 backend 
> doesn't track individual flags at all, and thus conclude it probably 
> wasn't worth it begin with.  :)

I'm intrigued what functions would usefully *preserve* flags.  That's 
quite difficult on x86, since it means you have to spill flags if you do 
any basic arithmetic at all (unless you do it all with `lea`).  Maybe on 
a target like PPC with really fleshed-out support for flags and 
conditionality?

John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190724/4eb6a1ad/attachment.html>


More information about the llvm-dev mailing list