How to avoid de-optimization

[Jan Hubicka]

> 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
an challenge.

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)

Honza
> 
> -- 
> Frank Klemm