To be more specified, when reading all the codes corresponding to “STRICT_ALIGNMENT” and “SLOW_UNALIGNMENT_ACCESS” in gcc (NOTE, SLOW_UNALIGNMENT_ACCESS is the same as STRICT_ALIGNMENT when it is NOT defined explicitly, this is the case for SPARC)
We can get the following summary: all the special handling on STRICT_ALIGNMENT or SLOW_UNALIGNMENT_ACCESS in these codes have the following common logic: if the memory access is known to be not-aligned well during compilation time, if the targeted platform does NOT support faster unaligned memory access, the compiler will try to make the memory access aligned well. Otherwise, if the targeted platform supports faster unaligned memory access, it will leave the compiler-time known not-aligned memory access as it, later the hardware support will kicked in for these unaligned memory access. this behavior is consistent with the high level definition of STRICT_ALIGNMENT. And also consistent with the M8 misaligned support: if the target is NOT TARGET_MISALIGN, STRICT_ALIGNMENT is 1, all the compiler-time known misaligned memory accesses are adjusted to aligned memory access before RTL generation; on the other hand, if the target is TARGET_MISALIGN, STRICT_ALIGNMENT is 0, the compiler-time known misaligned memory accesses are NOT adjusted, after RTL generation, we will have compiler-time known misaligned memory access, we can use the new misaligned ld/st hardware insns to support these compiler-time known misaligned memory access. hope this is clear. thanks. Qing >> >> Why don't you read the code rather than just relying upon what >> high level description is given by the documentation instead? > > I read the codes before making the change, that’s the reason I ask you to > specify clearly the bad side effect that I didn’t considered yet. > > thanks. > > Qing
