http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54232
Bug #: 54232
Summary: For x86 PIC code, ebx should be spillable
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bug...@aerifal.cx
When generating x86 position-independent code, GCC permanently reserves EBX as
the GOT register. Even in functions that make no use of global data, EBX cannot
be used as a general-purpose register. This both slows down code that's under
register pressure and forces inline asm that needs an argument in EBX (e.g.
syscalls) to use ugly temp register shuffling to make gcc happy.
My proposal, and I understand this may be difficult but I still think it's
worth stating, is that the GOT register EBX should be considered spillable like
any other register. In particular, the following consequences should result:
- If a function is not using the GOT (not accessing global or file-local static
symbols or making non-hidden function calls), all GP registers can be used just
like in non-PIC code. A pure function with no
- If a function is only using a "GOT register" for PC-relative data access, it
should not go to the trouble of actually adjusting the PC obtained to point to
the GOT. Instead it should generate addressing relative to the PC address that
gets loaded into the register.
- In a function that's not making calls through the PLT (i.e. a leaf function
or a function that only calls hidden/protected functions), the "GOT register"
need not be EBX. Any register could be used, and in fact in some trivial
functions, using a call-clobbered register would avoid having to save/restore
EBX on the stack.
- In any function where EBX or any other register is being used to store the
GOT address, it should be spillable (either pushed to stack, or simply
discarded and reloaded with the standard load sequence when it's needed again
later) just like a register caching any other data, so that under register
pressure or inline asm constraints, the register becomes temporarily available
for another use.
It seems like all of these very positive consequences would fall out of just
treating GOT and GOT-relative addressing as address expressions based on the
GOT address, which could be cached in registers just like any other expression,
instead of hard-coding the GOT register as a special reserved register. The
only remaining special-case/hard-coding would be treating the need for EBX to
contain the GOT address when making calls through the PLT as an extra
constraint of the function call ABI.
