This is the mail archive of the 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: [windows][rft] regparm vs stack probe fix

On Mon, Oct 20, 2003 at 08:55:20PM +0100, Danny Smith wrote:
>From: "Christopher Faylor"
>> On Mon, Oct 20, 2003 at 10:20:35AM +0100, Danny Smith wrote:
>> >
>> >----- Original Message -----
>> >From: "Richard Henderson"
>> >> It would appear that we can just save and restore eax around the
>> >> stack probe routine.  This looks good to my eye, but I don't have
>> >> things set up to do testing on windows anywhere.
>> >>
>> >> * i386.c (ix86_eax_live_at_start_p): New.
>> >> (ix86_expand_prologue): Save and restore eax around stack probe
>> >> if it's live.
>> >
>> >Yes, this seems to do it.  I've tested with attached  testcase using
>> >gcc -O[1-3],
>> >
>> >Bootstrap in progress on mingw32.
>> >.
>Tests OK. The patch fixes the -funit-at-a-time bootstrap PR 12209 and
>does not
>cause any new regressions
>> This seems to be better than the patch that I was testing.  Danny,
>this works
>> ok with fastcall?  That was a minor problem with my patch.
>Yes, this handles fastcall correctly.
>FWIW. my earlier patch (use fastcall convention rather than regparm
>when optimizing local functions via cgraph) can be applied on top of
>That would mean for explicit regparm request on global function,
>the push/mov would be used to save eax.  When cgraph  does it for
>local functions,it would avoid the need for extra push/mov by setting
>regno = 2 and using fastcall convention.
>I don't know if that is worth it.  May be just some documentation that
>suggests that for local functions that allocate big stack chunks,
>consider using explict fastcall attribute

Wouldn't using ebx rather than eax solve this problem for all cases,


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