[PATCH] Treat a sibling call as though it does a wild read

[John David Anglin]

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.

Okay?

Dave
--
John David Anglin	dave.anglin@bell.net


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: dse.c.d.4.txt
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20141217/3d83b0b4/attachment.txt>