| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D11181
llvm-svn: 246963
|
| |
|
|
|
|
|
|
|
| |
SelectT2ShifterOperandReg has identical behaviour to SelectImmShifterOperand,
so get rid of it and use SelectImmShifterOperand instead.
Differential Revision: http://reviews.llvm.org/D12195
llvm-svn: 246962
|
| |
|
|
|
|
|
|
| |
MAX.fmt, MIN.fmt, MAXA.fmt, MINA.fmt and CMP.condn.fmt instructions
Differential Revision: http://reviews.llvm.org/D12141
llvm-svn: 246960
|
| |
|
|
| |
llvm-svn: 246953
|
| |
|
|
|
|
|
|
|
|
| |
Trivial multiplication by zero may survive the worklist. We tried to
reassociate the multiplication with a division instruction, causing us
to divide by zero; bail out instead.
This fixes PR24726.
llvm-svn: 246939
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In searching for a fix for the underlying code-quality bug highlighted by
r246937 (that SDAG simplification can lead to us generating an ISD::OR node
with a constant zero LHS), I ran across this:
We generically canonicalize commutative binary-operation nodes in SDAG getNode
so that, if only one operand is a constant, it will be on the RHS. However, we
were doing this only after a bunch of constant-based simplification checks that
all assume this canonical form (that any constant will be on the RHS). Moving
the operand-swapping canonicalization prior to these checks seems like the
right thing to do (and, as it turns out, causes SDAG to completely fold away the
computation in test/CodeGen/ARM/2012-11-14-subs_carry.ll, just like InstCombine
would do).
llvm-svn: 246938
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To commute a trivial rlwimi instructions (meaning one with a full mask and zero
shift), we'd need to ability to form an all-zero mask (instead of an all-one
mask) using rlwimi. We can't represent this, however, and we'll miscompile code
if we try.
The code quality problem that this highlights (that SDAG simplification can
lead to us generating an ISD::OR node with a constant zero LHS) will be fixed
as a follow-up.
Fixes PR24719.
llvm-svn: 246937
|
| |
|
|
|
|
| |
This fixes PR24713.
llvm-svn: 246933
|
| |
|
|
|
| |
Differential: http://reviews.llvm.org/D11590
llvm-svn: 246930
|
| |
|
|
|
|
|
|
| |
MADDF.fmt, MSUBF.fmt and NEG.fmt instructions
Differential Revision: http://reviews.llvm.org/D11978
llvm-svn: 246919
|
| |
|
|
| |
llvm-svn: 246908
|
| |
|
|
|
|
|
| |
We want a deterministic output. GNU AS leaves it zero.
FIXME: It may be optional by its user, like llc and clang.
llvm-svn: 246905
|
| |
|
|
| |
llvm-svn: 246903
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
PPCISelDAGToDAG has a transformation that generates a rlwimi instruction from
an input pattern that looks like this:
and(or(x, c1), c2)
but the associated logic does not work if there are bits that are 1 in c1 but 0
in c2 (these are normally canonicalized away, but that can't happen if the 'or'
has other users. Make sure we abort the transformation if such bits are
discovered.
Fixes PR24704.
llvm-svn: 246900
|
| |
|
|
| |
llvm-svn: 246899
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D12434
llvm-svn: 246896
|
| |
|
|
| |
llvm-svn: 246888
|
| |
|
|
| |
llvm-svn: 246865
|
| |
|
|
| |
llvm-svn: 246851
|
| |
|
|
|
|
|
| |
Casting to unsigned long can cause the time to get truncated to 32-bits,
making it appear to be a valid timestamp. Just use isUInt<32> instead.
llvm-svn: 246840
|
| |
|
|
|
|
| |
[-Wsign-compare]
llvm-svn: 246839
|
| |
|
|
|
|
| |
mutations before returning un-mutated data
llvm-svn: 246828
|
| |
|
|
| |
llvm-svn: 246825
|
| |
|
|
|
|
|
|
|
|
|
| |
This adds a basic cost model for interleaved-access vectorization (and a better
default for shuffles), and enables interleaved-access vectorization by default.
The relevant difference from the default cost model for interleaved-access
vectorization, is that on PPC, the shuffles that end up being used are *much*
cheaper than modeling the process with insert/extract pairs (which are
quite expensive, especially on older cores).
llvm-svn: 246824
|
| |
|
|
|
|
|
|
| |
On the A2, with an eye toward QPX unaligned-load merging, we should always use
aggressive interleaving. It is generally superior to only using concatenation
unrolling.
llvm-svn: 246819
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When forming permutation-based unaligned vector loads, we need to know whether
it is valid to read ahead of the requested address by a full vector length.
Doing so is more efficient (and allows for more CSE with later loads), but
could trigger a page fault if invalid. To determine validity, we look for other
loads in the same block that access the relevant address range.
The relevant point here is that we need to do this as part of the process of
forming permutation-based vector loads, and this happens quite early in the
SDAG pipeline - specifically before many of the address calculations are fully
canonicalized. As a result, we need to try harder to recognize base+offset
address computations, because they still might appear as chain of adds
(base+offset+offset, for example). To account for this, we'll look through
chains of adds, accumulating the constant offsets.
llvm-svn: 246813
|
| |
|
|
|
|
|
| |
Test case attached -- currently the parser smears the "foo bar" to all
of the formal arguments.
llvm-svn: 246812
|
| |
|
|
|
|
| |
warning [NFC]
llvm-svn: 246810
|
| |
|
|
|
|
|
|
|
|
| |
As a first step towards a new implementation of the base pointer inference algorithm, introduce an abstraction for BDVs, strengthen the assertions around them, and rewrite the BDV relation code in terms of the abstraction which includes an explicit notion of whether the BDV is also a base. The later is motivated by the fact we had a bug where insertelement was always assumed to be a base pointer even though the BDV code knew it wasn't. The strengthened assertions in this patch would have caught that bug.
The next step will be to separate the DefiningValueMap into a BDV use list cache (entirely within findBasePointers) and a base pointer cache. Having the former will allow me to use a deterministic visit order when visiting BDVs in the inference algorithm and remove a bunch of ordering related hacks. Before actually doing the last step, I'm likely going to extend the lattice with a 'BaseN' (seen only base inputs) state so that I can kill the post process optimization step.
Phabricator Revision: http://reviews.llvm.org/D12608
llvm-svn: 246809
|
| |
|
|
|
|
| |
a class. NFC
llvm-svn: 246808
|
| |
|
|
|
|
|
|
|
|
| |
Pre-P8, when we generate code for unaligned vector loads (for Altivec and QPX
types), even when accounting for the combining that takes place for multiple
consecutive such loads, there is at least one load instructions and one
permutation for each load. Make sure the cost reported reflects the cost of the
permutes as well.
llvm-svn: 246807
|
| |
|
|
|
|
|
|
|
|
|
| |
If you compute the MMO offset using unsigned arithmetic, you end up with a
large positive offset instead of a small negative one. In theory, this could
cause bad instruction-scheduling decisions later.
I noticed this by inspection from the debug output, and using that for the
regression test is the best I can do right now.
llvm-svn: 246805
|
| |
|
|
|
|
|
|
| |
The visit order being used in the base pointer inference algorithm is currently non-deterministic. When working on http://reviews.llvm.org/D12583, I discovered that we were relying on a peephole optimization to get deterministic ordering in one of the test cases.
This change is intented to let me test and land http://reviews.llvm.org/D12583. The current code will not be long lived. I'm starting to investigate a rewrite of the algorithm which will combine the post-process step into the initial algorithm and make the visit order determistic. Before doing that, I wanted to make sure the existing code was complete and the test were stable. Hopefully, patches should be up for review for the new algorithm this week or early next.
llvm-svn: 246801
|
| |
|
|
| |
llvm-svn: 246800
|
| |
|
|
|
|
|
| |
Splitting basic blocks really messes up WinEHPrepare. We can remove this
change when SEH uses the new EH IR.
llvm-svn: 246799
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In vectorized add reduction code, the final "reduce" step is sub-optimal.
This change wll combine :
ext v1.16b, v0.16b, v0.16b, #8
add v0.4s, v1.4s, v0.4s
dup v1.4s, v0.s[1]
add v0.4s, v1.4s, v0.4s
into
addv s0, v0.4s
PR21371
http://reviews.llvm.org/D12325
Patch by Jun Bum Lim <junbuml@codeaurora.org>!
llvm-svn: 246790
|
| |
|
|
|
|
|
|
|
|
| |
Summary:
This fixes bugzilla bug 24656. Fixes the case where there is a forward
reference to a global variable using an ID (i.e. @0). It does this by
passing the address space of the initializer pointer for which the
forward referenced global is used.
llvm-svn: 246788
|
| |
|
|
|
|
|
|
| |
This prevents MC clients from getting COFF.h, which conflicts with
winnt.h macros. Also a minor IWYU cleanup. Now the only public headers
including COFF.h are in Object, and they actually need it.
llvm-svn: 246784
|
| |
|
|
|
|
|
|
| |
This reverts commit r246769.
This appears to have broken Multisource/Benchmarks/tramp3d-v4.
llvm-svn: 246782
|
| |
|
|
| |
llvm-svn: 246781
|
| |
|
|
|
|
|
|
|
|
|
| |
Summary:
Fixes bug 24645. Problem appears to be that the type may be undefined
when ConvertValIDToValue is called.
Reviewers: kcc
Subscribers: llvm-commits
llvm-svn: 246779
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Fixes bug 24646. Previous code was not checking if an index into a vector
was valid, resulting in a SEGV. Fixed by assuming the construct can't
be parsed when given this input.
Reformat and add test.
Differential Revision: http://reviews.llvm.org/D12539
llvm-svn: 246774
|
| |
|
|
|
|
|
|
| |
Fixes bug 24646. Previous code was not checking if an index into a vector
was valid, resulting in a SEGV. Fixed by assuming the construct can't
be parsed when given this input.
llvm-svn: 246773
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use and check the 'IsFast' optional parameter to TLI.allowsMemoryAccess() any time
we have a merged access candidate. Without this patch, we were generating unaligned
16-byte (SSE) memops for x86 targets where those accesses are slow.
This change was mentioned in:
http://reviews.llvm.org/D10662 and
http://reviews.llvm.org/D10905
and will help solve PR21711.
Differential Revision: http://reviews.llvm.org/D12573
llvm-svn: 246771
|
| |
|
|
|
|
|
|
|
|
|
| |
This patch allows the mixing of scaled and unscaled load/stores to form
load/store pairs.
PR24465
http://reviews.llvm.org/D12116
Many thanks to Ahmed and Michael for fixes and code review.
llvm-svn: 246769
|
| |
|
|
| |
llvm-svn: 246767
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
traps and breaks in the integrated assembler.
Summary:
Patch by Scott Egerton
Reviewers: vkalintiris, dsanders
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D11675
llvm-svn: 246763
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This intrinsic can be used to extract a pointer to the exception caught by
a given catchpad. Its argument has token type and must be a `catchpad`.
Also clarify ExtendingLLVM documentation regarding overloaded intrinsics.
Reviewers: majnemer, andrew.w.kaylor, sanjoy, rnk
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D12533
llvm-svn: 246752
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Add a `cleanupendpad` instruction, used to mark exceptional exits out of
cleanups (for languages/targets that can abort a cleanup with another
exception). The `cleanupendpad` instruction is similar to the `catchendpad`
instruction in that it is an EH pad which is the target of unwind edges in
the handler and which itself has an unwind edge to the next EH action.
The `cleanupendpad` instruction, similar to `cleanupret` has a `cleanuppad`
argument indicating which cleanup it exits. The unwind successors of a
`cleanuppad`'s `cleanupendpad`s must agree with each other and with its
`cleanupret`s.
Update WinEHPrepare (and docs/tests) to accomodate `cleanupendpad`.
Reviewers: rnk, andrew.w.kaylor, majnemer
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D12433
llvm-svn: 246751
|
| |
|
|
|
|
|
|
|
|
| |
vpconflictq, vpconflictd
Added tests for intrinsics and encoding.
Differential Revision: http://reviews.llvm.org/D11931
llvm-svn: 246750
|