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

[John David Anglin <dave dot anglin at bell dot net>]

On 16-Dec-14, at 8:17 PM, John David Anglin 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.
>
> Okay?


Sorry, forgot to append testcase and ChangeLog entry for it.

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

Attachment: dse.c.d.4.txt
Description: Text document