PR63633: May middle-end come up width hard regs for insn expanders?

[Vladimir Makarov]

On 22/04/15 10:39 AM, Georg-Johann Lay wrote:
>
> Attached is a C test program which produces fine results with
>
> $ avr-gcc -S -O2 -mmcu=atmega8
>
> Also attached is a respective patch against the trunk avr backend that 
> indicates the transition from clobbers to hard-regs-by-constraint.
>
> I don't actually remember when I tried this first; sometimes around 
> when 4.8 was in stage I or so.
>
> If my recollection is right; the problem was not that small test 
> programs with mulsi3 produced large code, but that "ordinary" code 
> could get much worse.  I had the impression it was because the bunch 
> of new, rarely used / rarely useful register classes, and that IRA's 
> cost computation got confused resp. much less accurate than with the 
> usual register classes (only 10 classes of GENERAL_REG).
>
> The attached patch adds 27 new register classes, and to transform all 
> insns even more classes might be needed: 8-bit, 16-bit and 24-bit 
> multiplications including sign/zero extension of operands, fixed-point 
> functions from 8...32 bit, divmod, builtins implementations, support 
> functions for address spaces, ...
>
> The insns which are using this all have the following properties in 
> common:
>
> - Only 1 constraint alternative
>
> - Register allocation is uniquely determined, i.e. reg allocator has 
> no choice what register to pick for what operand (except for 
> commutative constraints with '%' which give exactly 2 solutions).
>
> The patch avoids clobbers or scratches altogether.  The only insn 
> where a register is affected that is not the output, are transformed 
> from single_set to parallels in split1.  The 2nd set describes setting 
> a (reg:HI 26) to a useless value.  The insn is not expanded as 
> parallel, because insn combine won't use them for combinations.
>
> Is there a chance that register allocation gets worse just because so 
> many register classes are added?
Thanks for providing the patch and test.  Sometimes it is even for me 
hard to say how the RA will behave in complicated cases without 
investigating actual code.  After looking at IRA dumps, I think you will 
be okay.

When you use hard regs, pseudos moved to the hard regs got preferences 
of the hard regs from the moves and possibility of the pseudos to get 
the hard reg and moves to be eliminated will be high.

When you use one hard reg class constraints, the operand pseudo gets the 
same hard reg preference.  IRA has a code for this.  So the final result 
will be quite analogous.

The only difference is that RA (more accurately ira-costs.c code) will 
be a bit slower as there are more reg classes.