[Libre-soc-isa] [Bug 532] discuss iterative approach for statistical analysis of effectiveness of Compressed PowerISA encoding

bugzilla-daemon at libre-soc.org bugzilla-daemon at libre-soc.org
Sat Nov 21 22:19:25 GMT 2020


--- Comment #11 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Alexandre Oliva from comment #9)
> FTR, information extracted from gcc's gcc/config/rs6000/rs6000.h about fixed
> registers (assigned to special purposes) and register allocation order:
> Special-purpose registers on ppc are:
> r0: constant zero/throw-away
> r1: stack pointer
> r2: thread-local storage pointer in 32-bit mode
> r2: non-minimal TOC register
> r10: EH return stack adjust register
> r11: static chain pointer
> r13: thread-local storage pointer in 64-bit mode
> r30: minimal-TOC/-fPIC/-fpic base register
> r31: frame pointer

ah! that's what i thought was SP. excellent.  so we need to find out what the
range is on the immediate, for this one.  it's used a *lot*, same as SP.

> lr: return address register
> the register allocation order in GCC (i.e., it takes the earliest available
> register that fits the constraints) is:
>    We allocate in the following order:
> 	fp0		(not saved or used for anything)
> 	fp13 - fp2	(not saved; incoming fp arg registers)
> 	fp1		(not saved; return value)
> 	fp31 - fp14	(saved; order given to save least number)

these aren't contiguous, makes deciding the priority for C allocation something
of a pain.  hence the reason for seeing actual usage.

> 	r9		(not saved; best for TImode)
> 	r10, r8-r4	(not saved; highest first for less conflict with params)

at least these should be mappable

> 	r3		(not saved; return value register)

and this

You are receiving this mail because:
You are on the CC list for the bug.

More information about the Libre-SOC-ISA mailing list