> Doesn't that also apply to arithmetic on symbols when the offset is NULL?
This can presumably be retrofitted when the offset is null or constant.
> But yes, the codegen example posted shows this kind of difference
> (though it doesn't seem to save anything for that case). I'd have expected
> a more explicit guarding of this case, like with MEM_P (to_rtx)
> && SYMBOL_REF_P (XEXP (to_rtx, 0)) though, eventually even looking
> whether the resulting address is legitimate. But ... doesn't forwprop
> fix this up later anyway?
Not clear IMO, it would need to reassociate.
> The comment before it is also odd and likely only applies to later
> added restrictions. Just to quote it again:
>
> if (offset != 0)
> {
> ...
> /* A constant address in TO_RTX can have VOIDmode, we must not try
> to call force_reg for that case. Avoid that case. */ if (MEM_P (to_rtx)
> && GET_MODE (to_rtx) == BLKmode
> && GET_MODE (XEXP (to_rtx, 0)) != VOIDmode
> && bitsize > 0
> && (bitpos % bitsize) == 0
> && (bitsize % GET_MODE_ALIGNMENT (mode1)) == 0
> && MEM_ALIGN (to_rtx) == GET_MODE_ALIGNMENT (mode1))
> {
> to_rtx = adjust_address (to_rtx, mode1, bitpos /
> BITS_PER_UNIT); bitpos = 0;
> }
>
> to_rtx = offset_address (to_rtx, offset_rtx,
> highest_pow2_factor_for_target (to,
> offset));
> }
Yes, the comment is out-of-sync and not very informative.
--
Eric Botcazou
