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 <xry...@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 <xry...@xry111.site> > School of Aerospace Science and Technology, Xidian University
