On 8-Dec-14, at 5:36 PM, Jeff Law wrote:
On 12/08/14 15:15, John David Anglin wrote:
On 12/8/2014 3:01 PM, Jeff Law wrote:
The above is wrong for sibcalls. Sibcall arguments are relative
to the incoming argument pointer. Is this always the frame
pointer?
I don't think it's always the frame pointer. Don't we use an
argument pointer for the PA64 runtime? If I recall, it was the
only port that had a non-eliminable argument pointer at the time.
I don't think PA64 is an argument against this as sibcalls don't work
in the PA64 runtime (they are disabled in pa.c) because the argument
pointer isn't a fixed register. I guess in theory it could be fixed
if it was saved and restored across calls.
But there's nothing that says another port in the future won't have
similar characteristics as the PA, so while the PA isn't particularly
important, it shows there's cases where arguments won't be accessed by the
FP.
DSE as it stands doesn't look at argument pointer based stores and I
suspect they would be deleted with current code.
Agreed.
I believe that this version addresses the above issues. While there may be
some opportunity to
optimize the handling of sibling call arguments, I think it is more
important to get the overall logic
correct. Also, it's obviously a rare situation for the arguments to be
pushed to the stack.
Tested on hppa-unknown-linux-gnu and hppa64-hp-hpux11.11.