On 6/26/25 10:46 AM, Stefan Schulze Frielinghaus wrote:
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?
Sorry there was a missing "avoiding".
I tend to prefer avoiding the overloads when we can easily do so.
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.
Understood. In general I prefer diagnostics as early as we can
reasonably do them. So perhaps splitting the test is the way to go.
Jeff
