https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320
--- Comment #54 from rguenther at suse dot de <rguenther at suse dot de> --- On July 17, 2014 5:50:44 PM CEST, "ebotcazou at gcc dot gnu.org" <gcc-bugzi...@gcc.gnu.org> wrote: >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 > >--- Comment #51 from Eric Botcazou <ebotcazou at gcc dot gnu.org> --- >> Ah, we also expand one from a TARGET_MEM_REF: >> >> ;; basic block 76, loop depth 2 >> ;; pred: 79 >> load_dst_215 = MEM[base: ptr_110, offset: 0B]; >> >> and TARGET_MEM_REF only handles the movmisalign case. So it's either >IVOPTs >> not punting properly here (it does for unaligned accesses - grep for >> STRICT_ALIGNMENT) or we need to put a bitfield extraction case into >> TARGET_MEM_REF expansion (IMHO that's missing anyway, IVOPTs is too >much >> pessimized by not considering this). > >TARGET_MEM_REF is supposed to be a valid memory access for the target >though >and, by definition, an unaligned access is not valid for a strict >alignment >target (unless you have a movmisalign pattern), so the problem is the >TARGET_MEM_REF. Ivopts does not change the memory addresses, so even when not using a target_men_ref the access will be unaligned. It's only that we had no way of specifying whether an access is unaligned or not. The addressing mode costs may not reflect reality though. Richard. > >If you want to make IVOPTS generate unaligned TARGET_MEM_REFs, you'll >need to >make sure that the costs are properly adjusted and benchmark the >result.
