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
> > > <stefa...@linux.ibm.com> wrote:
> > >
> > > Ping.
> > >
> > > On Mon, Jun 10, 2024 at 07:19:19AM +0200, Stefan Schulze Frielinghaus
> > > wrote:
> > > > Ping.
> > > >
> > > > 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
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
(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
