Question regarding riscv_valid_lo_sum_p vs strict-align

[Andrew Waterman]

IIRC, the reason is that, under strict alignment, it can be assumed
that accessing subfields of an aligned datatype won't cross a boundary
that would cause the high part to change, thus requiring a different
LUI instruction for the subfield access.  Under non-strict alignment,
this assumption doesn't hold.  But I didn't write this part, so I
could be wrong.


On Tue, Dec 31, 2024 at 7:08 AM Xi Ruoyao <xry111@xry111.site> wrote:
>
> Hi,
>
> When -mstrict-align was added for RISC-V, there was a change for
> riscv_valid_lo_sum_p:
>
> @@ -726,7 +733,8 @@ riscv_valid_lo_sum_p (enum riscv_symbol_type
> sym_type, enum
> machine_mode mode)
>    /* We may need to split multiword moves, so make sure that each word
>       can be accessed without inducing a carry.  */
>    if (GET_MODE_SIZE (mode) > UNITS_PER_WORD
> -      && GET_MODE_BITSIZE (mode) > GET_MODE_ALIGNMENT (mode))
> +      && (!TARGET_STRICT_ALIGN
> +         || GET_MODE_BITSIZE (mode) > GET_MODE_ALIGNMENT (mode)))
>      return false;
>
> I cannot get the rationale of this change: shouldn't -mno-strict-align
> make more lo_sum valid, instead of making less lo_sum invalid?  I.e. why
> it's not "TARGET_STRICT_ALIGN && size > align"?
>
> Sorry for my stupidity, and, happy new year in advance.
>
> --
> Xi Ruoyao <xry111@xry111.site>
> School of Aerospace Science and Technology, Xidian University