| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
llvm-svn: 131600
|
|
|
|
| |
llvm-svn: 131598
|
|
|
|
| |
llvm-svn: 131597
|
|
|
|
| |
llvm-svn: 131596
|
|
|
|
|
|
|
|
| |
patterns,
which fixes all of the CodeGen/MBlaze verifier failures.
llvm-svn: 131595
|
|
|
|
|
|
| |
uses them.
llvm-svn: 131591
|
|
|
|
| |
llvm-svn: 131590
|
|
|
|
| |
llvm-svn: 131587
|
|
|
|
|
|
| |
Add test case.
llvm-svn: 131582
|
|
|
|
|
|
| |
tweak so that we don't depend on an uninitialized argument.
llvm-svn: 131581
|
|
|
|
| |
llvm-svn: 131580
|
|
|
|
| |
llvm-svn: 131579
|
|
|
|
|
|
| |
turned on.
llvm-svn: 131578
|
|
|
|
|
|
|
| |
of the comparison, so that the resulting expression is fully
normalized. This fixes PR9939.
llvm-svn: 131576
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- StartChained and EndChained delimit a chained unwind area, which can contain
additional operations to be undone if an exception occurs inside of it.
- UnwindOnly declares that this function doesn't handle any exceptions. If it
has a handler, it's an unwind handler instead of an exception handler.
- Lsda declares the location and size of the LSDA, which in the Win64 EH
scheme is kept inside the UNWIND_INFO struct. Windows itself ignores the
LSDA; it's used by the Language-Specific Handler (the "Personality Function"
from DWARF).
llvm-svn: 131572
|
|
|
|
| |
llvm-svn: 131571
|
|
|
|
| |
llvm-svn: 131567
|
|
|
|
| |
llvm-svn: 131566
|
|
|
|
|
|
| |
immediate operand.
llvm-svn: 131565
|
|
|
|
| |
llvm-svn: 131561
|
|
|
|
|
|
| |
optimized into tail-calls when possible.
llvm-svn: 131560
|
|
|
|
| |
llvm-svn: 131559
|
|
|
|
|
|
| |
bonus inter-library dependencies.
llvm-svn: 131556
|
|
|
|
|
|
| |
rdar://9449159.
llvm-svn: 131555
|
|
|
|
|
|
| |
type as input. Sorry test cases only trigger when dag combine is disabled. rdar://9449178
llvm-svn: 131553
|
|
|
|
| |
llvm-svn: 131552
|
|
|
|
| |
llvm-svn: 131551
|
|
|
|
| |
llvm-svn: 131548
|
|
|
|
| |
llvm-svn: 131547
|
|
|
|
| |
llvm-svn: 131545
|
|
|
|
| |
llvm-svn: 131544
|
|
|
|
| |
llvm-svn: 131543
|
|
|
|
| |
llvm-svn: 131542
|
|
|
|
| |
llvm-svn: 131541
|
|
|
|
| |
llvm-svn: 131538
|
|
|
|
|
|
| |
Patch by Dan Bailey
llvm-svn: 131537
|
|
|
|
|
|
|
|
| |
Original log entry:
Refactor getActionType and getTypeToTransformTo ; place all of the 'decision'
code in one place.
llvm-svn: 131536
|
|
|
|
|
|
| |
code in one place.
llvm-svn: 131534
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
splits each half. Therefore, the real problem was that we were using a VREV64 for a 4xi16, when we should have been using a VREV32.
Updated test case and reverted change to the PerfectShuffle Table.
llvm-svn: 131529
|
|
|
|
|
|
|
|
|
| |
GAS has no such directives (not even mingw-w64 GAS has them), so I took
creative license with their names in assembly. I prefixed them all with
"w64_" to avoid namespace collisions, for example. If I discover that GAS
has taken a different approach, I'll change ours to match.
llvm-svn: 131525
|
|
|
|
| |
llvm-svn: 131524
|
|
|
|
|
|
|
| |
The 'last use' may not be in the same basic block, and we still want a correct
live range.
llvm-svn: 131523
|
|
|
|
|
|
|
|
|
| |
the purposes of the Win64 EH tables, I realized we had no way to tell where
the function ends. (MASM bounds functions with PROC and ENDP keywords.)
Add a directive to delimit the end of the function, and rename the 'frame'
directive to more accurately reflect its duality with the new directive.
llvm-svn: 131522
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
joined copies.
LiveInterval::shrinkToUses recomputes the live range from scratch instead of
removing snippets. This should avoid the problem with dangling live ranges.
Leave physreg identity copies alone. They can be created when joining a virtreg
with a physreg. They don't affect register allocation, and they will be removed
by the rewriter.
llvm-svn: 131521
|
|
|
|
| |
llvm-svn: 131519
|
|
|
|
|
|
| |
compare-and-swap intrinsics.
llvm-svn: 131518
|
|
|
|
|
|
|
|
|
|
| |
to set the debug location on the IRBuilder, which will be then right location in most cases. This should magically give many transformations debug locations, and fixing places which are missing a debug location will usually just means changing the code creating it to use the IRBuilder.
As an example, the change to InstCombineCalls catches a common case where a call to a bitcast of a function is rewritten.
Chris, does this approach look reasonable?
llvm-svn: 131516
|