This is the mail archive of the
mailing list for the GCC project.
Re: How to avoid de-optimization
- To: Jan Hubicka <jh at suse dot cz>
- Subject: Re: How to avoid de-optimization
- From: Frank Klemm <pfk at fuchs dot offl dot uni-jena dot de>
- Date: Sun, 26 Aug 2001 23:08:22 +0200
- >Received: (from pfk@localhost)by fuchs.offl.uni-jena.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id XAA04340;Sun, 26 Aug 2001 23:08:22 +0200
- Cc: gcc at gcc dot gnu dot org
- References: <20010826101321.B8344@atrey.karlin.mff.cuni.cz> <20010826133123.A326@fuchs.offl.uni-jena.de> <20010826170729.F17801@atrey.karlin.mff.cuni.cz>
On Sun, Aug 26, 2001 at 05:07:29PM +0200, Jan Hubicka wrote:
> Also many shift+add sequences simplifies back to leas.
> Perhaps we can re-try on spec2000 benchmark, as it is larger scale, but I guess
> that in such benchmark the differences will not be measurable.
> Do you have some testcases?
They are not public available.
Another problem I saw is that jumps are "exploding".
Normally on Intel jumps (JMP, Jcc) are 2 byte long.
If the distance become bigger than -128...+127 the jump instruction becomes
5 (JMP) or 6 (Jcc) byte long. This enlarges code so that other Jumps also
become bigger and so on ...
Especially if you have code with lots of if/while/for statements and less
arithmetic this can increase the code by additional 50 per cent.