<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Dec 17, 2008, at 12:08 PM, Fariborz Jahanian wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div><br>On Dec 17, 2008, at 6:34 AM, steve naroff wrote:<br><br><blockquote type="cite"><br></blockquote><blockquote type="cite">On Dec 15, 2008, at 1:02 PM, Douglas Gregor wrote:<br></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Will we need to have the RecordDecl layout for most or all<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Objective-C interfaces? If most programs only need the layout for a<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">small number of interfaces, it might be beneficial to compute the<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">layouts lazily (as we do with the layout of RecordDecls).<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Lay out is needed when a field is referenced. I will look at this<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">later when I am done with code gen.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Okay!<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Just to build on this issue...why does ObjCInterfaceDecl need a 'RecordForDecl' slot at all?<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">From my perspective, this should be computed lazily (as you suggest) and stored separately (using a map that is populated during code generation).<br></blockquote><br>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<br>can be done as well.<br><br></div></blockquote><div><br></div>Hey Fariborz,</div><div><br></div><div>I don't think that storing the slot separately adds a lot of complexity. Here are two arguments for storing RecordForDecl separately:</div><div><br></div><div>#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).</div><div><br></div><div>#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...</div><div><br></div><div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 10px/normal Monaco; ">    <span style="color: #3f6e74">llvm</span>::<span style="color: #3f6e74">DenseMap</span><<span style="color: #3f6e74">ObjCMethodDecl</span>*, <span style="color: #5c2699">std</span>::<span style="color: #5c2699">string</span>> MethodInternalNames;</div><div><br></div>I could have added a 'MethodInternalNames' slot, however decided the map was a much better solution.</div><div><br></div><div>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. </div><div><br></div><div>Agreed?</div><div><br></div><div>snaroff</div><div><br><blockquote type="cite"><div>- Fariborz<br><br><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">snaroff<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite"><span class="Apple-tab-span" style="white-space:pre">      </span>- Doug<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">_______________________________________________<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">cfe-commits mailing list<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><a href="mailto:cfe-commits@cs.uiuc.edu">cfe-commits@cs.uiuc.edu</a><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits</a><br></blockquote></blockquote><blockquote type="cite"><br></blockquote><br></div></blockquote></div><br></body></html>