[PATCH] Allow CodeGen to take advantage of functions that always return arguments
Stephen Lin
swlin at post.harvard.edu
Thu Apr 18 21:37:07 PDT 2013
Oh OK, will do. Most of what I did was to keep things aligned in the
same style it was already (adding a new parameter attribute that was
longer in length then any previous ones required reformatting for
consistency), but upon review there were some other extraneous
changes. Will try to avoid the instinct to change little things like
that in the same working copy as a main patch next time.
-Stephen
On Thu, Apr 18, 2013 at 11:23 PM, Evan Cheng <evan.cheng at apple.com> wrote:
> Thanks. One suggestion. Next time please separate out stylistic changes into a separate patch.
>
> Evan
>
> Sent from my iPad
>
> On Apr 18, 2013, at 12:13 PM, Stephen Lin <swlin at post.harvard.edu> wrote:
>
>> Hi,
>>
>> This patch adds a target-independent parameter attribute 'returned'
>> (I'm very open to renaming it, just couldn't think of anything
>> better...), which indicates to the caller that a function's return
>> value is always equal to (a bitcast of) the parameter value, allowing
>> tail call optimization and possibly save/restore elision. It is the
>> callee's responsibility to ensure that this contract is fulfilled.
>>
>> The initial intended use case is for C++ constructors and destructors
>> that are ABI-guaranteed to return 'this'; however, I've made it
>> flexible enough to apply to any parameter position or even multiple
>> parameters, since there's no real technical reason not to (although
>> obviously the contract can only be fulfilled in the latter case if
>> multiple arguments are always equal for some reason...)
>>
>> For now, the attribute is taken advantage of in two places:
>>
>> 1. SelectionDAGBuilder::LowerCallTo will detect a tail call
>> opportunity through 'returned' arguments (subject to target-dependent
>> requirements checked later).
>>
>> 2. The ARM backend, in ARMTargetLowering::LowerCall, will avoid
>> save/restoring R0 when 'returned' is on the first argument and the
>> argument's type lowers to MVT::i32, as R0 is used for both the first
>> argument and the return value in that case.
>>
>> Eventually, support can be added to the register allocator to take
>> advantage of the 'returned' guarantee to do better register allocation
>> on all targets, although apparently this is non-trivial.
>>
>> Please kindly review.
>>
>> Stephen
>>
>> P.S. This patch depends on two previous patches, which have yet to be committed:
>>
>> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130415/171948.html
>> (only the first patch)
>>
>> and
>>
>> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130415/171945.html
>> <return-argument.patch>
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
More information about the llvm-commits
mailing list