[cfe-dev] Preprocessor::LookNext

Argiris Kirtzidis akyrtzi at gmail.com
Tue Jul 8 07:28:46 PDT 2008


Chris Lattner wrote:
> Is there a specific problem with calling LookAhead(0)?  To me, this is 
> a performance optimization tweak... I'd rather do this sort of thing 
> when more of the C++ front-end is in place.  This would give us better 
> grounds for profiling and determine whether it is actually a win in 
> the end.

Yes, it is only a performance optimization tweak; I wanted to find out 
if it is acceptable to optimize just LookAhead(0) (which, by the way, is 
currently the only use for LookAhead).

>
> Adding a "LookNext()" method to the preprocessor as a helper for 
> LookAhead(0) would be ok if you think it would be significantly useful 
> though.  Also, LookAhead could obviously be improved :).
>
> [....]    While always having peektok available is nice, it adds 
> significant cost to the hotest part of the C preprocessor.  I would 
> expect a significant slowdown from the patch on large .i files with 
> -Eonly for example (which spends almost all time in this code).

With a slight modification, the PeekedToken check can be avoided for the 
common case:

>   void Lex(Token &Result) {
>     if (CurLexer)
>       CurLexer->Lex(Result);
>     else
>       CurTokenLexer->Lex(Result);
>     else {
>       // We have a peeked token that hasn't been consumed yet.
>       Result = PeekedToken;
>       ConsumedPeekedToken();
>       return;
>     }
>   }

LookNext would cache CurLexer,CurTokenLexer before setting them to null, 
and ConsumedPeekedToken would restore them.

> are you sure it would be completely unreasonable to refactor the C++ 
> grammar to avoid the look-ahead in the common case?

I'll go ahead with GetLookAhead; after I post a patch and the code is 
there for reviewing, it will be a lot easier to discuss about this.


-Argiris



More information about the cfe-dev mailing list