https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320
--- Comment #27 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Thomas Preud'homme from comment #23) > (In reply to Eric Botcazou from comment #20) > > > > > Maybe a better solution for sparc would be to add a switch for this pass > > > and > > > disable it by default on sparc. What do you think about that? > > > > There is nothing special about SPARC, it's the same for every strict > > alignment architecture supported by GCC and SLOW_UNALIGNED_ACCESS is a valid > > predicate. > > My point was two fold: > > 1) Even if the pass does nothing for unaligned access on target where this > is slow, a bunch of code is still executed to determine that the access is > unaligned (in fact most of the pass is executed before the address of the > access is known). > > 2) For some unaligned access the rewrite might be interesting, like > rewriting this: > > tab[1] | (tab [2] << 8) | (tab[3] << 16) | (tab[4] << 24) > > into this: > > *((uint32_t *) &tab[1]) > > (considering tab[0] to be 4 byte aligned) which could end up doing one 32 > bit load at addresses &tab[0], one shift and one byte load at address > &tab[4]. Yes, I think that the load may be written in non-optimal way and the expander has a better chance to produce optimal code (considering insv availability). I fear that if we install this workaround we'll never get at the actual issue (which might be just PR61306?)
