On Dec 17, 2008, at 12:08 PM, Fariborz Jahanian wrote:
On Dec 17, 2008, at 6:34 AM, steve naroff wrote:
On Dec 15, 2008, at 1:02 PM, Douglas Gregor wrote:
Will we need to have the RecordDecl layout for most or all
Objective-C interfaces? If most programs only need the layout
for a
small number of interfaces, it might be beneficial to compute the
layouts lazily (as we do with the layout of RecordDecls).
Lay out is needed when a field is referenced. I will look at this
later when I am done with code gen.
Okay!
Just to build on this issue...why does ObjCInterfaceDecl need a
'RecordForDecl' slot at all?
From my perspective, this should be computed lazily (as you
suggest) and stored separately (using a map that is populated
during code generation).
Storage lay out is done lazily. Build of the record decl can also be
done lazily. Saving a slot ONTOH, may not be worth the extra
complexity, but certainly
can be done as well.
Hey Fariborz,
I don't think that storing the slot separately adds a lot of
complexity. Here are two arguments for storing RecordForDecl separately:
#1: It is more modular. For example, I just fixed a regression that
should have been isolated to code generation. Unfortunately, the
regression showed up with -fsyntax-only (because the slot was being
mismanaged within the AST).
#2: It scales better. Even though this is just 4 bytes, imagine if
every clang client added overhead to the base AST's! Here is an
example from the Rewriter...
llvm::DenseMap<ObjCMethodDecl*, std::string> MethodInternalNames;
I could have added a 'MethodInternalNames' slot, however decided the
map was a much better solution.
Summary: We need to avoid dumping stuff into our AST's. The AST's
should model the language element, not model application specific
operations on the language element.
Agreed?
snaroff
- Fariborz
snaroff
- Doug
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
