This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH][MIPS] mwarn-framesize= option
- From: Eric Botcazou <ebotcazou at adacore dot com>
- To: "Seongbae Park (ëìë, ææå)" <seongbae dot park at gmail dot com>
- Cc: gcc-patches at gcc dot gnu dot org, "Mark Mitchell" <mark at codesourcery dot com>, "David Daney" <ddaney at avtrex dot com>, "Andreas Krebbel" <Andreas dot Krebbel at de dot ibm dot com>, "Andrew Pinski" <pinskia at gmail dot com>, maxim at codesourcery dot com, rdsandiford at googlemail dot com
- Date: Fri, 13 Jun 2008 23:19:49 +0200
- Subject: Re: [PATCH][MIPS] mwarn-framesize= option
- References: <48458950.5090404@codesourcery.com> <4852D27E.5040403@codesourcery.com> <ab3a61990806131356u20eb005dn7bfd08d992b03da@mail.gmail.com>
> 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 ?
A few years of experience[*] have shown that the first approach is somewhat
error-prone: for example, on the IA-64, the validity window during which you
can calculate it is very small (just before prologue/epilogue generation).
On the SPARC, you must be careful with the leaf function business. And so on.
So the second approach is clearly the way to go in my opinion.
[*] http://gcc.gnu.org/ml/gcc-patches/2006-06/msg01008.html
--
Eric Botcazou