Commit Graph

231 Commits

Author SHA1 Message Date
Piotr Padlewski 4bed31b9bf Revert "Generating assumption loads of vptr after ctor call (fixed)"
It seems that there is small bug, and we can't generate assume loads
when some virtual functions have internal visibiliy
This reverts commit 982bb7d966947812d216489b3c519c9825cacbf2.

llvm-svn: 247332
2015-09-10 20:18:30 +00:00
Peter Collingbourne 2c7f7e31c4 CFI: Introduce -fsanitize=cfi-icall flag.
This flag causes the compiler to emit bit set entries for functions as well
as runtime bitset checks at indirect call sites. Depends on the new function
bitset mechanism.

Differential Revision: http://reviews.llvm.org/D11857

llvm-svn: 247238
2015-09-10 02:17:40 +00:00
Piotr Padlewski 255652e828 Generating assumption loads of vptr after ctor call (fixed)
Generating call assume(icmp %vtable, %global_vtable) after constructor
call for devirtualization purposes.

For more info go to:
http://lists.llvm.org/pipermail/cfe-dev/2015-July/044227.html

Edit:
Fixed version because of PR24479.
After this patch got reverted because of ScalarEvolution bug (D12719)
Merged after John McCall big patch (Added Address).

http://reviews.llvm.org/D11859

llvm-svn: 247199
2015-09-09 22:20:28 +00:00
John McCall 7f416cc426 Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment.  Introduce APIs on CGBuilderTy to work with Address
values.  Change core APIs on CGF/CGM to traffic in Address where
appropriate.  Require alignments to be non-zero.  Update a ton
of code to compute and propagate alignment information.

As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.

The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned.  Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay.  I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.

Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.

We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment.  In particular,
field access now uses alignmentAtOffset instead of min.

Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs.  For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint.  That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.

ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments.  In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments.  That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.

I partially punted on applying this work to CGBuiltin.  Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.

llvm-svn: 246985
2015-09-08 08:05:57 +00:00
Steven Wu 5528da76ef Revert r246214 and r246213
These two commits causes llvm LTO bootstrap to hang in ScalarEvolution.

