https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88398
--- Comment #38 from Jiu Fu Guo <guojiufu at gcc dot gnu.org> --- (In reply to rguent...@suse.de from comment #37) > On Tue, 2 Jun 2020, guojiufu at gcc dot gnu.org wrote: > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88398 > > ... > > Unaligned reading is supported on some platforms already, and reading > > multi-bytes(64/128bits) takes far less cost than reading 8bits multi-times, > > extremely, dword reading may cost the same cycles as byte reading. > > As the above discussions, there are still a few kinds of stuff need to take > > care of. I’m wondering if we could introduce this as a compiler > > optimization > > in some circumstances. > > The challenge is as always to not regress cases too much where it ends > up not profitable rather than just making it work for SPEC ;) Luckily > chasing SPEC numbers isn't our primary objective. Yes. An optimization would benefit general workloads. I had also tangled about which would be the best way to do, as Jakub and all guys discussed above. Through wider reading (vs. unroll/peel), it may be helpful for a serial byte reading.
