Forgot to put the word "distinction" in the previous comment.
Please take another look at the patch!
================
Comment at: lib/AST/VTableBuilder.cpp:2415-2416
@@ +2414,4 @@
+ BaseOffset = Layout.getBaseClassOffset(CurBase);
+ if (DerivedVBPtrOffset < BaseOffset)
+ continue;
+ const ASTRecordLayout &BaseLayout = Context.getASTRecordLayout(CurBase);
----------------
Reid Kleckner wrote:
> Can this happen? I thought we always just used the first nvbase with vbases.
> If so, I'd make that the loop exit criteria, since it's simpler than this
> vbptr offset comparison.
OK, I've removed this microoptimization and after some thought replaced
"continue" below with "break".
================
Comment at: lib/CodeGen/MicrosoftVBTables.cpp:213
@@ -213,2 +212,3 @@
Offset -= VBPtrSubobject.getBaseOffset() + VBPtrOffset;
- Offsets.push_back(llvm::ConstantInt::get(CGM.IntTy, Offset.getQuantity()));
+ llvm::Constant *&VBOffset = Offsets[GetVBTableIndex(ReusingBase, VBase)];
+ assert(VBOffset == 0 && "The same vbindex seen twice?");
----------------
Reid Kleckner wrote:
> This is silly, we're walking the inheritance graph in a loop. Make something
> that returns the full BaseSetVectorTy, and we can use that to fill in this
> table.
OK, I left the loop in place, but the getVBTableIndex results are now cached
inside MicrosoftVTableContext. I don't think adding an extra interface function
and an extra RD-to-Vector map is worth it for just one function using them.
http://llvm-reviews.chandlerc.com/D2089
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
