limiting call clobbered registers for library functions

[Paul Shortis]

On 03/02/15 09:14, Joern Rennecke wrote:
> On 2 February 2015 at 21:54, Paul Shortis <pshortis@dataworx.com.au> wrote:
>> I could have avoided the expander and used a single instruction pattern for
>> a)b)c) if if could have found a way to have alternative dependent clobbers
>> in an instruction pattern. I investigated attributes but couldn't see how I
>> would be able to achieve what I needed. Also tried clobber (match_dup 2) but
>> when one of the alternatives has a constant for operands[2] the clobber is
>> accepted silently by the .md compiler but doesn't actually clobber the
>> non-constant alternatives.
> You can clobber one or more match_scratch with suitable constraint alternatives
> and let the register allocator / reload reserve the hard registers.
> Well, not really for cc, you'll just have to say you clobber it, and
> split away the
> unused clobber post-reload.
> That will not really give you less source code, but more uniform patterns
> prior to register allocation.  That gives the rtl optimizers a better
> handle on the code.
> The effect is even more pronounced when you replace all hard register usage with
> pseudo register usage and appropriate constraints.
>
Thanks Joern,

That was one of the (many) things I had tried, but I couldn't get 
it to work & moved on. Your post caused to to try again, and it 
worked perfectly and I now need just a single pattern and no 
expander.

I do howeverhave one remaining issue.

The pattern I'm using is ...

(define_insn "<hiShiftName>hi3"
   [(set (match_operand:WORD 0 "register_operand" "=r,C,C")
             (hiShiftOperator:WORD (match_operand:WORD 1 
"register_operand"  "0,0,0")
                                   (match_operand:WORD 2 
"rhs_operand" "M,i,D")))
     (clobber (reg:CC_NOOV CC_REGNUM))
     (clobber (match_scratch:HI 3 "=X,X,D"))
   ]
   ""
"..."
   [(set_attr "length" "2,8,8")]
)

the r/M constraint pair is for shifts small enough to perform in 
line ( M == const_int 1...3)

register constraints C and D are for the registers used for the 
library calls

At first I used the first two registers normally used for 
function calls (r1 and r2), however when building the libgcc et 
al I occasionally encounter the situation where a register in the 
R1_CLASS (constraint C) can't be allocated.

I changed these two registers to the two last GPRs in the 
allocation order and made them call clobbered and I can at least 
compile libgcc and newlib.

Could I be doing something better, or is this expected behaviour ?

Paul.