https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65215
--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Thomas Preud'homme from comment #5) > (In reply to Richard Biener from comment #4) > > (In reply to Jakub Jelinek from comment #1) > > > Created attachment 34879 [details] > > > gcc5-pr65215.patch > > > > > > Untested fix. There are still issues left, e.g. I can't understand the > > > "bswap &&" part in > > > if (bswap > > > && align < GET_MODE_ALIGNMENT (TYPE_MODE (load_type)) > > > && SLOW_UNALIGNED_ACCESS (TYPE_MODE (load_type), align)) > > > return false; > > > Don't you use the new MEM_REF even for the !bswap (aka nop) case? So, I > > > don't see how it would be safe to generate that. > > > And the testsuite coverage of this is definitely suboptimal, from > > > endianity > > > POV, bitfields etc. > > > > I suggested that change (remove bswap &&) multiple times, but it got lost > > appearantly. (I even remember applying that change myself!?) > > > I remember the contrary as this was the reason PR61320 was investigated in > the first place. This idea is that if it's unaligned the expander will take > care of this and that they would be at least as efficient as what the user > code was doing to avoid doing an unaligned load. Ah indeed. The idea is that the expander should be able to produce the most optimal and canonical form for an unaligned load on those targets, especially for say loading a 4-byte value from a 2-byte aligned source where the source had 4 individual char loads. > I'm happy to revisit that position though. No - I just stand corrected. > Best regards, > > Thomas
