On 11/01/2016 11:36 AM, Wilco Dijkstra wrote:
Looking at PR77308, one of the issues is that the bswap optimization phase doesn't work on ARM. This is due to an odd check that uses SLOW_UNALIGNED_ACCESS (which is always true on ARM). Since the testcase in PR77308 generates much better code with this patch (~13% fewer instructions), it seems best to remove this odd check.This exposes a problem with SLOW_UNALIGNED_ACCESS - what is it supposed to mean or do? According to its current definition, it means we should never emit an unaligned access for a given mode as it would lead to a trap. However that is not what happens, for example all integer modes on ARM support really fast unaligned access and we generate unaligned instructions without any issues. Some Thumb-1 targets automatically expand unaligned accesses if necessary. So this macro clearly doesn't stop unaligned accesses from being generated. So I want to set it to false for most modes on ARM as they are not slow. However doing so causes incorrect code generation and unaligned traps. How can we differentiate between modes that support fast unaligned access in hardware, modes that get expanded and modes that should never be used in an unaligned access? Bootstrap & regress OK. ChangeLog: 2015-11-01 Wilco Dijkstra <wdijk...@arm.com> gcc/ * tree-ssa-math-opts.c (bswap_replace): Remove test of SLOW_UNALIGNED_ACCESS. testsuite/ * gcc.dg/optimize-bswapdi-3.c: Remove xfail. * gcc.dg/optimize-bswaphi-1.c: Likewise. * gcc.dg/optimize-bswapsi-2.c: Likewise.
I think you'll need to look at bz61320 before this could go in. jeff
