[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