[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