DebugInfo: Emit only the declaration of a class template that has an explicit instantiation declaration (& always emit such a type when there's an explicit instantiation definition)

We should only have this optimization fire when the explicit
instantiation definition would cause at  least one member function to be
emitted, thus ensuring that even a compiler not performing this
optimization would still emit the full type information elsewhere.

But we should also pessimize output still by always emitting the
definition when the explicit instantiation definition appears so that at
some point in the future we can depend on that information even when no
code had to be emitted in that TU. (this shouldn't happen very often,
since people mostly use explicit spec decl/defs to reduce code size -
but perhaps one day they could use it to explicitly reduce debug info
size too)

This was worth about 2% for Clang and LLVM - so not a huge win, but a
win. It looks really great for simple STL programs (include <string> and
just declare a string - 14k -> 1.4k of .dwo)

llvm-svn: 202769

This needs to modify a line table test to account for the new lexical
block created to hold the new discriminator value.

llvm-svn: 202754

Some files had CRLF line terminators, some only had a mixture of
CRLF and LF.  Switch to LF.

llvm-svn: 202659

Summary:
This merges VFPtrInfo and VBTableInfo into VPtrInfo, since they hold
almost the same information.  With that change, the vbtable mangling
code can easily be applied to vftable data and we magically get the
correct, unambiguous vftable names.

Fixes PR17748.

Reviewers: timurrrr, majnemer

CC: cfe-commits

Differential Revision: http://llvm-reviews.chandlerc.com/D2893

llvm-svn: 202425

Change this test to not try to emit any IR. (It should fail to, but it tries to create an output file before encountering the error.)

llvm-svn: 202343

generation purposes.
Paired with a commit to llvm.

llvm-svn: 202334

Erroring out until we fix the bug means we don't have to keep chasing down
this same miscompile in a bunch of different places.

Differential Revision: http://llvm-reviews.chandlerc.com/D2890

llvm-svn: 202331

llvm-svn: 202324

Clang is using llvm::StructType::isOpaque() as a way of signaling if
we've finished record type conversion in
CodeGenTypes::isRecordLayoutComplete().  However, Clang was setting the
body of the type before it finished laying out the type as a base type.
Laying out the %class.C.base LLVM type attempts to convert more types,
eventually recursively attempting to layout 'C' again, at which point we
would say that layout was complete, even though we were still in the
middle of it.

By not setting the body, we correctly signal that layout is not
complete, and things work as expected.

At some point, it might be worth refactoring this to avoid looking at
the LLVM IR types under construction.

llvm-svn: 202320

llvm-svn: 202226

llvm-svn: 202208

Paired commit with LLVM.

rdar://problem/13690847

llvm-svn: 202185

Previously the X86 backend would look for the sret attribute and handle
this for us.  inalloca takes that all away, so we have to do the return
ourselves now.

llvm-svn: 202097

Most 64-bit targets define int64_t as long int, and AArch64 should
make same definition to follow LP64 model. In GNU tool chain, int64_t
is defined as long int for 64-bit target. So to get consistent with GNU,
it's better Changing int64_t from 'long long int' to 'long int',
otherwise clang will get different name mangling suffix compared with g++.

llvm-svn: 202004

CGRecordLayoutBuilder was aging, complex, multi-pass, and shows signs of 
existing before ASTRecordLayoutBuilder.  It redundantly performed many 
layout operations that are now performed by ASTRecordLayoutBuilder and 
asserted that the results were the same.  With the addition of support 
for the MS-ABI, such as placement of vbptrs, vtordisps, different 
bitfield layout and a variety of other features, CGRecordLayoutBuilder 
was growing unwieldy in its redundancy.

This patch re-architects CGRecordLayoutBuilder to not perform any 
redundant layout but rather, as directly as possible, lower an 
ASTRecordLayout to an llvm::type.  The new architecture is significantly 
smaller and simpler than the CGRecordLayoutBuilder and contains fewer 
ABI-specific code paths.  It's also one pass.

The architecture of the new system is described in the comments. For the 
most part, the new system simply takes all of the fields and bases from 
an ASTRecordLayout, sorts them, inserts padding and dumps a record. 
Bitfields, unions and primary virtual bases make this process a bit more 
complicated.  See the inline comments.

In addition, this patch updates a few lit tests due to the fact that the 
new system computes more accurate llvm types than CGRecordLayoutBuilder. 
Each change is commented individually in the review.

Differential Revision: http://llvm-reviews.chandlerc.com/D2795

llvm-svn: 201907

Virtual methods expect 'this' to point to the vfptr containing the
virtual method, and this extends to virtual member pointer thunks.  The
relevant vfptr is always at offset zero on entry to the thunk, and no
this adjustment is needed.

Previously we would not include the vfptr adjustment in the member
pointer, and we'd look at the vfptr offset when loading from the vftable
in the thunk.

Fixes PR18917.

llvm-svn: 201835

Sema: Do not assert when dereferencing member pointer using virtual inheritance with an incomplete class type

The MS ABI requires that we determine the vbptr offset if have a
virtual inheritance model.  Instead, raise an error pointing to the
diagnostic when this happens.

This fixes PR18583.

Differential Revision: http://llvm-reviews.chandlerc.com/D2842

llvm-svn: 201824

In the Microsoft ABI, the vftable is laid out as if all methods in every
overload set were declared in reverse order of declaration at the point
of declaration of the first overload in the set.

Previously we only considered virtual methods in an overload set, but
MSVC includes non-virtual methods for ordering purposes.

Fixes PR18902.

llvm-svn: 201722

Summary:
Generally the vector deleting dtor, which we model as a vtable thunk,
takes care of non-virtual adjustment and delegates to the other
destructor variants.  The other non-complete destructor variants assume
that 'this' on entry points to the virtual base subobject that first
declared the virtual destructor.

We need to change the adjustment in both the prologue and the vdtor call
setup.

Reviewers: timurrrr

CC: cfe-commits

Differential Revision: http://llvm-reviews.chandlerc.com/D2821

llvm-svn: 201612

llvm-svn: 201591

Extended qualifiers can appear in many places, refactor the code so it's
more reusable.  Add tests in areas where we've increased compatibility.

llvm-svn: 201574

Pointer types in the MSVC ABI are a bit awkward, the width of the
pointer is considered a kind of CVR qualifier.

Restrict is handled similarly to const and volatile but is mangled after
the pointer width qualifier.

This fixes PR18880.

llvm-svn: 201569

llvm-svn: 201537

Previously, we made one traversal of the AST prior to codegen to assign
counters to the ASTs and then propagated the count values during codegen. This
patch now adds a separate AST traversal prior to codegen for the
-fprofile-instr-use option to propagate the count values. The counts are then
saved in a map from which they can be retrieved during codegen.

This new approach has several advantages:

1. It gets rid of a lot of extra PGO-related code that had previously been
added to codegen.

2. It fixes a serious bug. My original implementation (which was mailed to the
list but never committed) used 3 counters for every loop. Justin improved it to
move 2 of those counters into the less-frequently executed breaks and continues,
but that turned out to produce wrong count values in some cases. The solution
requires visiting a loop body before the condition so that the count for the
condition properly includes the break and continue counts. Changing codegen to
visit a loop body first would be a fairly invasive change, but with a separate
AST traversal, it is easy to control the order of traversal. I've added a
testcase (provided by Justin) to make sure this works correctly.

3. It improves the instrumentation overhead, reducing the number of counters for
a loop from 3 to 1. We no longer need dedicated counters for breaks and
continues, since we can just use the propagated count values when visiting
breaks and continues.

To make this work, I needed to make a change to the way we count case
statements, going back to my original approach of not including the fall-through
in the counter values. This was necessary because there isn't always an AST node
that can be used to record the fall-through count. Now case statements are
handled the same as default statements, with the fall-through paths branching
over the counter increments.  While I was at it, I also went back to using this
approach for do-loops -- omitting the fall-through count into the loop body
simplifies some of the calculations and make them behave the same as other
loops. Whenever we start using this instrumentation for coverage, we'll need
to add the fall-through counts into the counter values.

llvm-svn: 201528

check-clang: Introduce the feature "dw2" to suppress CodeGenCXX/debug-info-namespace.cpp with *-win32.

FIXME: Could we add itanium triple here?
llvm-svn: 201483

llvm-svn: 201477

llvm-svn: 201476

llvm-svn: 201470

1. CHECK-NOT-LABEL is not valid FileCheck.
2. This test would not trigger the CHECK-NOT-LABEL even if 'interface' is
   replaced with 'struct'.

llvm-svn: 201462

We don't support using the MS ABI with non-x86/x86_64 targets anyway.

llvm-svn: 201260

unique them and permits the implementation of dynamic_cast (and
anything else which knows it's working with a complete class
type) to compare their addresses directly.

rdar://16005328

llvm-svn: 201020

This was crashing compilation of DeclContext::buildLookupImpl<>.

llvm-svn: 201013

gross, and increasingly replaced through other mechanisms.

llvm-svn: 201011

llvm-svn: 200940

Properly support fields that come from anonymous unions and structs
when used as template arguments for pointer to data member params.

llvm-svn: 200921

Properly determine the inheritance model when dealing with nullptr:
- If a nullptr template argument is being checked against
  pointer-to-member parameter, nail down an inheritance model.
  N.B. We will chose an inheritance model even if we won't ultimately
  choose the template to instantiate!  Cooky, right?
- Null pointer-to-datamembers have a virtual base table offset of -1,
  not zero. Previously, we chose an offset of 0.

llvm-svn: 200920

Function references always use $1? like function pointers and never $E?
like var decl references.  Static methods are mangled like function
pointers.

llvm-svn: 200869

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

We accept these with a warning in MS mode, but we would previously mark them
invalid, causing us not to emit code for them.

Differential Revision: http://llvm-reviews.chandlerc.com/D2681

llvm-svn: 200815

llvm-svn: 200805