On Thu, Oct 24, 2013 at 10:37 AM, Eric Botcazou <ebotca...@adacore.com> wrote:
>> if bitregion_start/end are used after the adjust_address call then they have
>> to be adjusted (or bitpos left in place). In fact why we apply byte-parts
>> of bitpos here only if offset != 0 is weird.
>
> Presumably to be able to do arithmetic on symbols when the offset is variable,
> which can save one addition in the final code.
Doesn't that also apply to arithmetic on symbols when the offset is NULL?
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?
Either way, bitregion_start/end is clearly wrong after we hit this case.
I'm always fast approving removal of "odd" code (less-code-is-better
doctrine...), but in this case maybe the code can be improved instead.
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));
}
Thanks,
Richard.
> --
> Eric Botcazou
