not stop it by using RAII.

llvm-svn: 99832

llvm-svn: 99831

a 2.47% speedup in 403.gcc.

llvm-svn: 99830

When collecting virtual bases it's very important to use the canonical type of the base class. Otherwise, we might add the same virtual base class twice if the virtual base is an instantiated template. Fixes PR6251.

llvm-svn: 99829

llvm-svn: 99828

Most of these were unused, some of them were wrong and unused (isS16Constant<short>,
isS10Constant<short>).

llvm-svn: 99827

llvm-svn: 99826

John Tytgat

llvm-svn: 99825

llvm-svn: 99824

on one .i file from 403.gcc by 0.5%.

llvm-svn: 99823

PR6661, patch by Ori Avtalion!

llvm-svn: 99821

llvm-svn: 99820

"the bigstack patch for SPU, with testcase. It is essentially the patch committed as 97091, and reverted as 97099, but with the following additions:
-in vararg handling, registers are marked to be live, to not confuse the register scavenger
-function prologue and epilogue are not emitted, if the stack size is 16. 16 means it is empty - there is only the register scavenger emergency spill slot, which is not used as there is no stack."

llvm-svn: 99819

llvm-svn: 99818

Anton Yartsev!

llvm-svn: 99817

This is same as r99772 (which was reverted) with just one meaningful difference where two source lines exchanged their positions.

llvm-svn: 99816

llvm-svn: 99815

llvm-svn: 99812

end of a struct/class/union in C++, from Justin Bogner!

llvm-svn: 99811

llvm-svn: 99807

Fix a nasty bug in the virtual base computation which would lead to us initializing virtual bases in the wrong order.

llvm-svn: 99806

This patch moves some methods from QualType to Type and changes the users to
use -> instead of .

llvm-svn: 99805

More vtable work - it's not possible to use the new vtable code for everything by setting a flag inside CGVtable.cpp. My plan is to run some tests and bootstrap and once that's done flip the bit.

llvm-svn: 99804

llvm-svn: 99803

Sprinkle some sed dust over check-ztt to make it work with newer clang asm output. (I am not a sed expert so this might be terribly inefficient :)

llvm-svn: 99802

Only add thunks for the most derived class. This fixes some link errors I was seeing in files generated by the vtable tester utility.

llvm-svn: 99801

Flip the switch to always get vtables from the VTT when necessary, I've verified that clang bootstraps with this.

llvm-svn: 99800

llvm-svn: 99799

llvm-svn: 99798

doesn't need to be stable because the patterns are fully ordered.

Add a first level sort predicate that orders patterns in this
order:  1) scalar integer operations 2) scalar floating point 
3) vector int 4) vector float.  This is a trivial sort on their
top level pattern type so it is nice and transitive.  The
benefit of doing this is that simple integer operations are
much more common than insane vector things and isel was trying
to match the big complex vector patterns before the simple
ones because the complexity of the vector operations was much
higher.  Since they can't both match, it is best (for compile
time) to try the simple integer ones first.

This cuts down the # failed match attempts on real code by
quite a bit, for example, this reduces backtracks on crafty
(as a random example) from 228285 -> 188369.

llvm-svn: 99797

llvm-svn: 99796

patterns within the generated matcher.  This works great except
that the sort fails because the relation defined isn't 
transitive.  I have a much simpler solution coming next, but want
to archive the code.

llvm-svn: 99795

comment in the generated table.

llvm-svn: 99794

llvm-svn: 99793

Make sure to sort the vtable thunks by their vtable index :) With this we now pass the test from http://www.codesourcery.com/public/cxx-abi/abi-examples.html#vtable-ctor successfully.

llvm-svn: 99792

llvm-svn: 99791

llvm-svn: 99790

These instructions use byte index in a control vector (M:Vm) to lookup byte
values in a table and generate a new vector (D:Vd).  The table is specified via
a list of vectors, which can be:

{Dn}
{Dn D<n+1>}
{Dn D<n+1> D<n+2>}
{Dn D<n+1> D<n+2> D<n+3>}

llvm-svn: 99789

llvm-svn: 99788

Use construction vtables when needed. This is currently guarded by -fdump-vtable-layouts since it doesn't work 100% yet :)

llvm-svn: 99787