This is the mail archive of the libc-hacker@sourceware.cygnus.com mailing list for the glibc project.

Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.


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

sysdeps/powerpc/*.S, BPs and registers


The way gcc passes structs by value for PPC (and presumably any RISC)
is hardly optimal.  Since BPs don't exactly fit a machine mode, they
aren't passed in registers.  Rather, the address of an in-memory copy
is passed.  When everything is basically working on PPC & MIPS, I will
work on making gcc pass BPs in registers.  There are implications for
the assembler stuff I wish to discuss now.

The current pass-by-value convention for BPs allows low-impact changes
to the assembler code since BPs don't alter the register assignments
for arguments (a bounded pointer arg still occupies a single
register).  However, when things change so that BPs occupy three
registers, register assignments for later args will be bumped.  IMO, a
good way to handle this is to move from numeric to symbolic register
names.  E.g., instead of writing strcmp in terms of r3 and r4, do
this:

#define rSTR1 r3
#define rSTR2 r4

... and write the body in terms of rSTR1 & rSTR2.  When BPs are passed
in registers, it will need to change the definitions like so:

#if __BOUNDED_POINTERS__
# define rSTR1	 r3
# define rSTR1_b r4
# define rSTR1_e r5
# define rSTR2	 r6
# define rSTR2_b r7
# define rSTR2_e r8
#else
# define rSTR1	 r3
# define rSTR2	 r4
#endif

All temporary register variables will also need symbolic names.

There should be relatively little register pressure with BPs since at
least the base check will occur in the prologue so the base register
can be immediately recycled as a temp variable.  Only when the extent
check happens in the epilogue will we need to preserve the r*_e
registers and there are most often only one or two of these.

I'd like to handle this in three phases:

1) rename numeric registers as symbolic
2) add BP checks for current in-memory pass-by-value
3) revise BP checks for register pass-by-value

Even though BP checks can be added with relatively low impact,
they would still benefit from symbolic register naming.
Therefore, I'd like to do the register renaming first.

Correctness for the register renaming pass should be easy to verify,
since there should be no object-code changes.  Even the pre-processed
assembler should remain unchanged modulo some whitespace differences.

What do you think?  May I proceed with renaming registers?

Greg

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