https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99422
--- Comment #27 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> Before the patches function process_address_1 used CONSTRAINT__UNKNOWN
> (taken from '=' of constraint "=T,..." and this is wrong) to check validity
> address. It was invalid and LRA added reloads for the address.
Is that because T is a special_memory_constraint or did it happen with a
regular memory_constraint as well?
> After the patches, the function uses CONTSTRAINT_T (taken from 'T'). For
> constraint T sparc code says that the memory address is ok and LRA keeps the
> address and does not generate reloads.
So LRA does not check that the memory is valid for special_memory_constraint or
memory_constraint, and the constraint must do it on its own? Then it's
probably inherited from reload and I guess that
if (! can_create_pseudo_p ()
&& !strict_memory_address_p (Pmode, XEXP (op, 0)))
return 0;
was supposed to do it, in which case David and I missed it when we converted
the port to LRA. This would point to:
diff --git a/gcc/config/sparc/sparc.c b/gcc/config/sparc/sparc.c
index f1504172022..d8860f908e9 100644
--- a/gcc/config/sparc/sparc.c
+++ b/gcc/config/sparc/sparc.c
@@ -9227,7 +9227,7 @@ memory_ok_for_ldd (rtx op)
if (TARGET_ARCH32 && !mem_min_alignment (op, 8))
return 0;
- if (! can_create_pseudo_p ()
+ if ((lra_in_progress || reload_in_progress)
&& !strict_memory_address_p (Pmode, XEXP (op, 0)))
return 0;
Thanks for the investigation, I'll take over from there.
