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: [semi PATCH] ARM/Thumb branches out of range for MI thunks


Richard Earnshaw <rearnsha@arm.com> writes:

>> > It sounds like the problem is that "this is a thunk" is a concept only
>> > visible within the C++ front end, whereas it needs to be language-
>> > independent.  That ought to be a feasible change to make, if we can
>> > agree on what "this is a thunk" means.
>> > 
>> > I am not sure if the present state of thunk generation is better or
>> > worse than it was at the time you posted these messages.
>> > 
>> > What is the cost of an arm/thumb mode switch, compared to the extra
>> > cycles required to execute a purely Thumb thunk?
>> 
>> The cost of a Thumb->arm switch is just the cost of a branch - none of
>> the ARM cores I'm familiar with take an extra hit on switching.  Three
>> cycles on arm9tdmi which is what I have the manual open for.  It's
>> just a "bx pc; nop" switch although it also means you need to make an
>> interworking branch to whatever you're thunking.
>> 
>> The same thing applied to PLT entries - you take more delays in trying
>> to make it work in Thumb than you do in switching.
>
> In this case the cost is even lower than that.  Since you always arrive at 
> a thunk with an indirect call (which uses bx, so the switch happens for 
> free) and it's fairly simple to do the same on the dispatch (one extra 
> instruction for v4t none for v5).

Ok, so it seems clear that we ought to emit these thunks in ARM mode.
It also seems clear that including C++ front end headers in arm.c is
not the right way to do it.

Richard, what do you think the right way would be?  What information
needs to get exposed in a language-independent manner, so that the
ARM back end can do the right thing?

zw

p.s. There is another skeleton in this particular closet, which is the
concept of using alternate entry points to the function instead of
thunks.  I got stuck on trying to represent this at the tree level,
and it certainly isn't the right way to do it for 3.4.  But whatever
we do now shouldn't make it _harder_ to do that.


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