This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH][MIPS] mwarn-framesize= option


Seongbae Park (ëìë, ææå) wrote:
On Fri, Jun 13, 2008 at 1:03 PM, Mark Mitchell <mark@codesourcery.com> wrote:
Richard Sandiford wrote:

Since we are in stage 1, this would be the time to get this in.  We would
then not have two different ways to specify very nearly the same thing.  It
would also save us the trouble of deprecating and removing a mips specific
version in the future.
Agreed 100%.  FWIW, this was also what Seongbae and I thought when
the -Wframe-larger-than patch originally went in:

http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00642.html
It seems a bit unfortunate to me that we're using Maxim's patch to try to
force someone to implement this bit of infrastructure.  If we wanted the
target hook, I think we should have asked the original submitter of the
patch you mention to implement it at the time as a condition of putting it
in.

However, I guess we can ask politely now...

Seongbae, is adding some hook mechanism so that back-ends can refine the
frame-size check something that you would be able to take on?

Thanks,

I can give a shot. I think we need to record the frame size calculated in the backend somehow somewhere, and the question is where to store it and how to get it.

One way to do it, is the adding a new target hook, something like,
target_get_frame_size() which will return the actual frame size of a function
(the hook will work only after prologue and epilogue are generated of course).
This means targets will have to independently remember the frame size somehow,
or be able to calculate it.
If the target doesn't implement one, we can fall back to
get_frame_size() in function.c.

One alternative is to add a new field in struct function
that contains the actual frame size, and have the backend write to it
during prologue/epilogue generation.

Any preference for either way ?

My 2 cents are for the second approach. A new target hook will provoke temptation to call it when it is not yet ready to properly calculate frame size. A new field is cleaner in a way that it provides kinda read-only access for target-independent code and may be treated as non-usable till target says overwise (e.g., by setting it to a sensible value).


--
Maxim


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]