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

[Georg-Johann Lay]

Am 04/20/2015 um 10:11 PM schrieb Vladimir Makarov:
> On 17/04/15 05:58 AM, Georg-Johann Lay wrote:
>> I allowed me to CC Vladimir; maybe he can propose how the backend can
>> describe an efficient, constraint-based solution.  The problem is about
>> expanders producing insns with non-fixed hard-regs as in/out operands or
>> clobbers.  This includes move insn from non-generic address spaces which
>> require dedicated hard regs. Issue is about correctness and efficiency of
>> generated code.
>>
> I might be wrong but I think you have a bloated code because you use
> scratches.  I already told several times that usage of scratch is always a bad
> idea.  It was a bad idea for an old RA and is still a bad idea for IRA.  The
> usage of scratches should be prohibited, probably we should write it
> somewhere.  It is better to use just a regular pseudo instead.
>
> Why it is a bad idea?  Because IRA (or the old global RA) does not take them
> into account *at all*.  It means that IRA might think that there are enough
> registers for pseudos but in reality it is wrong because of scratches in live
> range of the pseudos.

Ok, thanks for that information!

The avr backend actually uses clobbers only if one is available peep2.  But 
there are insns that need always specific registers.

> If it is not the case I should investigate why you have a bloated code and
> small test would help here.
>
> Thanks,  I hope my comments will be useful.

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?

Johann

-------------- next part --------------
A non-text attachment was scrubbed...
Name: mul.c
Type: text/x-csrc
Size: 798 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20150422/5c2f164e/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mulsi-without-clobbers.diff
Type: text/x-patch
Size: 35552 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20150422/5c2f164e/attachment-0001.bin>