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: [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


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