| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 153163
|
|
|
|
|
|
|
|
| |
run with LIT now and now Dejagnu. dg.exp is no longer needed.
Patch reviewed by Daniel Dunbar. It will be followed by additional cleanup patches.
llvm-svn: 150664
|
|
|
|
|
|
|
|
| |
now. It requires TARGETS=arm.
I cannot reproduce a fixed issue with other targets.
llvm-svn: 149604
|
|
|
|
|
|
|
| |
more than two adjacent ranges needed to be merged. The new version should be
able to handle an arbitrary sequence of adjancent ranges.
llvm-svn: 149588
|
|
|
|
|
|
| |
There was always the current EH. -- Ministry of Truth
llvm-svn: 149335
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I followed three heuristics for deciding whether to set 'true' or
'false':
- Everything target independent got 'true' as that is the expected
common output of the GCC builtins.
- If the target arch only has one way of implementing this operation,
set the flag in the way that exercises the most of codegen. For most
architectures this is also the likely path from a GCC builtin, with
'true' being set. It will (eventually) require lowering away that
difference, and then lowering to the architecture's operation.
- Otherwise, set the flag differently dependending on which target
operation should be tested.
Let me know if anyone has any issue with this pattern or would like
specific tests of another form. This should allow the x86 codegen to
just iteratively improve as I teach the backend how to differentiate
between the two forms, and everything else should remain exactly the
same.
llvm-svn: 146370
|
|
|
|
|
|
|
|
| |
The decision was to pack the bits. Currently no codegen supports this.
Currently, all of the bits in the vector are saved into the same address
in memory.
llvm-svn: 142149
|
|
|
|
|
|
| |
2011-06-09-TailCallByVal and 2010-11-04-BigByval
llvm-svn: 140516
|
|
|
|
| |
llvm-svn: 140213
|
|
|
|
| |
llvm-svn: 139288
|
|
|
|
| |
llvm-svn: 139285
|
|
|
|
| |
llvm-svn: 139058
|
|
|
|
| |
llvm-svn: 139046
|
|
|
|
| |
llvm-svn: 138955
|
|
|
|
| |
llvm-svn: 138900
|
|
|
|
| |
llvm-svn: 138894
|
|
|
|
| |
llvm-svn: 138656
|
|
|
|
| |
llvm-svn: 138606
|
|
|
|
|
|
| |
proper function to do it.
llvm-svn: 138550
|
|
|
|
| |
llvm-svn: 134958
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
patch brings numerous advantages to LLVM. One way to look at it
is through diffstat:
109 files changed, 3005 insertions(+), 5906 deletions(-)
Removing almost 3K lines of code is a good thing. Other advantages
include:
1. Value::getType() is a simple load that can be CSE'd, not a mutating
union-find operation.
2. Types a uniqued and never move once created, defining away PATypeHolder.
3. Structs can be "named" now, and their name is part of the identity that
uniques them. This means that the compiler doesn't merge them structurally
which makes the IR much less confusing.
4. Now that there is no way to get a cycle in a type graph without a named
struct type, "upreferences" go away.
5. Type refinement is completely gone, which should make LTO much MUCH faster
in some common cases with C++ code.
6. Types are now generally immutable, so we can use "Type *" instead
"const Type *" everywhere.
Downsides of this patch are that it removes some functions from the C API,
so people using those will have to upgrade to (not yet added) new API.
"LLVM 3.0" is the right time to do this.
There are still some cleanups pending after this, this patch is large enough
as-is.
llvm-svn: 134829
|
|
|
|
| |
llvm-svn: 134820
|
|
|
|
| |
llvm-svn: 134573
|
|
|
|
| |
llvm-svn: 134516
|
|
|
|
| |
llvm-svn: 133821
|
|
|
|
|
|
|
|
|
| |
for pre-2.9 bitcode files. We keep x86 unaligned loads, movnt, crc32, and the
target indep prefetch change.
As usual, updating the testsuite is a PITA.
llvm-svn: 133337
|
|
|
|
|
|
| |
subsumed by extractvalue.
llvm-svn: 133247
|
|
|
|
|
|
|
| |
syntax and has been long obsolete. As usual, updating the tests is the nasty
part of this.
llvm-svn: 133242
|
|
|
|
|
|
| |
are either unreduced or only test old syntax.
llvm-svn: 133228
|
|
|
|
| |
llvm-svn: 133115
|
|
|
|
|
|
| |
the upper limit on the block IDs since basic blocks might get removed (simplified away) after being initially numbered. Plus the test case, in which SelectionDAGBuilder::visitBr() calls llvm::MachineFunction::removeFromMBBNumbering(), which introduces the hole in numbering leading to an assert in llc (prior to the fix).
llvm-svn: 133113
|
|
|
|
|
|
| |
codegen. Thanks Galina.
llvm-svn: 132706
|
|
|
|
|
|
| |
legalize SDNodes such as BUILD_VECTOR, EXTRACT_VECTOR_ELT, etc.
llvm-svn: 132689
|
|
|
|
|
|
| |
(copyFromParts/copyToParts).
llvm-svn: 132649
|
|
|
|
|
|
|
|
|
| |
patch we add a flag to enable a new type legalization decision - to promote
integer elements in vectors. Currently, the rest of the codegen does not support
this kind of legalization. This flag will be removed when the transition is
complete.
llvm-svn: 132394
|
|
|
|
| |
llvm-svn: 131477
|
|
|
|
|
|
| |
to fix PR9900. I will keep it open until sable is able to comment on it.
llvm-svn: 131294
|
|
|
|
| |
llvm-svn: 129875
|
|
|
|
|
|
|
| |
delete the instruction pointed to by CGP's current instruction
iterator, leading to a crash on the testcase. This fixes PR9578.
llvm-svn: 129200
|
|
|
|
| |
llvm-svn: 128891
|
|
|
|
| |
llvm-svn: 126650
|
|
|
|
| |
llvm-svn: 126574
|
|
|
|
|
|
|
|
| |
The DAGCombiner created illegal BUILD_VECTOR operations.
The patch added a check that either illegal operations are
allowed or that the created operation is legal.
llvm-svn: 125435
|
|
|
|
|
|
| |
llvm.objectsize changes.
llvm-svn: 123771
|
|
|
|
|
|
| |
comes back some day.
llvm-svn: 122982
|
|
|
|
|
|
|
|
| |
In the bottom-up selection DAG scheduling, handle two-address
instructions that read/write unspillable registers. Treat
the entire chain of two-address nodes as a single live range.
llvm-svn: 122472
|
|
|
|
| |
llvm-svn: 122222
|
|
|
|
| |
llvm-svn: 122185
|
|
|
|
|
|
| |
but not complicated enough to merit another test.
llvm-svn: 119898
|
|
|
|
| |
llvm-svn: 118908
|