This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On 12/02/2016 01:33 AM, Richard Biener wrote:
That seems like a mistake -- the fact that we can copy propagate the LHS from the returned argument is interesting, but in practice I've found it to not be useful to do so.The LHS on the assignment makes it easier to identify when a tail call is possible. It's not needed for correctness. Not having the LHS on the assignment just means we won't get an optimized tail call. Under what circumstances would the LHS possibly be removed? We know the return statement references the LHS, so it's not going to be something that DCE will do.Well, I thought Prathamesh added the optimization to copy-propagate the lhs from the returned argument. So we'd have both transforms here.
The problem is it makes the value look live across a the call and we're then dependent upon the register allocator to know the trick about the returned argument value and apply it consistently -- which it does not last I checked.
I think we're better off leaving the call in the form of LHS = call () if the return value is used. That's going to be more palatable to tail calling.
But if the function returns the value from the tail call, then going through an LHS is the right thing to do. Using the magic "argX will be the return value" seems clever, but actually hurts in practice.Of course as always the user could have written the code in this way. If the LHS is not required for correctness then I don't think we need to put it there - Pratamesh verified the call is tail-called already if marked by the tailcall pass, even if the LHS is not present.
jeff
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |