[ast-optimizer-branch] Goto/Break/Continue/Switch elimination

Daniel Berlin dberlin@dberlin.org
Thu May 2 11:36:00 GMT 2002


On Thu, 2 May 2002, Zack Weinberg wrote:

> On Thu, May 02, 2002 at 05:16:12PM +0100, Sebastian Pop wrote:
> > 
> > Now I agree that the code becomes verrrrrrrry huge, and even we
> > loose some performances since we introduce lots of tests against
> > temporaries if (T.1==0) ..., but after the SSA we're able to delete
> > a part of the unreachable code.
> 
> I bring it up because I'm concerned that we're chasing all these nifty
> optimization tactics that bulk up the code -- which, on modern
> processors, means you blow the cache and your program runs slow
> anyway.  I think we should be paying a lot more attention to code
> size.
I think you two are talking about two different code sizes (Sebastian, 
correct me if i'm wrong).
Zack is concerned about the result after compilation
Sebastian is talking about the intermediate code size after elimination.

For the case of, say, switch statement elimination, whether we 
increase the end code size is dependent on how many of the if's we 
eventually eliminate.

if SSA-(CCP,DCE) do a good job, and we eliminate half the if blocks, the 
net code size will probably be smaller.

It's dependent on the size of encoding a jump table vs the size of 
encoding it as a bunch of branch/compares.


There's also the fact that we probably eliminate otherwise mispredicted 
branches, etc, whose resulting stalls might more than make up for having 
to fetch from L2 cache.


This is all speculation, of course.  I'll do stuff like run lexer/parser
generators that make direct-encoded scanners/parsers using switch 
statements (re2c, for instance), so that i can get a large number of 
switches and whatnot, and see how it stacks up.

> > zw
> 



More information about the Gcc-patches mailing list