On Tue, Dec 16, 2014 at 5:17 PM, John David Anglin <dave.ang...@bell.net> wrote: > 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. >
This caused: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64388 -- H.J.
