[PATCH] Teach DeadArgElimination not to eliminate return values of functions with 'returned' arguments

Stephen Lin swlin at post.harvard.edu
Fri Jun 21 16:01:42 PDT 2013


> Suppose we manage to internalize the constructor (ie., all callers are
> visible), then the calling convention can be changed to fastcc which means
> "llvm can do anything it wants, even different things for different
> functions". If there's an optimization which we could be doing, but that
> fastcc isn't doing it then we ought to fix that! That will apply to many
> more functions than just constructors and more architectures than arm.
>
> If we don't internalize it, we'll see the 'armthisreturn' calling convention
> and the caller and callee both know that the argument is returned. But
> notice that in this case, it isn't possible for deadargelim to remove the
> return type, since we don't have all the callers, so deadargelim must
> conservatively assume the return value is used.
>

Sorry, I didn't fully process your argument correct the first time I
read it so my response (though accurate) was slightly incomplete.

So in addition to what I wrote in my previous e-mail: yes, we should
be taking advantage of this on all architectures when using 'fastcc',
but we don't :D it's hard because the only way to generically take
advantage of this right now without mucking with register allocation
(as far as I could tell) would be to arrange for the 'returned'
argument and return value to be in the same register and to apply the
same trick I use in the ARM backend, but it's not clear upfront
whether or not it's more profitable to do that in the general case or
not because forcing such an arrangement may have other negative
consequences that can't be easily quantified and compared to the
benefit of taking advantage of 'returned'.

On ARM, the ABI has already dictated that the two are the same
register and that constructors/destructors return 'this', so the
decision has already been made for us and it just becomes dumb not to
take advantage of the situation :D (especially since the situation was
arranged that way specifically to allow compilers to do this...)

Stephen



More information about the llvm-commits mailing list