This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

PING [ARM, RFC] Support unaligned access for modern ARM processors


PING.

On 12/28/2010 08:10 PM, Jie Zhang wrote:
Hi,

This patch adds ARM unaligned access support to GCC. It adds a new
option -m(no-)unaligned-access to ARM target. The default setting is:

Enable -munaligned-access by default for
- all ARMv6 architecture-based processors
- ARMv7-A, ARMv7-R, and ARMv7-M architecture-based processors.

Disable -munaligned-access by default for
- all pre-ARMv6 architecture-based processors
- ARMv6-M architecture-based processors.

A new hook TARGET_CANNOT_RELOAD_MEM_ADDRESS is added. When a MEM is
invalid because its address is misaligned, reloading its address into a
register cannot make it valid. This hook is used to tell GCC not to
reload memory address in such cases. Anyway I think GCC should discover
this by itself, i.e. reloading memory address does not help, then try
reload the MEM instead. But it seems more complicated to implement.

The testing has been mainly done for a backported version for our
internal 4.5 branch. It has no regressions when testing gcc, g++ and
libstdc++ with "-march=armv7-a -mfloat-abi=softfp -mfpu=neon" multilib
on a Cortex-A8 board.

I also use it (patched internal GCC 4.5) to build a Linux kernel image
from recent linux-2.6 git tree with omap2plus_defconfig, the kernel
boots well on OMAP4 pandaboard. The code size of Linux kernel is reduced
by about 0.5%.

I also benchmarked it using EEMBC. There are no noticeable changes when
optimize for speed for both arm-none-eabi and arm-none-linux-gnueabi
targets. But two tests have large performance improvements when optimize
for size, 25% and 16%, for arm-none-linux-gnueabi target on a Cortex-A8
board. The code size changes are small.

No changes seen on SPEC2000 except 186.crafty from 174 to 183.

As for FSF mainline, there are no regressions for the default multilib.
I'm now regression testing for "-mcpu=cortex-a8 -mfpu=neon
-mfloat-abi=softfp" multilib. I will also do some performance
benchmarking with EEMBC and SPEC2000. But all these testing will take
several days. If anyone can help me, I will appreciate.

Any comments are welcome.


Regards,


--
Jie Zhang


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]