On Tue, Nov 1, 2016 at 10:39 PM, Wilco Dijkstra <wilco.dijks...@arm.com> wrote: > Jeff Law <l...@redhat.com> wrote: > >> I think you'll need to look at bz61320 before this could go in. > > I had a look, but there is nothing there that is related - eventually > a latent alignment bug was fixed in IVOpt. Note that the bswap phase > currently inserts unaligned accesses irrespectively of STRICT_ALIGNMENT > or SLOW_UNALIGNED_ACCESS: > > - if (bswap > - && align < GET_MODE_ALIGNMENT (TYPE_MODE (load_type)) > - && SLOW_UNALIGNED_ACCESS (TYPE_MODE (load_type), align)) > - return false; > > If bswap is false no byte swap is needed, so we found a native endian load > and it will always perform the optimization by inserting an unaligned load.
Yes, the general agreement is that the expander can do best and thus we should canonicalize accesses to larger ones even for SLOW_UNALIGNED_ACCESS. The expander will generate the canonical best code (hopefully...). > This apparently works on all targets, and doesn't cause alignment traps or > huge slowdowns via trap emulation claimed by SLOW_UNALIGNED_ACCESS. > So I'm at a loss what these macros are supposed to mean and how I can query > whether a backend supports fast unaligned access for a particular mode. > > What I actually want to write is something like: > > if (!FAST_UNALIGNED_LOAD (mode, align)) return false; > > And know that it only accepts unaligned accesses that are efficient on the > target. > Maybe we need a new hook like this and get rid of the old one? No, we don't need to other hook. Note there is another similar user in gimple-fold.c when folding small memcpy/memmove to single load/store pairs (patch posted but not applied by me -- I've asked for strict-align target maintainer feedback but got none). Now - for bswap I'm only 99% sure that unaligned load + bswap is better than piecewise loads plus manual swap. But generally I'm always in favor of removing SLOW_UNALIGNED_ACCESS / STRICT_ALIGNMENT checks from the GIMPLE side of the compiler. Richard. > Wilco >
