Constrainst for individual registers

[Georg-Johann Lay]

Ilya Lesokhin schrieb:
> Hi,
> I've used your suggestion of "Specifying Registers for Local
> Variables" and found out that code it generates gives better results
> than my method.
> 
> Unfortunately, a recent there on the subject:
> http://gcc.gnu.org/ml/gcc/2012-01/msg00305.html
> 
> got me worried, so I would like to hear what you (or anyone familiar
> with the subjet) know about the status of implementation of "Local
> register Variables" in the AVR backend in gcc-4.5.3 and if it's better
> in newer gcc's.
> 
> Specifically, I would like to know if you believe the following code
> is safe (assuming _mul16x16_32 is implemented correctly):
> 
> DWord_t mul16x16_32(uint16_t x, uint16_t y)__attribute__((always_inline));	
> DWord_t mul16x16_32(uint16_t x, uint16_t y)
> {
> register uint16_t r24_25 asm ("r24") = x;
> register uint16_t r22_23 asm ("r22") = y;
> 
> register uint16_t r30_31 asm ("r30");
> register uint16_t r20_21 asm ("r20");
> 
>  asm (" call _mul16x16_32"  	"\n\t"
> 	: "=&r" (r20_21), "=&r" (r30_31)
> 	: "r" (r24_25), "r" (r22_23)
> 	: "r0", "r1", "cc"
> );
> 
>  DWord_t Result;
>  Result.High = r20_21;
>  Result.Low = r30_31;
>  return Result;
> }

 From my understanding of the matter anf from the manual that should 
word. I don't understand the eary-clobber but it won't hurt here.

But for similar code I saw ICE in fwprop, presumably because it failed 
to handle the additional register mess together with incoming function 
parameters depending on context of the call site.

As you have fun backporting changes then and when, you might want to 
backport the widening multiply patches from PR49687. You don't need all 
that fancy combinations, the quinta essentia is umulhisi3 pattern/insn 
that performs the same operation as yours but without inline assembler 
needed, of course, and different interface.

Your code then looked like

DWord_t mul16x16_32(uint16_t x, uint16_t y)
{
    uint32_t result = (uint32_t) x * y;
    ...

The stuff in 4.7 works by mapping the insns to libgcc calls. As the 
insns explicitly model the register footprint of the libcall, special 
predicates are used to keep insn combine from propagating hard registers 
into (zero_)extend insns. Otherwise, combine fails to synthesize the 
pattern in some cases, i.e. if the "draft" footprint of mulsi3 overlaps 
the propagated hard reg. See comment at respective predicates.

As umulhisi3 is a standard pattern and the tree optimizers handle 
widening multiply, umulhisi3 should work reasonabe even without that 
complexity. But I observed the general part having problems if one 
operand is an integer that fits in 16 bits.

Johann

> Thank,
> Ilya.
> 
> On 10/24/11, Georg-Johann Lay <avr@de> wrote:
> 
>>>Hi,
>>>I'm doing some modifections to the avr backend to suit my needs.
>>>
>>>I would like to add new constrainst for individual registers to use in
>>>inline assembly blocks and i was wondering what is the correct way of
>>>doing this?
>>
>>Not on topic: You can have a look at GCC's "Specifying Registers for
>>Local Variables" feature:
>>http://gcc.gnu.org/onlinedocs/gcc/Local-Reg-Vars.html#Local-Reg-Vars
>>
>>For example, this enables you to interface non-ABI assembler functions
>>with C code without patching the compiler.
>>
>>Moreover, introducing individual register classes will result in a zoo
>>of constraints for 8-bit, 16-bit, 32-bit registers.
>>
>>>in gcc-4.5, i've added a new class for each register to reg_class,
>>>REG_CLASS_NAMES and REG_CLASS_CONTENTS, made a need constrainst for
>>>each register using its class and it worked as expected.
>>>
>>>i tried to do the same in gcc-4.7 and i got:
>>>internal compiler error: in find_costs_and_classes, at ira-costs.c:1704.
>>
>>You will have to debug the compiler proper.
>>
>>Notice that hooks like HARD_REGNO_MODE_OK put additional restrictions on
>>registers/mode combinations.
>>
>>>So i was wondering whether i did the wrong thing or just forgot to
>>>update some target hook.
>>>
>>>Thanks,
>>>Ilya.