Re: [RFA] Improve Sparc epilogue analysis

David S. Miller
2002-04-26T01:33:21Z

From: Michael Snyder <msnyder@redhat.com>
Date: Thu, 25 Apr 2002 13:59:00 -0700

"David S. Miller" wrote:
>
> From: Michael Snyder <msnyder@redhat.com>
> Date: Wed, 24 Apr 2002 17:36:02 -0700
>
> "David S. Miller" wrote:
> > I'd like to ask that you re-review this change, given this, please.
>
> The part that's mentioned in the changelog entry is OK, except
> you can remove sparc_skip_prologue_frameless_p (and say so in
> the changelog) rather than rewrite it.
>
> Wait a second, how can I remove sparc_skip_prologue_frameless_p
> when it isn't even there anymore? :-)
>
> What exists is "sparc_prologue_frameless_p" which is a boolean.
> That is what replaces the functionality for what I removed
> (sparc_skip_prologue_frameless_p, SKIP_PROLOGUE_FRAMELESS_P,
> et al.).
>
> I think you're still a little confused on the current state of
> the tree.

That comment was unnecessary, thank you.

I think it was more than appropriate.

Whether the function is in or out, it is wrong as written,
or at the least you have to justify why you have changed
the behavior.

If it does not exist in the tree, it by definition can't be in any
other state than "not there".

This part of the thread centers around you telling me to remove
"sparc_skip_prologue_frameless_p". And I'm trying to say "it isn't
there to begin with, what function are you even talking about?"

The existing function returns TRUE if and only if the input
address is equal to the address returned by examine_prologue,
which in this case will be the address of one of a small set
of specific instructions (eg. a SAVE or an add sp).

Your function, in the presence of symbols, will return TRUE
if and only if the input address is equal to the last instruction
in the line (presumably of the prologue). This is a change.
I don't know whether it was intentional or not, but you can't
make it without explaining it.

Here you are making a point about my changes to
sparc_prologue_frameless_p, and those are quite valid.
And I have dealt with this in the followup patch I sent
last night.

But this has nothing to do with my what I am replying to,
which is you telling me to remove a differently named
function which no longer exists in the tree.