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

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=532

--- 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.