[cfe-commits] r60993 - in /cfe/trunk: include/clang/AST/DeclObjC.h lib/AST/DeclObjC.cpp lib/Sema/SemaDecl.cpp lib/Sema/SemaDeclObjC.cpp

steve naroff snaroff at apple.com
Wed Dec 17 10:49:05 PST 2008


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
>>> cfe-commits at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20081217/7fdb3462/attachment.html>


More information about the cfe-commits mailing list