[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