This is the mail archive of the
mailing list for the GCC project.
Re: How to avoid de-optimization
- To: Frank Klemm <pfk at fuchs dot offl dot uni-jena dot de>
- Subject: Re: How to avoid de-optimization
- From: Jan Hubicka <jh at suse dot cz>
- Date: Sun, 26 Aug 2001 23:46:39 +0200
- Cc: Jan Hubicka <jh at suse dot cz>, 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> <20010826230822.F2544@fuchs.offl.uni-jena.de>
> 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.
Uh yes, this is always problem - when you are optimizing you don't know
the exact code layout and resulting code size, so it is dificult to decide
what optimizations are workthile and what not. This is making compiler design
I agree that the one of important targets of optimizations is to reduce
code size, as code size limits the overall system peroformance more than
spec-like benchmarks claim.
I am working in this area right now - I am trying to make framework for
recognizing the hot spot functions and do the expensive (code size wise)
optimizations only in this area.
I've laready got about 10% code size savings at no runtime cost.
(and larger scale benchmarks benefits, as the code sometimes fits in the cache)
> Frank Klemm