On Sat, Jun 21, 2025 at 09:18:43AM -0600, Jeff Law wrote:
>
>
> On 5/20/25 1:22 AM, Stefan Schulze Frielinghaus wrote:
> > This implements error handling for hard register constraints including
> > potential conflicts with register asm operands.
> >
> > In contrast to register asm operands, hard register constraints allow
> > more than just one register per operand. Even more than just one
> > register per alternative. For example, a valid constraint for an
> > operand is "{r0}{r1}m,{r2}". However, this also means that we have to
> > make sure that each register is used at most once in each alternative
> > over all outputs and likewise over all inputs. For asm statements this
> > is done by this patch during gimplification. For hard register
> > constraints used in machine description, error handling is still a todo
> > and I haven't investigated this so far and consider this rather a low
> > priority.
> >
> > There are 9/10 call sides for parse_{input,output}_constraint() which I
> > didn't dare to touch in the first run. If this patch is about to be
> > accepted I could change those call sides and explicitly pass a null
> > pointer instead of overloading those functions as it is done right now.
> > I consider this an implementation nit and didn't want to clutter the
> > patch for reviewing.
> Makes sense. I tend to prefer the overloads when we can easily do so, so
> please make that change. You're going to need a ChangeLog as well.
>
>
> With those changes this is OK as well.
Just to get this right, you prefer the overloads which means I leave the
patch as is, right?
As promised in the cover letter I will also look into the last failing
test. What is a bit annoying, now, that some errors are thrown during
gimplification and some during expand. For example, from pr87600-3.c
test1 fails during expand_asm_stmt() and test{2,3} fail during
parse_input_constraint(). Since after throwing an error during
gimplification we do not reach expand anymore and the dg-warnings for
those fail. Currently I see two ways to fix this. Simply split the
test into two files, or move the error handling part from expand to
gimplification. For the moment I went with the former since that can be
quickly done ;-) and also without my patches some errors are thrown
during gimplification and some during expand, i.e., this kind of problem
already exists. Thus, I don't have a strong opinion here but wanted to
make it clear upfront.
Since the general idea has been approved now, I will do a
bootstrap+regtest on multiple targets and probably also try to build
glibc+kernel with -fdemote-register-asm (I used that in the very
beginning as a benchmark in order to catch odd cases but didn't run
those tests for a while). I will come up with a (hopefully) last patch
series including changelogs. This manual testing might take some time.
Cheers,
Stefan
