On Wed, Oct 20, 2021 at 8:34 PM H.J. Lu <hjl.to...@gmail.com> wrote: > > On Wed, Oct 20, 2021 at 9:58 AM Richard Biener > <richard.guent...@gmail.com> wrote: > > > > On October 20, 2021 3:19:28 PM GMT+02:00, "H.J. Lu" <hjl.to...@gmail.com> > > wrote: > > >On Wed, Oct 20, 2021 at 4:18 AM Richard Biener > > ><richard.guent...@gmail.com> wrote: > > >> > > >> On Wed, Oct 20, 2021 at 12:40 PM Xu Dianhong <dianho...@gmail.com> wrote: > > >> > > > >> > Many thanks for your explanation. I got the meaning of operands. > > >> > The "addpd b(%rip), %xmm0" instruction needs "b(%rip)" aligned > > >> > otherwise it will rise a "Real-Address Mode Exceptions". > > >> > I haven't considered this situation "b(%rip)" has an address > > >> > dependence of "a(%rip)" before. I think this situation could be > > >> > resolved on the assembler side except for this dummy code like "movapd > > >> > 0x200b37(%rip),%xmm1, ... addpd 0x200b37(%rip),%xmm0 ". > > >> > > >> Of course the compiler will only emit instructions which have the > > >> constraint of aligned memory > > >> when the memory is known to be aligned. That's why I wonder why you > > >> would need such > > >> option. "Real-Address Mode Exceptions" may point to the issue, but I > > >> wonder what's different > > >> in real mode vs. protected mode - even with segmentation the alignment > > >> of objects should > > >> prevail unless you play linker"tricks" that make global objects have > > >> different alignment - but > > >> then it's better to adjust the respective hooks to not falsely claim > > >> such alignment. Consider > > >> for example > > >> > > >> if ((uintptr_t)&a & 0x7) > > >> foo(); > > >> else > > >> bar(); > > >> > > >> GCC will optimize the branch statically to always call foo if 'a' > > >> appears to be aligned, > > >> even if you later try to "override" this with an option. Alignment is > > >> not only about > > >> moves, it's also about knowledge about low bits in addresses and about > > >> alias analysis where alignment constrains how two objects can overlap. > > >> > > >> So - do not lie to the compiler! A late "workaround" avoiding aligned > > >> SSE moves isn't a proper fix. > > >> > > > > > >The motivations are > > > > > >1. AVX non-load/store ops work on unaligned memory. Unaligned > > >load/store on aligned memory is as fast as aligned load/store on Intel > > >AVX machines. The new switch makes load/store consistent with > > >other AVX ops. > > >2. We don't properly align the stack for AVX on Windows. This can > > >be used as a workaround for -mavx on Windows. > > > > But this, with lying that the stack is aligned, causes all of the above > > mentioned issues and thus needs to be fixed by either properly aligning the > > stack or not lying to the compiler that we do. > > > > > > > >We can change TARGET_USE_UNALIGNED_VECTOR_MOVE > > >to require AVX. > > > > But such workaround does not make any sense since it does not fix the > > fundamental underlying problem. > > > > There is a long standing desire to remove alignment checking (#AC(0)). > For integer operations, alignment checking is disabled in hardware. > For AVX ops, alignment checking is disabled in hardware for non-load/store > instructions. But we can't disable alignment checking in hardware for > aligned load/store instructions. -muse-unaligned-vector-move implements > disabling alignment checking for all AVX ops.
No, it does not - it just emits unaligned moves. The compiler still assumes aligned memory. So whatever reason you have for disabling alignment checking for memory that is known to be aligned, I don't see it. If you want to "fix" broken user code then this doesn't do it. If you want to avoid the penalty for runtime stack alignment then you simply have to change the ABI(?) to not require vector types to have big alignment. Richard. > > -- > H.J.
