On Thu, 4 Nov 2021, Jeff Law wrote:
> Sometimes the language we're using in email is not as crisp as it should be.
> So
> just to be clear, the canonicalization I'm referring to is only in effect
> within
> a MEM. It does not apply to address calculations that happen outside a MEM.
> I
> think that is consistent with Richard's comments.
Ah, OK then.
> > and then reload substitutes (reg/v:SI 154 [ n_ctrs ]) with the inner MEM
> > as it fails to reload the pseudo and just uses its memory location.
> OK. So what I still don't see is why we would need to re-recognize. You're
> changing code that I thought was only applicable when we were reloading an
> address inside a MEM and if we're inside a MEM, then we shouldn't be seeing an
> ASHIFT. We're replacing the argument of the ASHIFT.
Well, the context of this code (around and including hunk #1) is:
else if (insn_extra_address_constraint
(lookup_constraint (constraints[i])))
{
address_operand_reloaded[i]
= find_reloads_address (recog_data.operand_mode[i], (rtx*) 0,
recog_data.operand[i],
recog_data.operand_loc[i],
i, operand_type[i], ind_levels, insn);
/* If we now have a simple operand where we used to have a
PLUS or MULT, re-recognize and try again. */
if ((OBJECT_P (*recog_data.operand_loc[i])
|| GET_CODE (*recog_data.operand_loc[i]) == SUBREG)
&& (GET_CODE (recog_data.operand[i]) == MULT
|| GET_CODE (recog_data.operand[i]) == PLUS))
{
INSN_CODE (insn) = -1;
retval = find_reloads (insn, replace, ind_levels, live_known,
reload_reg_p);
return retval;
}
so the body of the conditional is specifically executed for an address and
not a MEM; in this particular case matched with the plain "p" constraint.
MEMs are handled with the next conditional right below.
> So, overall, I'm still confused as to why the patch has any effect at all.
Does the explanation above clear your confusion?
Maciej
