| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a recommit of r258620 which causes PR26293.
The original message:
Now LIR can turn following codes into memset:
typedef struct foo {
int a;
int b;
} foo_t;
void bar(foo_t *f, unsigned n) {
for (unsigned i = 0; i < n; ++i) {
f[i].a = 0;
f[i].b = 0;
}
}
void test(foo_t *f, unsigned n) {
for (unsigned i = 0; i < n; i += 2) {
f[i] = 0;
f[i+1] = 0;
}
}
llvm-svn: 258777
|
|
|
|
| |
llvm-svn: 258703
|
|
|
|
|
|
|
|
|
|
| |
The computation of ICmp demanded bits is independent of the individual operand being evaluated. We simply return a mask consisting of the minimum leading zeroes of both operands.
We were incorrectly passing "I" to ComputeKnownBits - this should be "UserI->getOperand(0)". In cases where we were evaluating the 1th operand, we were taking the minimum leading zeroes of it and itself.
This should fix PR26266.
llvm-svn: 258690
|
|
|
|
|
|
| |
The documentation for these functions is already present in the header file.
llvm-svn: 258649
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now LIR can turn following codes into memset:
typedef struct foo {
int a;
int b;
} foo_t;
void bar(foo_t *f, unsigned n) {
for (unsigned i = 0; i < n; ++i) {
f[i].a = 0;
f[i].b = 0;
}
}
void test(foo_t *f, unsigned n) {
for (unsigned i = 0; i < n; i += 2) {
f[i] = 0;
f[i+1] = 0;
}
}
llvm-svn: 258620
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
element type instead of pointer type and rename to getIndexedOffsetInType.
Summary:
Reviewers: mjacob, dblaikie
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D16282
llvm-svn: 258478
|
|
|
|
|
|
|
|
|
|
|
|
| |
of just the pointer.
Reviewers: mjacob, dblaikie
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D16422
llvm-svn: 258477
|
|
|
|
|
|
|
|
|
|
|
|
| |
ConstantFoldLoadFromConstPtr.
Reviewers: mjacob, dblaikie
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D16418
llvm-svn: 258472
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
when folding GEPs.
Summary:
Reviewers: mjacob, dblaikie
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D16302
llvm-svn: 258456
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit extends the patterns recognised by InstSimplify to also handle (x >> y) <= x in the same way as (x /u y) <= x.
The missing optimisation was found investigating why LLVM did not optimise away bound checks in a binary search: https://github.com/rust-lang/rust/pull/30917
Patch by Andrea Canciani!
Differential Revision: http://reviews.llvm.org/D16402
llvm-svn: 258422
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
And use it in PPCLoopDataPrefetch.cpp.
@hfinkel, please let me know if your preference would be to preserve the
ppc-loop-prefetch-cache-line option in order to be able to override the
value of TTI::getCacheLineSize for PPC.
Reviewers: hfinkel
Subscribers: hulx2000, mcrosier, mssimpso, hfinkel, llvm-commits
Differential Revision: http://reviews.llvm.org/D16306
llvm-svn: 258419
|
|
|
|
|
|
|
|
| |
This undoes the change made in r258163. The assertion fails if `Ptr` is of a
vector type. The previous code doesn't look completely correct either, so I'll
investigate this more.
llvm-svn: 258411
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
type. NFC.
Summary:
The previous form, taking opcode and type, is moved to an internal
helper and the new form, taking an instruction, is a wrapper around this
helper.
Although this is a slight cleanup on its own, the main motivation is to
refactor the constant folding API to ease migration to opaque pointers.
This will be follow-up work.
Reviewers: eddyb
Subscribers: dblaikie, llvm-commits
Differential Revision: http://reviews.llvm.org/D16383
llvm-svn: 258391
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ConstantFoldInstOperands to use it. NFC.
Summary:
Although this is a slight cleanup on its own, the main motivation is to
refactor the constant folding API to ease migration to opaque pointers.
This will be follow-up work.
Reviewers: eddyb
Subscribers: zzheng, dblaikie, llvm-commits
Differential Revision: http://reviews.llvm.org/D16380
llvm-svn: 258390
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ConstantFoldInstOperands to use it. NFC.
Summary:
Although this is a slight cleanup on its own, the main motivation is to
refactor the constant folding API to ease migration to opaque pointers.
This will be follow-up work.
Reviewers: eddyb
Subscribers: dblaikie, llvm-commits
Differential Revision: http://reviews.llvm.org/D16378
llvm-svn: 258389
|
|
|
|
| |
llvm-svn: 258332
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In some cases, the max backedge taken count can be more conservative
than the exact backedge taken count (for instance, because
ScalarEvolution::getRange is not control-flow sensitive whereas
computeExitLimitFromICmp can be). In these cases,
computeExitLimitFromCond (specifically the bit that deals with `and` and
`or` instructions) can create an ExitLimit instance with a
`SCEVCouldNotCompute` max backedge count expression, but a computable
exact backedge count expression. This violates an implicit SCEV
assumption: a computable exact BE count should imply a computable max BE
count.
This change
- Makes the above implicit invariant explicit by adding an assert to
ExitLimit's constructor
- Changes `computeExitLimitFromCond` to be more robust around
conservative max backedge counts
llvm-svn: 258184
|
|
|
|
| |
llvm-svn: 258183
|
|
|
|
| |
llvm-svn: 258163
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
get{Source,Result}ElementType.
Summary:
GEPOperator: provide getResultElementType alongside getSourceElementType.
This is made possible by adding a result element type field to GetElementPtrConstantExpr, which GetElementPtrInst already has.
GEP: replace get(Pointer)ElementType uses with get{Source,Result}ElementType.
Reviewers: mjacob, dblaikie
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D16275
llvm-svn: 258145
|
|
|
|
| |
llvm-svn: 258125
|
|
|
|
| |
llvm-svn: 258088
|
|
|
|
|
|
|
|
|
|
|
|
| |
getType()->getPointerElementType().
Reviewers: mjacob
Subscribers: llvm-commits, dblaikie
Differential Revision: http://reviews.llvm.org/D16272
llvm-svn: 258028
|
|
|
|
| |
llvm-svn: 258027
|
|
|
|
| |
llvm-svn: 258026
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
source element type of the GEP as an argument.
Patch by Eduard Burtescu.
Reviewers: dblaikie, mjacob
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D16281
llvm-svn: 258024
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: dblaikie, mjacob
Subscribers: llvm-commits, dblaikie
Patch by Eduard Burtescu.
Differential Revision: http://reviews.llvm.org/D16274
llvm-svn: 258022
|
|
|
|
|
|
|
|
| |
Reviewed By: reames
Differential Revision: http://reviews.llvm.org/D16226
llvm-svn: 258010
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: mjacob
Subscribers: jholewinski, arsenm, dsanders, dblaikie
Patch by Eduard Burtescu.
Differential Revision: http://reviews.llvm.org/D16260
llvm-svn: 257999
|
|
|
|
|
|
|
|
| |
function
Differential Revision: http://reviews.llvm.org/D16225
llvm-svn: 257991
|
|
|
|
|
|
|
|
|
| |
It looks nicer and improves the compiletime of a typical
clang -O3 -emit-llvm run by ~0.6% for me.
Differential Revision: http://reviews.llvm.org/D16205
llvm-svn: 257944
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Rename to getCatchSwitchParentPad, to make it more clear which ancestor
the "parent" in question is. Add a comment pointing out the key feature
that the returned pad indicates which funclet contains the successor
block.
Reviewers: rnk, andrew.w.kaylor, majnemer
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D16222
llvm-svn: 257933
|
|
|
|
|
|
| |
http://reviews.llvm.org/D10920.
llvm-svn: 257894
|
|
|
|
| |
llvm-svn: 257845
|
|
|
|
| |
llvm-svn: 257835
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D15401
llvm-svn: 257832
|
|
|
|
| |
llvm-svn: 257804
|
|
|
|
|
|
| |
This reverts commit r257769. Backing this out because of stage2 failures.
llvm-svn: 257773
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some patterns of select+compare allow us to know exactly the value of the uppermost bits in the select result. For example:
%b = icmp ugt i32 %a, 5
%c = select i1 %b, i32 2, i32 %a
Here we know that %c is bounded by 5, and therefore KnownZero = ~APInt(5).getActiveBits() = ~7.
There are several such patterns, and this patch attempts to understand a reasonable subset of them - namely when the base values are the same (as above), and when they are related by a simple (add nsw), for example (add nsw %a, 4) and %a.
llvm-svn: 257769
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Since globals may escape as function arguments (even when they have been
found to be non-escaping, because of optimizations such as memcpyoptimizer
that replaces stores with memcpy), all arguments to a function are checked
during query to make sure they are identifiable. At that time, also ensure
we return a conservative result only if the arguments don't alias to our global.
Reviewers: hfinkel, jmolloy
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D16140
llvm-svn: 257750
|
|
|
|
| |
llvm-svn: 257688
|
|
|
|
| |
llvm-svn: 257676
|
|
|
|
| |
llvm-svn: 257646
|
|
|
|
| |
llvm-svn: 257643
|
|
|
|
| |
llvm-svn: 257626
|
|
|
|
| |
llvm-svn: 257613
|
|
|
|
| |
llvm-svn: 257542
|
|
|
|
| |
llvm-svn: 257399
|
|
|
|
| |
llvm-svn: 257396
|
|
|
|
|
|
|
|
|
|
|
| |
It's strange that LoopInfo mostly owns the Loop objects, but that it
defers deleting them to the loop pass manager. Instead, change the
oddly named "updateUnloop" to "markAsRemoved" and have it queue the
Loop object for deletion. We can't delete the Loop immediately when we
remove it, since we need its pointer identity still, so we'll mark the
object as "invalid" so that clients can see what's going on.
llvm-svn: 257191
|