llvm-svn: 246282
2015-08-28 07:14:10 +00:00
Piotr Padlewski 81461a4350 Assume loads fix #2
There was linker problem, and it turns out that it is not always safe
to refer to vtable. If the vtable is used, then we can refer to it
without any problem, but because we don't know when it will be used or
not, we can only check if vtable is external or it is safe to to emit it
speculativly (when class it doesn't have any inline virtual functions).
It should be fixed in the future.

http://reviews.llvm.org/D12385

llvm-svn: 246214
2015-08-27 21:35:41 +00:00
Yaron Keren 556b21aa10 Remove and forbid raw_svector_ostream::flush() calls.
After r244870 flush() will only compare two null pointers and return,
doing nothing but wasting run time. The call is not required any more
as the stream and its SmallString are always in sync.

Thanks to David Blaikie for reviewing.

llvm-svn: 244928
2015-08-13 18:12:56 +00:00
Michael Kuperstein 819ad33f63 Mark calls in thunk functions as tail-call optimization candidates
When a thunk is generated with a call to the original adjusted function, 
the thunk appears in the debugger call stack. We want the backend to perform
tail-call optimization on the call, to make it invisible to the debugger.

This fixes PR24235

Patch by: amjad.aboud@intel.com
Differential Revision: http://reviews.llvm.org/D11476

llvm-svn: 244207
2015-08-06 11:57:15 +00:00
Yaron Keren ede603057e Rangify for loops, NFC.
llvm-svn: 243841
2015-08-01 19:11:36 +00:00
Piotr Padlewski 44b4ce8e9b Getting rid of old iterator loops
llvm-svn: 243431
2015-07-28 16:10:58 +00:00
Piotr Padlewski a68a78751f Generating available_externally vtables for outline virtual functions
Generating available_externally vtables for optimizations purposes.
Unfortunatelly ItaniumABI doesn't guarantee that we will be able to
refer to virtual inline method by name.
But when we don't have any inline virtual methods, and key function is
not defined in this TU, we can generate that there will be vtable and
mark it as available_externally.

This is patch will help devirtualize better.
Differential Revision: http://reviews.llvm.org/D11441

llvm-svn: 243090
2015-07-24 04:04:49 +00:00
Rafael Espindola 6bedf4a707 Set comdat when an available_externally thunk is converted to linkonce_odr.
Fixes pr24130.

llvm-svn: 242293
2015-07-15 14:48:06 +00:00
Peter Collingbourne 6fccf95aad CodeGen: Improve CFI type blacklisting mechanism.
We now use the sanitizer special case list to decide which types to blacklist.
We also support a special blacklist entry for types with a uuid attribute,
which are generally COM types whose virtual tables are defined externally.

Differential Revision: http://reviews.llvm.org/D11096

llvm-svn: 242286
2015-07-15 12:15:56 +00:00
Rafael Espindola d6e669458c Set the linkage before setting the visibility.
Otherwise the visibility setting code would not know that a given
function was available_externally.

Fixes PR24097.

llvm-svn: 242012
2015-07-13 06:07:58 +00:00
Peter Collingbourne e570644285 CFI: Emit correct bit set information if RTTI is disabled under MS ABI.
We were previously creating bit set entries at virtual table offset
sizeof(void*) unconditionally under the Microsoft C++ ABI. This is incorrect
if RTTI data is disabled; in that case the "address point" is at offset
0. This change modifies bit set emission to take into account whether RTTI
data is being emitted.

Also make a start on a blacklisting scheme for records.

Differential Revision: http://reviews.llvm.org/D11048

llvm-svn: 241845
2015-07-09 19:56:14 +00:00
Yaron Keren 07d4496ab7 Remove whitespace from start of line, NFC.
llvm-svn: 241272
2015-07-02 14:44:35 +00:00
Peter Collingbourne e286b0e1f2 Fix use-after-free.
llvm-svn: 241121
2015-06-30 22:08:44 +00:00
Peter Collingbourne 45a2401c04 CodeGen: Assign an appropriate comdat to thunks.
Previously we were not assigning a comdat to thunks in the Microsoft ABI,
which would have required us to emit these functions outside of a comdat.
(Due to an inconsistency in how we were emitting objects, we were getting this
right most of the time, but only when compiling with function sections.) This
code generator change causes us to create a comdat for each thunk.

Differential Revision: http://reviews.llvm.org/D10829

llvm-svn: 241102
2015-06-30 19:07:26 +00:00
Peter Collingbourne 86d34a72b3 CodeGen: Factor out some of the bitset entry creation code. NFC.
llvm-svn: 239927
2015-06-17 19:08:05 +00:00
NAKAMURA Takumi c7da6da58e Revert r236879, "Do not emit thunks with available_externally linkage in comdats"
It broke pecoff, at least i686-cygwin.

llvm-svn: 236937
2015-05-09 21:10:07 +00:00
Derek Schuff 2312bd3811 Do not emit thunks with available_externally linkage in comdats
Functions with available_externally linkage will not be emitted to object
files (they will just be undefined symbols), so it does not make sense to
put them in comdats.

Creates a second overload of maybeSetTrivialComdat that uses the GlobalObject
instead of the Decl, and uses that in several places that had the faulty
logic.

Differential Revision: http://reviews.llvm.org/D9580

llvm-svn: 236879
2015-05-08 16:47:21 +00:00
Peter Collingbourne 1a7488afaa Implement CFI type checks for non-virtual calls.
This uses the same class metadata currently used for virtual call and
cast checks.

The new flag is -fsanitize=cfi-nvcall. For consistency, the -fsanitize=cfi-vptr
flag has been renamed -fsanitize=cfi-vcall.

Differential Revision: http://reviews.llvm.org/D8756

llvm-svn: 233874
2015-04-02 00:23:30 +00:00
David Majnemer a03849b2e7 MS ABI: Don't try to emit VF/VB-Tables for extern class templates
There will be an explicit template instantiation in another translation
unit which will provide the definition of the VF/VB-Tables.

This fixes PR22932.

llvm-svn: 232680
2015-03-18 22:04:43 +00:00
Peter Collingbourne 4794190d81 CodeGenModule::EmitVTableBitSetEntries: Add check for identical bit set entries.
No two elements of this array should be the same, but the standard library
may pass the same element as both arguments to this function.

llvm-svn: 230293
2015-02-24 01:12:53 +00:00
Peter Collingbourne a4ccff3281 Implement Control Flow Integrity for virtual calls.
This patch introduces the -fsanitize=cfi-vptr flag, which enables a control
flow integrity scheme that checks that virtual calls take place using a vptr of
the correct dynamic type. More details in the new docs/ControlFlowIntegrity.rst
file.

It also introduces the -fsanitize=cfi flag, which is currently a synonym for
-fsanitize=cfi-vptr, but will eventually cover all CFI checks implemented
in Clang.

Differential Revision: http://reviews.llvm.org/D7424

llvm-svn: 230055
2015-02-20 20:30:56 +00:00
Rafael Espindola f9b1730d41 Add comdat to thunks.
llvm-svn: 226465
2015-01-19 14:02:14 +00:00
Nico Weber b6a5d05a8a Remove ASTConsumer::HandleVTable()'s bool parameter.
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
2015-01-15 04:07:35 +00:00
David Blaikie 4d5c7288cc PR22051: Missing debug location on calls in dtor thunks in Windows.
llvm-svn: 224963
2014-12-29 22:53:52 +00:00
David Blaikie a629c0f658 Use std::find_if instead of manual loop.
llvm-svn: 224960
2014-12-29 22:39:45 +00:00
David Majnemer b9bd6fb397 CodeGen: Virtual dtor thunks shouldn't have this marked as 'returned'
The ARM ABI virtual destructor thunks cannot be marked as 'returned'
because they return undef.

llvm-svn: 221042
2014-11-01 05:42:23 +00:00
David Majnemer 0c0b6d9ac6 MS ABI: Properly call global delete when invoking virtual destructors
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
2014-10-31 20:09:12 +00:00
Hans Wennborg ec53c29932 Don't emit strong vtable definitions for imported classes with key functions (PR21355)
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
2014-10-23 22:40:46 +00:00
Alexey Samsonov 3551e311f0 Simplify a few loops over CallArgList/FunctionArgList. NFC
llvm-svn: 215571
2014-08-13 20:06:24 +00:00
Reid Kleckner ab2090d107 MS ABI: Use musttail for vtable thunks that pass arguments by value
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
2014-07-26 01:34:32 +00:00
Reid Kleckner 3f76ac7daa Remove an extra parameter and C++11 for loop-ify this code
llvm-svn: 214003
2014-07-26 01:30:05 +00:00
Reid Kleckner 19819446eb MS ABI: Don't push destructor cleanups for aggregate parameters in thunks
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
2014-07-25 21:39:46 +00:00
David Majnemer d905da4a5f MS ABI: Reference MSVC RTTI from the VFTable
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
2014-07-01 20:30:31 +00:00
Hans Wennborg c94391d3bf MS ABI: Update the thunk linkage computation
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
2014-06-06 20:04:01 +00:00
Hans Wennborg 853ae94660 Start adding support for dllimport/dllexport on classes (PR11170)
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
2014-05-30 16:59:42 +00:00
Craig Topper 8a13c4180e [C++11] Use 'nullptr'. CodeGen edition.
llvm-svn: 209272
2014-05-21 05:09:00 +00:00
Rafael Espindola bf6e67f2e9 Simplify a few cast<>s.
llvm-svn: 208331
2014-05-08 15:44:45 +00:00
Adrian Prantl 42d71b9906 Debug info: (Bugfix) Make sure artificial functions like _GLOBAL__I_a
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
2014-04-10 23:21:53 +00:00
Ahmed Charles b89843299a Replace OwningPtr with std::unique_ptr.
This compiles cleanly with lldb/lld/clang-tools-extra/llvm.

llvm-svn: 203279
2014-03-07 20:03:18 +00:00
John McCall 8f80a61914 Remove the -fhidden-weak-vtables -cc1 option. It was dead,
gross, and increasingly replaced through other mechanisms.

llvm-svn: 201011
2014-02-08 00:41:16 +00:00
Reid Kleckner 96f8f9339d MS ABI: Mangle member pointer template arguments
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
2014-02-05 17:27:08 +00:00
Alp Toker 314cc81b8c Rename getResultType() on function and method declarations to getReturnType()
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
2014-01-25 16:55:45 +00:00
Reid Kleckner b60a3d5bc1 Eliminate the ItaniumVTableContext object from CodeGenVTables
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
2013-12-20 23:58:52 +00:00
Reid Kleckner 89077a1b00 [ms-cxxabi] The 'most derived' ctor parameter usually comes last
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
2013-12-17 19:46:40 +00:00
Rafael Espindola 94abb8ffed Avoid adding some decls to DeferredDeclsToEmit.
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
2013-12-09 04:29:47 +00:00
Benjamin Kramer 065c61b646 CodeGen: Don't emit linkage on thunks that aren't emitted because they're vararg.
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
2013-12-07 16:12:52 +00:00