| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 150918
|
| |
|
|
|
|
|
| |
were no 'unwind' instructions being generated before this, so this is in effect
a no-op.
llvm-svn: 149906
|
| |
|
|
| |
llvm-svn: 149849
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The purpose of refactoring is to hide operand roles from SwitchInst user (programmer). If you want to play with operands directly, probably you will need lower level methods than SwitchInst ones (TerminatorInst or may be User). After this patch we can reorganize SwitchInst operands and successors as we want.
What was done:
1. Changed semantics of index inside the getCaseValue method:
getCaseValue(0) means "get first case", not a condition. Use getCondition() if you want to resolve the condition. I propose don't mix SwitchInst case indexing with low level indexing (TI successors indexing, User's operands indexing), since it may be dangerous.
2. By the same reason findCaseValue(ConstantInt*) returns actual number of case value. 0 means first case, not default. If there is no case with given value, ErrorIndex will returned.
3. Added getCaseSuccessor method. I propose to avoid usage of TerminatorInst::getSuccessor if you want to resolve case successor BB. Use getCaseSuccessor instead, since internal SwitchInst organization of operands/successors is hidden and may be changed in any moment.
4. Added resolveSuccessorIndex and resolveCaseIndex. The main purpose of these methods is to see how case successors are really mapped in TerminatorInst.
4.1 "resolveSuccessorIndex" was created if you need to level down from SwitchInst to TerminatorInst. It returns TerminatorInst's successor index for given case successor.
4.2 "resolveCaseIndex" converts low level successors index to case index that curresponds to the given successor.
Note: There are also related compatability fix patches for dragonegg, klee, llvm-gcc-4.0, llvm-gcc-4.2, safecode, clang.
llvm-svn: 149481
|
| |
|
|
|
|
|
| |
we should (theoretically optimize and codegen ConstantDataVector as well
as ConstantVector.
llvm-svn: 149116
|
| |
|
|
|
|
|
| |
more robust) ways to do what it was doing now. Also, add static methods
for decoding a ShuffleVector mask.
llvm-svn: 149028
|
| |
|
|
|
|
| |
method.
llvm-svn: 149005
|
| |
|
|
|
|
|
| |
"isValidOperands" and "getMaskValue" methods to allow
ConstantDataSequential.
llvm-svn: 148998
|
| |
|
|
| |
llvm-svn: 148929
|
| |
|
|
|
|
|
| |
did something extremely surprising, and shadowed actually useful
implementations that had completely different behavior.
llvm-svn: 148898
|
| |
|
|
| |
llvm-svn: 148578
|
| |
|
|
| |
llvm-svn: 145801
|
| |
|
|
| |
llvm-svn: 145578
|
| |
|
|
|
|
|
| |
fix up later. For this special case, allow such a mask to be considered valid.
<rdar://problem/8622574>
llvm-svn: 142992
|
| |
|
|
|
|
|
|
|
|
|
|
| |
profile metadata at the same time. Use it to preserve metadata attached
to a branch when re-writing it in InstCombine.
Add metadata to the canonicalize_branch InstCombine test, and check that
it is tranformed correctly.
Reviewed by Nick Lewycky!
llvm-svn: 142168
|
| |
|
|
|
|
|
|
|
|
|
|
| |
assert(!"error message");
To:
assert(0 && "error message");
which is more consistant across the code base.
llvm-svn: 140234
|
| |
|
|
|
|
|
| |
Optimize chained bitcasts of the form A->B->A.
Undo r138722 and change isEliminableCastPair to allow this case.
llvm-svn: 138756
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This implements the 'landingpad' instruction. It's used to indicate that a basic
block is a landing pad. There are several restrictions on its use (see
LangRef.html for more detail). These restrictions allow the exception handling
code to gather the information it needs in a much more sane way.
This patch has the definition, implementation, C interface, parsing, and bitcode
support in it.
llvm-svn: 137501
|
| |
|
|
| |
llvm-svn: 137226
|
| |
|
|
| |
llvm-svn: 137170
|
| |
|
|
|
|
|
|
|
| |
This adds the 'resume' instruction class, IR parsing, and bitcode reading and
writing. The 'resume' instruction resumes propagation of an existing (in-flight)
exception whose unwinding was interrupted with a 'landingpad' instruction (to be
added later).
llvm-svn: 136589
|
| |
|
|
|
|
|
| |
r136339, r136341, r136369, r136387, r136392, r136396, r136429, r136430, r136444,
r136445, r136446, r136253 pending review.
llvm-svn: 136556
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
'atomicrmw' instructions, which allow representing all the current atomic
rmw intrinsics.
The allowed operands for these instructions are heavily restricted at the
moment; we can probably loosen it a bit, but supporting general
first-class types (where it makes sense) might get a bit complicated,
given how SelectionDAG works.
As an initial cut, these operations do not support specifying an alignment,
but it would be possible to add if we think it's useful. Specifying an
alignment lower than the natural alignment would be essentially
impossible to support on anything other than x86, but specifying a greater
alignment would be possible. I can't think of any useful optimizations which
would use that information, but maybe someone else has ideas.
Optimizer/codegen support coming soon.
llvm-svn: 136404
|
| |
|
|
| |
llvm-svn: 136392
|
| |
|
|
|
|
| |
to new vectors.
llvm-svn: 136338
|
| |
|
|
|
|
| |
value.
llvm-svn: 136326
|
| |
|
|
|
|
|
| |
* InvokeInst: Get the landingpad instruction associated with this invoke.
* LandingPadInst: A method to reserve extra space for clauses.
llvm-svn: 136325
|
| |
|
|
|
|
| |
This adds the new instructions 'landingpad' and 'resume'.
llvm-svn: 136253
|
| |
|
|
|
|
|
|
| |
replacement for llvm.memory.barrier.
This is just a LangRef entry and reading/writing/memory representation; optimizer+codegen support coming soon.
llvm-svn: 136009
|
| |
|
|
| |
llvm-svn: 135904
|
| |
|
|
| |
llvm-svn: 135375
|
| |
|
|
| |
llvm-svn: 135265
|
| |
|
|
| |
llvm-svn: 135040
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
-Wshorten-64-to-32 warning in Instructions.h.
llvm-svn: 133708
|
| |
|
|
|
|
|
|
|
| |
"Reinstate r133435 and r133449 (reverted in r133499) now that the clang
self-hosted build failure has been fixed (r133512)."
Due to some additional warnings.
llvm-svn: 133700
|
| |
|
|
|
|
| |
self-hosted build failure has been fixed (r133512).
llvm-svn: 133513
|
| |
|
|
| |
llvm-svn: 133499
|
| |
|
|
| |
llvm-svn: 133449
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Change PHINodes to store simple pointers to their incoming basic blocks,
instead of full-blown Uses.
Note that this loses an optimization in SplitCriticalEdge(), because we
can no longer walk the use list of a BasicBlock to find phi nodes. See
the comment I removed starting "However, the foreach loop is slow for
blocks with lots of predecessors".
Extend replaceAllUsesWith() on a BasicBlock to also update any phi
nodes in the block's successors. This mimics what would have happened
when PHINodes were proper Users of their incoming blocks. (Note that
this only works if OldBB->replaceAllUsesWith(NewBB) is called when
OldBB still has a terminator instruction, so it still has some
successors.)
llvm-svn: 133435
|
| |
|
|
|
|
|
|
|
| |
than either the primitive size or the element primitive size (in the case
of vectors), simplify the vector logic. No functionality change. There
is some distracting churn in the patch because I lined up comments better
while there - sorry about that.
llvm-svn: 131533
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
can be used to turn a <4 x i64> into a <4 x i32> but getCastOpcode would assert
if you passed these types to it. Note that this strictly extends the previous
functionality: if getCastOpcode previously accepted two vector types (i.e. didn't
assert) then it still will and returns the same opcode (BitCast). That's because
before it would only accept vectors with the same bitwidth, and the new code only
touches vectors with the same length. However if two vectors have both the same
bitwidth and the same length then their element types have the same bitwidth, so
the new logic will return BitCast as before.
llvm-svn: 131530
|
| |
|
|
|
|
| |
an odd number.
llvm-svn: 129270
|
| |
|
|
|
|
| |
list of operands. Simplify and rename them accordingly.
llvm-svn: 128708
|
| |
|
|
|
|
|
|
| |
had gotten out of sync: isCastable didn't think it was possible to
cast the x86_mmx type to anything, while it did think it possible
to cast an i64 to x86_mmx.
llvm-svn: 128705
|
| |
|
|
|
|
|
|
| |
instcombine xform to exercise this.
Nothing forms exact udivs yet though. This is progress on PR8862
llvm-svn: 124992
|
| |
|
|
| |
llvm-svn: 124659
|
| |
|
|
|
|
| |
User::dropHungOffUses().
llvm-svn: 123580
|
| |
|
|
|
|
|
| |
static_cast from Constant* to Value* has to adjust the "this" pointer.
This is groundwork for PR889.
llvm-svn: 123435
|