Sema calls HandleVTable() with a bool parameter which is then threaded through
three layers. The only effect of this bool is an early return at the last
layer.
Instead, remove this parameter and call HandleVTable() only if the bool is
true. No intended behavior change.
llvm-svn: 226096
Summary:
The Itanium ABI approach of using offset-to-top isn't possible with the
MS ABI, it doesn't have that kind of information lying around.
Instead, we do the following:
- Call the virtual deleting destructor with the "don't delete the object
flag" set. The virtual deleting destructor will return a pointer to
'this' adjusted to the most derived class.
- Call the global delete using the adjusted 'this' pointer.
Reviewers: rnk
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D5996
llvm-svn: 220993
Clang would previously assert on the following code when targeting MinGW:
struct __declspec(dllimport) S {
virtual ~S();
};
S::~S() {}
Because ~S is a key function and the class is dllimport, we would try to emit a
strong definition of the vtable, with dllimport - which is a conflict. We
should not emit strong vtable definitions for imported classes.
Differential Revision: http://reviews.llvm.org/D5944
llvm-svn: 220532
This moves some memptr specific code into the generic thunk emission
codepath.
Fixes PR20053.
Reviewers: majnemer
Differential Revision: http://reviews.llvm.org/D4613
llvm-svn: 214004
The target method of the thunk will perform the cleanup. This can't be
tested in 32-bit x86 yet because passing something by value would create
an inalloca, and we refuse to generate broken code for that.
llvm-svn: 213976
The pointer for a class's RTTI data comes right before the VFTable but
has no name. To be properly compatible with this, we do the following:
* Create a single GlobalVariable which holds the contents of the VFTable
_and_ the pointer to the RTTI data.
* Create a GlobalAlias, with appropriate linkage/visibility, that points
just after the RTTI data pointer. This ensures that the VFTable
symbol will always refer to VFTable data.
* Create a Comdat with a "Largest" SelectionKind and stick the private
GlobalVariable in it. By transitivity, the GlobalAlias will be a
member of the Comdat group. Using "Largest" ensures that foreign
definitions without an RTTI data pointer will _not_ be chosen in the
final linked image.
Whether or not we emit RTTI data depends on several things:
* The -fno-rtti flag implies that we should never not emit a pointer to
RTTI data before the VFTable.
* __declspec(dllimport) brings in the VFTable from a remote DLL. Use an
available_externally GlobalVariable to provide a local definition of
the VFTable. This means that we won't have any available_externally
definitions of things like complete object locators. This is
acceptable because they are never directly referenced.
To my knowledge, this completes the implementation of MSVC RTTI code
generation.
Further semantic work should be done to properly support /GR-.
llvm-svn: 212125
As suggested by Reid:
- class has GVA_Internal linkage -> internal
- thunk has return adjustment -> weak_odr, to handle evil corner case [1]
- all other normal methods -> linkonce_odr
1. Evil corner case:
struct Incomplete;
struct A { int a; virtual A *bar(); };
struct B { int b; virtual B *foo(Incomplete); };
struct C : A, B { int c; virtual C *foo(Incomplete); };
C c;
Here, the thunk for C::foo() will be emitted when C::foo() is defined, which
might be in a different translation unit, so it needs to be weak_odr.
Differential Revision: http://reviews.llvm.org/D3992
llvm-svn: 210368
This implements the central part of support for dllimport/dllexport on
classes: allowing the attribute on class declarations, inheriting it
to class members, and forcing emission of exported members. It's based
on Nico Rieck's patch from http://reviews.llvm.org/D1099.
This patch doesn't propagate dllexport to bases that are template
specializations, which is an interesting problem. It also doesn't
look at the rules when redeclaring classes with different attributes,
I'd like to do that separately.
Differential Revision: http://reviews.llvm.org/D3877
llvm-svn: 209908
are not associated with any source lines.
Previously, if the Location of a Decl was empty, EmitFunctionStart would
just keep using CurLoc, which would sometimes be correct (e.g., thunks)
but in other cases would just point to a hilariously random location.
This patch fixes this by completely eliminating all uses of CurLoc from
EmitFunctionStart and rather have clients explicitly pass in a
SourceLocation for the function header and the function body.
rdar://problem/14985269
llvm-svn: 205999
Member pointers are mangled as they would be represented at runtime.
They can be a single integer literal, single decl, or a tuple with some
more numbers tossed in. With Clang today, most of those numbers will be
zero because we reject pointers to members of virtual bases.
This change required moving VTableContextBase ownership from
CodeGenVTables to ASTContext, because mangling now depends on vtable
layout.
I also hoisted the inheritance model helpers up to be inline static
methods of MSInheritanceAttr. This makes the AST code that deals with
member pointers much more readable.
MSVC doesn't appear to have stable manglings of null member pointers:
- Null data memptrs in function templates have a mangling collision with
the first field of a non-polymorphic single inheritance class.
- The mangling of null data memptrs changes if you add casts.
- Large null function memptrs in class templates crash MSVC.
Clang uses the class template mangling for null data memptrs and the
function template mangling for null function memptrs to deal with this.
Reviewers: majnemer
Differential Revision: http://llvm-reviews.chandlerc.com/D2695
llvm-svn: 200857
A return type is the declared or deduced part of the function type specified in
the declaration.
A result type is the (potentially adjusted) type of the value of an expression
that calls the function.
Rule of thumb:
* Declarations have return types and parameters.
* Expressions have result types and arguments.
llvm-svn: 200082
Now CodeGenVTables has only one VTableContext object, which is either
Itanium or Microsoft.
Fixes a FIXME with no functionality change intended.
Ideally we could avoid the downcasts by pushing the things that
reference the Itanium vtable context into ItaniumCXXABI.cpp, but we're
not there yet.
llvm-svn: 197845
Unlike Itanium's VTTs, the 'most derived' boolean or bitfield is the
last parameter for non-variadic constructors, rather than the second.
For variadic constructors, the 'most derived' parameter comes after the
'this' parameter. This affects constructor calls and constructor decls
in a variety of places.
Reviewers: timurrrr
Differential Revision: http://llvm-reviews.chandlerc.com/D2405
llvm-svn: 197518
Before this patch GetOrCreateLLVMFunction would add a decl to
DeferredDeclsToEmit even when it was being called by the function trying to
emit that decl.
llvm-svn: 196753
This can happen when we're trying to emit a thunk with available_externally
linkage with optimization enabled but bail because it doesn't make sense
for vararg functions.
PR18098.
llvm-svn: 196658
Instead of storing the vtable offset directly in the function pointer and
doing a branch to check for virtualness at each call site, the MS ABI
generates a thunk for calling the function at a specific vtable offset,
and puts that in the function pointer.
This patch adds support for emitting such thunks. However, it doesn't support
pointers to virtual member functions that are variadic, have an incomplete
aggregate return type or parameter, or are overriding a function in a virtual
base class.
Differential Revision: http://llvm-reviews.chandlerc.com/D2104
llvm-svn: 194827
With this patch we produce alias for cases like
template<typename T>
struct foobar {
foobar() {
}
};
template struct foobar<void>;
We just have to be careful to produce the same aliases in every TU because
of comdats.
llvm-svn: 194000
CodeGenABITypes is a wrapper built on top of CodeGenModule that exposes
some of the functionality of CodeGenTypes (held by CodeGenModule),
specifically methods that determine the LLVM types appropriate for
function argument and return values.
I addition to CodeGenABITypes.h, CGFunctionInfo.h is introduced, and the
definitions of ABIArgInfo, RequiredArgs, and CGFunctionInfo are moved
into this new header from the private headers ABIInfo.h and CGCall.h.
Exposing this functionality is one part of making it possible for LLDB
to determine the actual ABI locations of function arguments and return
values, making it possible for it to determine this for any supported
target without hard-coding ABI knowledge in the LLDB code.
llvm-svn: 193717
Calling convention attributes can add sugar to methods that we have to
look through. This fixes an assertion failure in the provided test
case.
llvm-svn: 192496
This fixes pr13124.
From the discussion at
http://lists.cs.uiuc.edu/pipermail/cfe-dev/2012-June/022606.html
we know that we cannot make funcions in a weak_odr vtable also weak_odr. They
should remain linkonce_odr.
The side effect is that we cannot emit a available_externally vtable unless we
also emit a copy of the function. This also has an issue: If codegen is going
to output a function, sema has to mark it used. Given llvm.org/pr9114, it looks
like sema cannot be more aggressive at marking functions used because
of vtables.
This leaves us with a few unpleasant options:
* Marking functions in vtables used if possible. This sounds a bit sloppy, so
we should avoid it.
* Producing available_externally vtables only when all the functions in it are
already used or weak_odr. This would cover cases like
--------------------
struct foo {
virtual ~foo();
};
struct bar : public foo {
virtual void zed();
};
void f() {
foo *x(new bar);
delete x;
}
void g(bar *x) {
x->~bar(); // force the destructor to be used
}
--------------------------
and
----------------------------------
template<typename T>
struct bar {
virtual ~bar();
};
template<typename T>
bar<T>::~bar() {
}
// make the destructor weak_odr instead of linkonce_odr
extern template class bar<int>;
void f() {
bar<int> *x(new bar<int>);
delete x;
}
----------------------------
These look like corner cases, so it is unclear if it is worth it.
* And finally: Just nuke this optimization. That is what this patch implements.
llvm-svn: 189852
This reverts commit r189320.
Alexey Samsonov and Dmitry Vyukov presented some arguments for keeping
these around - though it still seems like those tasks could be solved by
a tool just using the symbol table. In a very small number of cases,
thunks may be inlined & debug info might be able to save profilers &
similar tools from misclassifying those cases as part of the caller.
The extra changes here plumb through the VarDecl for various cases to
CodeGenFunction - this provides better fidelity through a few APIs but
generally just causes the CGF::StartFunction to fallback to using the
name of the IR function as the name in the debug info.
The changes to debug-info-global-ctor-dtor.cpp seem like goodness. The
two names that go missing (in favor of only emitting those names as
linkage names) are names that can be demangled - emitting them only as
the linkage name should encourage tools to do just that.
Again, thanks to Dinesh Dwivedi for investigation/work on this issue.
llvm-svn: 189421
This was added in r166676 based on PR13942 on the basis that tools may
need debug information for any executable code/function for some fairly
broad/non-specific purposes. It seems to me (as noted in PR14569) that
the major/only purpose is in backtraces, which should generally not
apply to thunks as they won't appear in the stack themselves. By
removing them we fix PR14569 and reduce the size of Clang's debug info.
Strangely enough this doesn't seem to have a substantial impact on
Clang's self-hosted debug info (at least looking at DWO file size) size
at all. Not sure if I failed to test this correctly but I only observed
a 0.004% change in DWO file size over Clang+LLVM.
With thanks to Dinesh Dwivedi for work on this PR.
llvm-svn: 189320
CodeGenFunction is run on only one function - a new object is made for
each new function. I would add an assertion/flag to this effect, but
there's an exception: ObjC properties involve emitting helper functions
that are all emitted by the same CodeGenFunction object, so such a check
is not possible/correct.
llvm-svn: 189277
This might be able to be optimized further by only doing this in the
absence of a key function, but it doesn't look like GCC is doing that so
I'm not rushing to do it just yet.
llvm-svn: 189022
This reverts commit r188687 (reverts r188642 (reverts 188600 (reverts
188576))).
With added test coverage & fix for -gline-tables-only.
Thanks Michael Gottesman for reverting this patch when it demonstrated
problems & providing a reproduction/details to help me track this down.
llvm-svn: 188739
This reverts commit r188642.
This change is causing LTO builds to cause our 16 GB machines to swap and OOM
all weekend. I am going to work with Dave Blaikie to resolve the issue.
Sorry Dave =(.
llvm-svn: 188687
This reverts commit r188600.
r188640/r188639 fixed the root cause of the crash-on-valid that r188600
originally introduced. This now appears to bootstrap debug clang
successfully to the best of my testing.
llvm-svn: 188642
Rafael Espindola