This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: ARM condition code register handling
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: Ian Lance Taylor <ian at wasabisystems dot com>
- Cc: gcc at gcc dot gnu dot org, Richard dot Earnshaw at arm dot com
- Date: Tue, 03 Feb 2004 11:19:38 +0000
- Subject: Re: ARM condition code register handling
- Organization: ARM Ltd.
- Reply-to: Richard dot Earnshaw at arm dot com
ian@wasabisystems.com said:
> I looked into enabling TARGET_FIXED_CONDITION_CODE_REGS which I just
> added for this test case on the i386. The initial effect was not
> much, because on the ARM the conditions have the same mode, so CSE
> picks them up.
> However, I noticed that because CSE picks up the conditions, the
> effects of the jump bypass pass are severely blunted. The jump bypass
> pass works by identifying the register which controls a conditional
> jump, but it appears to only look within one basic block. When CSE
> eliminates a setting of the condition code register, the jump bypass
> pass can't figure out what is happening, even when it otherwise could.
> So I put in a bit of code to CSE to not eliminate sets of the
> condition code register until after the jump bypass pass has been run.
> The patch to cse.c, and arm.c, is below.
I've just tried this patch on the CSiBE benchmark, although it is a slight
win, the detailed results are much less conclusive -- some files are not
inconsiderably larger when this patch is used.
Before After Delta
O2 1201677 1201305 -0.03%
Os 1153205 1152741 -0.04%
But on some individual files we have:
bzip2/bzip2 -Os 12884 12936 +0.4%
osdemo/gltestperf -Os 6432 6478 +0.68%
It would be good to establish why some of these tests are now worse, it
might be that by disabling the early CSE of these values we can make
things worse as well.
R.