This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [split] Add x86 support
- From: rridge at csclub dot uwaterloo dot ca (Ross Ridge)
- To: gcc-patches at gcc dot gnu dot org
- Date: Sat, 26 Sep 2009 01:57:00 -0400 (EDT)
- Subject: Re: [split] Add x86 support
Ross Ridge writes:
> You should be able to simplify things creating an unspec almost exactly
> like UNSPEC_TP and using that as a part of a memory operand with the
> existing compare instructions, rather than defining new insns with
> UNSPEC_STACK_CHECK.
Ian Lance Taylor writes:
>I suppose, but it doesn't seem too major. The current approach seems fairly
>clear to me--everything is in one place.
Hmm... I think you can save at least 80 lines using something like
UNSPEC_TP.
>> I'm not sure if this is something you're concerned with at this point,
>> but munging the return address in __morestack will totally invalidate
>> the processor's return stack branch predictor. ?You can avoid that by
>> generating code something like (in Intel syntax):
>
>Yes, I've done something very similar in my x86 runtime routines, which I will
>commit shortly.
You still seem to invalidating the return stack. Because each call
doesn't have a corresponsing return, the ret instruction at the end
of __morestack will be mispredicted to return to where __morestack
was called.
Ross Ridge