| Commit message (Collapse) | Author | Age | Files | Lines | |
|---|---|---|---|---|---|
| * | [ms-cxxabi] Move VBTableBuilder from CodeGen over to AST/VTableBuilder.cpp | Reid Kleckner | 2014-01-03 | 1 | -233/+0 |
| | | | | | | | | | | | | | | | | | | | | | | Summary: No functionality change. This code should live here long-term because we should be able to use it to compute correct vftable names. It turns out that the most natural way to implement the naming algorithm is to use a caching layer similar to what we already have for virtual table info in VTableContext. Subsequent changes will take advantage of this to fix PR17748, where we have a vbtable name collision. Reviewers: majnemer CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D2499 llvm-svn: 198380 | ||||
| * | Fix vbtable indices when a class shares the vbptr with a non-virtual base | Timur Iskhodzhanov | 2013-11-05 | 1 | -6/+6 |
| | | | | | llvm-svn: 194082 | ||||
| * | Adds Microsoft compatiable C++ record layout code to clang. | Warren Hunt | 2013-10-11 | 1 | -6/+2 |
| | | | | | llvm-svn: 192494 | ||||
| * | Extract ABI-specific parts of MangleContext into separate classes | Timur Iskhodzhanov | 2013-10-03 | 1 | -1/+2 |
| | | | | | | | Reviewed at http://llvm-reviews.chandlerc.com/D1807 llvm-svn: 191878 | ||||
| * | [ms-cxxabi] Emit and install appropriately mangled vbtables | Reid Kleckner | 2013-06-19 | 1 | -0/+236 |
| In Itanium, dynamic classes have one vtable with several different address points for dynamic base classes that can't share vtables. In the MS C++ ABI, each vbtable that can't be shared gets its own symbol, similar to how ctor vtables work in Itanium. However, instead of mangling the subobject offset into the symbol, the unique portions of the inheritance path are mangled into the symbol to make it unique. This patch implements the MSVC 2012 scheme for forming unique vbtable symbol names. MSVC 2010 use the same mangling with a different subset of the path. Implementing that mangling and possibly others is TODO. Each vbtable is an array of i32 offsets from the vbptr that points to it to another virtual base subobject. The first entry of a vbtable always points to the base of the current subobject, implying that it is the same no matter which parent class contains it. Reviewers: rjmccall Differential Revision: http://llvm-reviews.chandlerc.com/D636 llvm-svn: 184309 | |||||
 |
index : bcm5719-llvm | |
| Project Ortega BCM5719 LLVM | Raptor Computing Systems |
| summaryrefslogtreecommitdiffstats |
|