[RFC][PATCH] Remove a bad use of SLOW_UNALIGNED_ACCESS
Jeff Law
law@redhat.com
Tue Nov 1 20:58:00 GMT 2016
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 <wdijkstr@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
>
More information about the Gcc-patches
mailing list