[Bug target/65689] [5 Regression][AArch64] S constraint fails for inline asm at -O0

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65689

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to alalaw01 from comment #6)
> Whilst I think this probably would fix the problem - surely this will change
> the meaning of loads of constraints, on loads of platforms? I will of course
> defer to the release manager(s) (!), but IMHO this feels rather risky to do
> at this late stage, i.e. potentially "the cure is worse than the disease"...?

The patch doesn't change meaning of any constraints, just attempts to provide
more precise answers on what constraints allow registers and what allow memory.

> Secondly, do I understand correctly, that the constraint-parsing mechanism
> will only come into play for plain ol' define_constraints, whereeas
> define_register_constraint / define_memory_constraint would provide/override
> with their own values? Does this still leave us with consistent meaning for
> all three kinds of define...constraint?

The new generated function is only used for define_constraint, sure,
define_register_constraint registered constraints are always handled as
*allows_reg = true;, define_memory_constraint are always handled as *allows_mem
= true;, define_address_constraint is handled also like *allows_reg = true;,
all 3 already before and still after the patch unchanged.  Similarly most of
the hardcoded well known architecture independent constraints.  The patch is
only about the case where it previously just made a very conservative last bet,
with the patch it still handles a couple of obvious constraints right and falls
back just for the rest where even genpreds.c doesn't safely know.