| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
not stop it by using RAII.
llvm-svn: 99832
|
| |
|
|
| |
llvm-svn: 99831
|
| |
|
|
|
|
| |
a 2.47% speedup in 403.gcc.
llvm-svn: 99830
|
| |
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
codegen time
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
|
| |
|
|
|
|
|
|
| |
AsmPrinter.cpp.
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
|
| |
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
output. (I am not a sed expert so this might be terribly inefficient :)
llvm-svn: 99802
|
| |
|
|
|
|
| |
was seeing in files generated by the vtable tester utility.
llvm-svn: 99801
|
| |
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
now pass the test from http://www.codesourcery.com/public/cxx-abi/abi-examples.html#vtable-ctor successfully.
llvm-svn: 99792
|
| |
|
|
| |
llvm-svn: 99791
|
| |
|
|
|
|
| |
vtable.
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
|
| |
|
|
|
|
| |
-fdump-vtable-layouts since it doesn't work 100% yet :)
llvm-svn: 99787
|
| |
|
|
|
|
| |
initializer and we weren't storing the secondary virtual pointer indices.
llvm-svn: 99786
|
| |
|
|
|
|
| |
(as they already are in practise).
llvm-svn: 99785
|
| |
|
|
| |
llvm-svn: 99783
|
| |
|
|
| |
llvm-svn: 99778
|
| |
|
|
|
|
| |
pointer for all bases, even those without a vtable pointer :)
llvm-svn: 99777
|
| |
|
|
| |
llvm-svn: 99776
|
| |
|
|
|
|
| |
vtable pointer for non-virtual primary bases. We also do a pre-order traversal of the class hierarchy; this is necessary in order to get the right vbase offset offsets in base ctors/dtors.
llvm-svn: 99775
|
| |
|
|
| |
llvm-svn: 99774
|
| |
|
|
| |
llvm-svn: 99773
|
| |
|
|
| |
llvm-svn: 99772
|