On Tue, Jan 13, 2026 at 08:03:48AM -0700, Jeffrey Law wrote:
> 
> 
> On 1/12/2026 1:38 AM, Stefan Schulze Frielinghaus wrote:
> > From: Stefan Schulze Frielinghaus<[email protected]>
> > 
> > With the current implementation, for an alternative like {r0}{r1}...{rn}
> > the last hard register constraint {rn} would always win which is not
> > what users expect.  Therefore, error out in case of multiple hard
> > register constraints in one alternative.
> > 
> > As far as I can tell right now, there is no inherent problem with
> > supporting multiple hard register constraints in one alternative or even
> > ad-hoc register classes.  However, in light of reaching stage 4, this is
> > something for another release.
> > 
> > Likewise, a combination of hard register constraints and regular
> > register constraints is not supported.  Note, a combination of hard
> > register constraints and non-register constraints as e.g. immediate
> > constraints is supported.  This is inspired by the i386 target where
> > constraints like aI are used which could be expressed as {ax}I, too.
> > 
> > gcc/ChangeLog:
> > 
> >     * stmt.cc (parse_output_constraint): Reject multiple hard
> >     register constraints or a combination of hard register
> >     constraints and regular register constraints in one alternative.
> >     (parse_input_constraint): Ditto.
> > 
> > gcc/testsuite/ChangeLog:
> > 
> >     * gcc.dg/asm-hard-reg-error-1.c: Remove tests containing
> >     multiple hard register constraints in one alternative.
> >     * gcc.dg/asm-hard-reg-error-6.c: New test.
> > ---
> >   Bootstrapped and regtested on s390 and x86_64.  Ok for mainline?
> Yea.  Given the infrastructure you've built I think most if not all of what
> would be needed to specify a small set of explicit registers ought to work,
> even if that set of registers doesn't correspond to a register class.
> 
> 
> Do you need to update extend.texi at all to document these cases are syntax
> errors?
> 
> 
> OK with the doc update (if needed).  If the docs are already clear on this,
> then the patch is OK as-is.

I don't mention the possibility of multiple constraints in one
alternative in the docs at all.  I refrained from that in the beginning
since I haven't done extensive testing here.  As presented at the
Cauldron I used the i386 target and replaced every single register
constraint a,b,c,d,S,D with the corresponding hard register constraint
in the machine description for testing.  This included quite a bunch
like {ax}I etc.  Bootstrap and regtest went fine.  Though, this is all
testing I have done beside some artificial ones.  So far I have focused
primarily on fixing issues which prevent the usage of hard register
constraints in alternatives with a single constraint.

I added to the subsubheading Limitations in extend.texi the following to
make at least clear what is not supported:

"Multiple hard register constraints in one alternative are also not supported.
Furthermore, combinations of hard register constraints and regular register
constraints in one alternative are not supported, too."

Thanks,
Stefan

Reply via email to