[cfe-commits] r57149 - /cfe/trunk/lib/AST/Expr.cpp

Chris Lattner sabre at nondot.org
Sun Oct 5 23:25:54 PDT 2008


On Oct 5, 2008, at 10:42 PM, Daniel Dunbar wrote:

> This is nice. For non-keyword identifiers which still have some  
> special
> treatment, could we allow the same sort of treatment?
>
> I'm thinking about the various Identifier* variables which are set  
> up in
> places like Parser::Initialize(). The idea would be to have some  
> notion
> of a "known" identifier.
>
> Code which currently compares an identifier to some stored Identifier*
> --
> &II == SuperID
> --
> would be replaced with something like
> --
> II->getKnownID() == KnownIDs::super.
>
> This centralizes the mechanism and avoids having various Identifier*s
> initialized and stored across scattered locations. The cost is that  
> the
> known ID table would presumably be centralized, and we would need
> some bits in Identifier (probably just one, since KnownIDs could be
> forced to be disjoint with Builtins, so we could reuse the builtin  
> bits).
>
> Good idea or bad idea?

Not entirely good and not entirely bad.  :)  It depends on how many  
identifiers you're talking about here.  Currently, the tradeoff is  
that the identifiers need to be populated when the compiler starts up,  
so the more identifiers with magic stuff hanging off them, the more  
that needs to be set up at startup-time.

I supposed the best way to solve this is the push into the "first  
instance of an identifier" codepath.  It would be reasonable and nice  
to do a quick hash lookup from a static hash table to see if the new  
identifier is "known".  If so, the new identifierinfo would be  
populated with info from that table.

Does that make sense?

-Chris



More information about the cfe-commits mailing list