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

llvm-svn: 200798

not-yet-completed templated types. getTypeSize() needs a complete type.

rdar://problem/15931354

llvm-svn: 200797

llvm-svn: 200722

llvm-svn: 200711

When a non-trivial parameter is present, clang now gathers up all the
parameters that lack inreg and puts them into a packed struct.  MSVC
always aligns each parameter to 4 bytes and no more, so this is a pretty
simple struct to lay out.

On win64, non-trivial records are passed indirectly.  Prior to this
change, clang was incorrectly using byval on win64.

I'm able to self-host a working clang with this change and additional
LLVM patches.

Reviewers: rsmith

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

llvm-svn: 200597

This fixes PR15768, where the sret parameter and the 'this' parameter
are in the wrong order.

Instance methods compiled by MSVC never return records in registers,
they always return indirectly through an sret pointer.  That sret
pointer always comes after the 'this' parameter, for both __cdecl and
__thiscall methods.

Unfortunately, the same is true for other calling conventions, so we'll
have to change the overall approach here relatively soon.

Reviewers: rsmith

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

llvm-svn: 200587

With this change, we give different results for __alignof than MSVC, but
our record layout is compatible.

Some data member pointers also now have a size that is not a multiple of
their alignment.

Fixes PR18618.

Reviewers: majnemer

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

llvm-svn: 200585

This should fix the clang part of the breakage in r200340.

llvm-svn: 200435

grow into the following virtual base.

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

llvm-svn: 200359

throw-expression, the result is also a glvalue and isn't unnecessarily coerced
to a prvalue.

llvm-svn: 200189

might have a smaller size as compared to the stand-alone type of the base class.
This is possible when the derived class is packed and hence might have smaller
alignment requirement than the base class.

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

llvm-svn: 200031

Some ABIs have different return types for constructors and
destructors, and we're just looking for the end of the function
here. Loosen up the regex.

llvm-svn: 199870

llvm-svn: 199864

This test requires asserts for now, and exception handling has an
awkward structure that leads to extra run lines. Because of this, the
test file's not a great place for other C++ PGO tests, but
instr-profile.cpp is obviously the better name for them.

llvm-svn: 199863