| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
C99 runtimes don't have exp2).
llvm-svn: 131872
|
|
|
|
|
|
| |
Luis Felipe Strano Moraes!
llvm-svn: 129558
|
|
|
|
|
|
| |
identical to the smul.with.overflow() code.
llvm-svn: 128379
|
|
|
|
|
|
| |
resulting pointer type both have the same size.
llvm-svn: 124987
|
|
|
|
|
|
|
| |
This is the one where one of the branches of the select is another select on
the same condition.
llvm-svn: 124547
|
|
|
|
|
|
|
|
| |
While here, I'd like to complain about how vector is not an aggregate type
according to llvm::Type::isAggregateType(), but they're listed under aggregate
types in the LangRef and zero vectors are stored as ConstantAggregateZero.
llvm-svn: 123956
|
|
|
|
|
|
|
|
| |
point values to their integer representation through the SSE intrinsic
calls. This is the last part of a README.txt entry for which I have real
world examples.
llvm-svn: 123206
|
|
|
|
|
|
| |
file and make it actually test something...
llvm-svn: 123205
|
|
|
|
| |
llvm-svn: 122620
|
|
|
|
| |
llvm-svn: 120316
|
|
|
|
| |
llvm-svn: 119033
|
|
|
|
| |
llvm-svn: 119032
|
|
|
|
|
|
| |
claims).
llvm-svn: 119031
|
|
|
|
| |
llvm-svn: 116462
|
|
|
|
| |
llvm-svn: 116461
|
|
|
|
|
|
|
|
|
| |
logic to use the new APInt methods. Among other things this
implements rdar://8501501 - llvm.smul.with.overflow.i32 should constant fold
which comes from "clang -ftrapv", originally brought to my attention from PR8221.
llvm-svn: 116457
|
|
|
|
| |
llvm-svn: 112889
|
|
|
|
|
|
| |
evaluateICmpRelation wasn't handling blockaddress.
llvm-svn: 94993
|
|
|
|
|
|
|
|
|
|
| |
if one of the vectors didn't have elements (such as undef). Fixes PR 6096.
Fix an issue in the constant folder where fcmp (<2 x %ty>, <2 x %ty>) would
have <2 x i1> type if constant folding was successful and i1 type if it wasn't.
This exposed a related issue in the bitcode reader.
llvm-svn: 94069
|
|
|
|
|
|
|
| |
result int by 8 for the first byte. While normally harmless,
if the result is smaller than a byte, this shift is invalid.
llvm-svn: 93018
|
|
|
|
|
|
| |
folding a load from constant.
llvm-svn: 90545
|
|
|
|
| |
llvm-svn: 85171
|
|
|
|
|
|
| |
Duncan for the nice tiny testcase.
llvm-svn: 84992
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
implements something out of Target/README.txt producing:
_foo: ## @foo
movl 4(%esp), %eax
movapd LCPI1_0, %xmm0
movapd %xmm0, (%eax)
ret $4
instead of:
_foo: ## @foo
movl 4(%esp), %eax
movapd _b, %xmm0
mulpd LCPI1_0, %xmm0
addpd _a, %xmm0
movapd %xmm0, (%eax)
ret $4
llvm-svn: 84942
|
|
|
|
|
|
| |
bytes (i256).
llvm-svn: 84941
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
non-type-safe constant initializers. This sort of thing happens
quite a bit for 4-byte loads out of string constants, unions,
bitfields, and an interesting endianness check from sqlite, which
is something like this:
const int sqlite3one = 1;
# define SQLITE_BIGENDIAN (*(char *)(&sqlite3one)==0)
# define SQLITE_LITTLEENDIAN (*(char *)(&sqlite3one)==1)
# define SQLITE_UTF16NATIVE (SQLITE_BIGENDIAN?SQLITE_UTF16BE:SQLITE_UTF16LE)
all of these macros now constant fold away.
This implements PR3152 and is based on a patch started by Eli, but heavily
modified and extended.
llvm-svn: 84936
|
|
|
|
|
|
|
|
|
| |
allowing it to simplify the crazy constantexprs in the testcases
down to something sensible. This allows -std-compile-opts to
completely "devirtualize" the pointers to member functions in
the testcase from PR5176.
llvm-svn: 84368
|
|
|
|
| |
llvm-svn: 84367
|
|
|
|
| |
llvm-svn: 84364
|
|
|
|
| |
llvm-svn: 83338
|
|
|
|
| |
llvm-svn: 83295
|
|
|
|
| |
llvm-svn: 82389
|
|
|
|
| |
llvm-svn: 82386
|
|
|
|
|
|
| |
CHECK-NOT.
llvm-svn: 82383
|
|
|
|
| |
llvm-svn: 82378
|
|
|
|
|
|
| |
the hopes that the two bitcasts will merge.
llvm-svn: 82371
|
|
|
|
| |
llvm-svn: 82340
|
|
|
|
| |
llvm-svn: 81848
|
|
|
|
|
|
|
|
| |
input filename so that opt doesn't print the input filename in the
output so that grep lines in the tests don't unintentionally match
strings in the input filename.
llvm-svn: 81537
|
|
|
|
| |
llvm-svn: 81257
|
|
|
|
|
|
| |
of using llvm-as, now that opt supports this.
llvm-svn: 81226
|
|
|
|
| |
llvm-svn: 81081
|
|
|
|
| |
llvm-svn: 80769
|
|
|
|
|
|
|
| |
and we get the original pointer type. This doesn't mean that we're
at the first pointer being indexed. Correct the predicate.
llvm-svn: 80762
|
|
|
|
|
|
|
| |
these instructions, no autoupgrade or backwards compatibility support is
provided.
llvm-svn: 74991
|
|
|
|
| |
llvm-svn: 73839
|
|
|
|
| |
llvm-svn: 73835
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
integer and floating-point opcodes, introducing
FAdd, FSub, and FMul.
For now, the AsmParser, BitcodeReader, and IRBuilder all preserve
backwards compatability, and the Core LLVM APIs preserve backwards
compatibility for IR producers. Most front-ends won't need to change
immediately.
This implements the first step of the plan outlined here:
http://nondot.org/sabre/LLVMNotes/IntegerOverflow.txt
llvm-svn: 72897
|
|
|
|
| |
llvm-svn: 57625
|