| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 154281
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
intrinsic syntax.
Now that this is explicitly covered, I plan to upgrade the existing test
suite to use an explicit immediate. Note that I plan to specify 'true'
in most places rather than the auto-upgraded value as that is the far
more common value to end up here as that is the value coming from GCC's
builtins. The only place I'm likely to put a 'false' in is when testing
x86 which actually has different instructions for the two variants.
llvm-svn: 146369
|
|
|
|
|
|
|
| |
trampoline forms. Both of these were correct in LLVM 3.0, and we don't
need to support LLVM 2.9 and earlier in mainline.
llvm-svn: 145174
|
|
|
|
| |
llvm-svn: 145167
|
|
|
|
|
|
| |
by David Meyer on llvmdev.
llvm-svn: 140040
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
init.trampoline and adjust.trampoline intrinsics, into two intrinsics
like in GCC. While having one combined intrinsic is tempting, it is
not natural because typically the trampoline initialization needs to
be done in one function, and the result of adjust trampoline is needed
in a different (nested) function. To get around this llvm-gcc hacks the
nested function lowering code to insert an additional parent variable
holding the adjust.trampoline result that can be accessed from the child
function. Dragonegg doesn't have the luxury of tweaking GCC code, so it
stored the result of adjust.trampoline in the memory GCC set aside for
the trampoline itself (this is always available in the child function),
and set up some new memory (using an alloca) to hold the trampoline.
Unfortunately this breaks Go which allocates trampoline memory on the
heap and wants to use it even after the parent has exited (!). Rather
than doing even more hacks to get Go working, it seemed best to just use
two intrinsics like in GCC. Patch mostly by Sanjoy Das.
llvm-svn: 139140
|
|
|
|
| |
llvm-svn: 138606
|
|
|
|
|
|
|
|
|
|
| |
of the instruction.
Note that this change affects the existing non-atomic load and store
instructions; the parser now accepts both forms, and the change is noted
in the release notes.
llvm-svn: 137527
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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: 134819
|
|
|
|
|
|
|
| |
top level type without a specified number. This syntax isn't documented
and blocks forward progress.
llvm-svn: 133371
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
been
needed since llvm-gcc 3.4 days.
llvm-svn: 133248
|
|
|
|
|
|
| |
was replaced with return of a "first class aggregate".
llvm-svn: 133245
|
|
|
|
|
|
| |
are either unreduced or only test old syntax.
llvm-svn: 133228
|
|
|
|
|
|
| |
names for named metadata nodes.
llvm-svn: 133166
|
|
|
|
|
|
|
| |
or instruction cache access. Update the targets to match it and also teach
autoupgrade.
llvm-svn: 132976
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
happily accept things like "sext <2 x i32> to <999 x i64>". It would
also accept "sext <2 x i32> to i64", though the verifier would catch
that later. Fixed by having castIsValid check that vector lengths match
except when doing a bitcast. (2) When creating a cast instruction, check
that the cast is valid (this was already done when creating constexpr
casts). While there, replace getScalarSizeInBits (used to allow more
vector casts) with getPrimitiveSizeInBits in getCastOpcode and isCastable
since vector to vector casts are now handled explicitly by passing to the
element types; i.e. this bit should result in no functional change.
llvm-svn: 131532
|
|
|
|
|
|
| |
<rdar://problem/8460511>
llvm-svn: 130791
|
|
|
|
| |
llvm-svn: 129419
|
|
|
|
| |
llvm-svn: 129403
|
|
|
|
|
|
|
|
|
| |
Now that we have a first-class way to represent unaligned loads, the unaligned
load intrinsics are superfluous.
First part of <rdar://problem/8460511>.
llvm-svn: 129401
|
|
|
|
|
|
|
| |
returning a scalar value in a function whose return type is a single-
element structure or array.
llvm-svn: 128810
|
|
|
|
| |
llvm-svn: 127824
|
|
|
|
|
|
| |
Factor some code better.
llvm-svn: 125006
|
|
|
|
|
|
|
|
| |
instcombine xform to exercise this.
Nothing forms exact udivs yet though. This is progress on PR8862
llvm-svn: 124992
|
|
|
|
| |
llvm-svn: 124209
|
|
|
|
| |
llvm-svn: 123529
|
|
|
|
| |
llvm-svn: 123358
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a unnamed_addr bit to global variables and functions. This will be used
to indicate that the address is not significant and therefore the constant
or function can be merged with others.
If an optimization pass can show that an address is not used, it can set this.
Examples of things that can have this set by the FE are globals created to
hold string literals and C++ constructors.
Adding unnamed_addr to a non-const global should have no effect unless
an optimization can transform that global into a constant.
Aliases are not allowed to have unnamed_addr since I couldn't figure
out any use for it.
llvm-svn: 123063
|
|
|
|
|
|
|
|
| |
out-of-bounds indexing.
Also add asserts that the indices are valid in InsertValueInst::init(). ExtractValueInst already asserts when constructed with invalid indices.
llvm-svn: 120956
|
|
|
|
|
|
|
|
|
| |
it in with the SSSE3 instructions.
Steward! Could you place this chair by the aft sun deck? I'm trying to get away
from the Astors. They are such boors!
llvm-svn: 115552
|
|
|
|
| |
llvm-svn: 115456
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The x86_mmx type is used for MMX intrinsics, parameters and
return values where these use MMX registers, and is also
supported in load, store, and bitcast.
Only the above operations generate MMX instructions, and optimizations
do not operate on or produce MMX intrinsics.
MMX-sized vectors <2 x i32> etc. are lowered to XMM or split into
smaller pieces. Optimizations may occur on these forms and the
result casted back to x86_mmx, provided the result feeds into a
previous existing x86_mmx operation.
The point of all this is prevent optimizations from introducing
MMX operations, which is unsafe due to the EMMS problem.
llvm-svn: 115243
|
|
|
|
| |
llvm-svn: 113783
|
|
|
|
|
|
| |
#uses comments, with a testcase.
llvm-svn: 112906
|
|
|
|
| |
llvm-svn: 112889
|
|
|
|
|
|
| |
being actively maintained, improved, or extended.
llvm-svn: 112356
|
|
|
|
|
|
| |
alignment, fixing silent truncation of alignment values.
llvm-svn: 109653
|
|
|
|
|
|
|
|
|
| |
alloca instructions (constrained by their internal encoding),
and add error checking for it. Fix an instcombine bug which
generated huge alignment values (null is infinitely aligned).
This fixes undefined behavior noticed by John Regehr.
llvm-svn: 109643
|
|
|
|
| |
llvm-svn: 100705
|
|
|
|
| |
llvm-svn: 96011
|
|
|
|
|
|
| |
to function-local IR were not getting written by BitcodeWriter; solution is for these metadata to be enumerated just like global metadata.
llvm-svn: 95467
|
|
|
|
|
|
| |
that it refers to; fix is to not enumerate operands of function-local metadata until after all instructions have been enumerated
llvm-svn: 95269
|
|
|
|
|
|
|
|
|
| |
its first argument, via function-local metadata (instead of via a bitcast).
This patch also cleans up code that expects there to be a bitcast in the first argument and testcases that call llvm.dbg.declare.
It also strips old llvm.dbg.declare intrinsics that did not pass metadata as the first argument.
llvm-svn: 93531
|
|
|
|
|
|
| |
auto-upgraded
llvm-svn: 93515
|
|
|
|
|
|
|
|
| |
its first argument, via function-local metadata (instead of via a bitcast).
This patch also cleans up code that expects there to be a bitcast in the first argument and testcases that call llvm.dbg.declare.
llvm-svn: 93504
|
|
|
|
| |
llvm-svn: 93408
|