Re: [PATCH] Hard register asm constraint

[Georg-Johann Lay <avr@gjlay.de>]

Am 27.06.24 um 10:51 schrieb Stefan Schulze Frielinghaus:
> On Thu, Jun 27, 2024 at 09:45:32AM +0200, Georg-Johann Lay wrote:
>> Am 24.05.24 um 11:13 Am 25.06.24 um 16:03 schrieb Paul Koning:
>>>> On Jun 24, 2024, at 1:50 AM, Stefan Schulze Frielinghaus <stefansf@linux.ibm.com> wrote:
>>>> On Mon, Jun 10, 2024 at 07:19:19AM +0200, Stefan Schulze Frielinghaus wrote:
>>>>> On Fri, May 24, 2024 at 11:13:12AM +0200, Stefan Schulze Frielinghaus wrote:
>>>>>> This implements hard register constraints for inline asm.  A hard register
>>>>>> constraint is of the form {regname} where regname is any valid register.  This
>>>>>> basically renders register asm superfluous.  For example, the snippet
>>>>>>
>>>>>> int test (int x, int y)
>>>>>> {
>>>>>>    register int r4 asm ("r4") = x;
>>>>>>    register int r5 asm ("r5") = y;
>>>>>>    unsigned int copy = y;
>>>>>>    asm ("foo %0,%1,%2" : "+d" (r4) : "d" (r5), "d" (copy));
>>>>>>    return r4;
>>>>>> }
>>>>>>
>>>>>> could be rewritten into
>>>>>>
>>>>>> int test (int x, int y)
>>>>>> {
>>>>>>    asm ("foo %0,%1,%2" : "+{r4}" (x) : "{r5}" (y), "d" (y));
>>>>>>    return x;
>>>>>> }
>>>
>>> I like this idea but I'm wondering: regular constraints specify what sort of value is needed, for example an int vs. a short int vs. a float.  The notation you've shown doesn't seem to have that aspect.
>>>
>>> The other comment is that I didn't see documentation updates to reflect this new feature.
>>>
>>> 	paul
>>>
>>   Stefan Schulze Frielinghaus:
>>> This implements hard register constraints for inline asm.  A hard register
>>> constraint is of the form {regname} where regname is any valid register.  This
>>> basically renders register asm superfluous.  For example, the snippet
>>>
>>> int test (int x, int y)
>>> {
>>>     register int r4 asm ("r4") = x;
>>>     register int r5 asm ("r5") = y;
>>>     unsigned int copy = y;
>>>     asm ("foo %0,%1,%2" : "+d" (r4) : "d" (r5), "d" (copy));
>>>     return r4;
>>> }
>>>
>>> could be rewritten into
>>>
>>> int test (int x, int y)
>>> {
>>>     asm ("foo %0,%1,%2" : "+{r4}" (x) : "{r5}" (y), "d" (y));
>>>     return x;
>>> }
>>
>> Hi, can this also be used in machine descriptions?
>>
>> It would make some insn handling much simpler, for example in
>> the avr backend.
>>
>> That backend has insns that represent assembly sequences in libgcc
>> which have a smaller register footprint than plain calls.  However
>> this requires that such insns have explicit description of which regs
>> go in and out.
>>
>> The current solution uses hard regs, which works, but a proper
>> implementation would use register constraints.  I tries that a while
>> ago, and register constraints lead to a code bloat even in places that
>> don't use these constraints due to the zillions of new register classes
>> like R22_1, R22;2, R22_4, R20_1, R20_2, R20_4 etc. that were required.
>>
>> Your approach would allow to use hard register constraints in insns,
>> and so far the only problem is to determine how much hard regs are
>> used by the constraint.  The gen tools that generates cc code from md
>> would use the operand's machine mode to infer the number of hard regs.
> 
> I have this on my todo list but ignored it for the very first draft.  At
> the moment this already fails because genoutput cannot parse the
> constraint format.
> 
> In my "alpha draft" I implemented this feature by emitting moves to hard
> registers during expand.  This had the limitation that I couldn't

One problem is that you cannot just introduce hard registers at that
time because a hard reg may live across the sequence, see for example
avr.cc::avr_emit3_fix_outputs() and avr_fix_operands().

> support multiple alternatives in combination with hard-register
> constraints.  I'm still not sure whether this is a feature we really
> want or whether it should be rather denied.  Anyhow, with this kind of
> implementation I doubt that this would be feasible for machine
> descriptions.  I moved on with my current draft where the constraint
> manifests during register allocation.  This also allows multiple
> alternatives.  I think one of the (major?) advantages of doing it this
> way is that operands are kept in pseudos which means they are
> automagically saved/restored over function boundaries and what not.  Or
> in other words, the register constraint manifests at the asm boundary
> which is probably what users expect and should be less error prone

As far as I know, a local register variable is only supposed to be
loaded to the specified register when the variable is used as an
operand to some inline asm.  Only in such asm statements, the
variable will live in the specified register.  So "surviving" a
function call is not even a problem to solve with the current local
regvar semantic?

> (again just thinking of implicit code which gets injected as e.g. by
> sanitizers introducing calls etc.).
> 
> So long story short, I would like to look into this but currently it
> doesn't work.  I'm also not sure to which extend this could be used.
> However, once I have some more time I will have a look at the avr
> backend for examples.
> 
> Cheers,
> Stefan

Great.  When you have any questions about the avr backend, don't
hesitate to ask me.

Cheers,
Johann