| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
| |
The early return seems to be missed. This causes a radical and wrong loop
optimization on powerpc. It isn't reproducible on x86_64, because
"UseInterleaved" is false.
Patch by Tim Shen.
llvm-svn: 257134
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
See PR25822 for a more full summary, but we were conflating the concepts of "capture" and "escape". We were proving nocapture and using that proof to infer noescape, which is not true. Escaped-ness is a function-local property - as soon as a value is used in a call argument it escapes. Capturedness is a related but distinct property. It implies a *temporally limited* escape. Consider:
static int a;
int b;
int g(int * nocapture arg);
int f() {
a = 2; // Even though a escapes to g, it is not captured so can be treated as non-escaping here.
g(&a); // But here it must be treated as escaping.
g(&b); // Now that g(&a) has returned we know it was not captured so we can treat it as non-escaping again.
}
The original commit did not sufficiently understand this nuance and so caused PR25822 and PR26046.
r248576 included both a performance improvement (which has been backed out) and a related conformance fix (which has been kept along with its testcase).
llvm-svn: 257058
|
| |
|
|
|
|
|
|
| |
Fix lit test fail due to outputting an extra line.
Differential Revision: http://reviews.llvm.org/D15776
llvm-svn: 256987
|
| |
|
|
| |
llvm-svn: 256954
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch implements "-print-funcs" option to support function filtering for IR printing like -print-after-all, -print-before etc.
Examples:
-print-after-all -print-funcs=foo,bar
Reviewers: mcrosier, joker.eph
Subscribers: tejohnson, joker.eph, llvm-commits
Differential Revision: http://reviews.llvm.org/D15776
llvm-svn: 256952
|
| |
|
|
|
|
| |
Since writeonly is the only missing attribute and special case left for the memset/memcpy family of intrinsics, rearrange the code to make that much more clear.
llvm-svn: 256949
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
InaccessibleMemOrArgMemOnly attributes"
Summary:
This reverts commit 5a9e526f29cf8510ab5c3d566fbdcf47ac24e1e9.
As per discussion in D15665
This also add a test case so that regression introduced by that diff are not reintroduced.
Reviewers: vaivaswatha, jmolloy, hfinkel, reames
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D15919
llvm-svn: 256932
|
| |
|
|
|
|
|
|
|
|
|
|
| |
attribute inference
Most of the properties of memset_pattern16 can be now covered by the generic attributes and inferred by InferFunctionAttrs. The only exceptions are:
- We don't yet have a writeonly attribute for the first argument.
- We don't have an attribute for modeling the access size facts encoded in MemoryLocation.cpp.
Differential Revision: http://reviews.llvm.org/D15879
llvm-svn: 256911
|
| |
|
|
|
|
|
|
| |
We only need to describe the writeonly property of one of the arguments. All of the rest of the semantics are nicely described by existing attributes in Intrinsics.td.
Differential Revision: http://reviews.llvm.org/D15880
llvm-svn: 256910
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This commit renames GCRelocateOperands to GCRelocateInst and makes it an
intrinsic wrapper, similar to e.g. MemCpyInst. Also, all users of
GCRelocateOperands were changed to use the new intrinsic wrapper instead.
Reviewers: sanjoy, reames
Subscribers: reames, sanjoy, llvm-commits
Differential Revision: http://reviews.llvm.org/D15762
llvm-svn: 256811
|
| |
|
|
|
|
|
|
|
|
| |
If we encounter a noalias call that alias analysis can't analyse, we can fall down into the generic call handling rather than giving up entirely. I noticed this while reading through the code for another purpose.
I can't seem to write a test case which changes; that sorta makes sense given any test case would have to be an inconsistency in AA. Suggestions welcome.
Differential Revision: http://reviews.llvm.org/D15825
llvm-svn: 256802
|
| |
|
|
|
|
|
|
|
|
|
|
| |
inference handling
This patch removes the isOperatorNewLike predicate since it was only being used to establish a non-null return value and we have attributes specifically for that purpose with generic handling. To keep approximate the same behaviour for existing frontends, I added the various operator new like (i.e. instances of operator new) to InferFunctionAttrs. It's not really clear to me why this isn't handled in Clang, but I didn't want to break existing code and any subtle assumptions it might have.
Once this patch is in, I'm going to start separating the isAllocLike family of predicates. These appear to be being used for a mixture of things which should be more clearly separated and documented. Today, they're being used to indicate (at least) aliasing facts, CSE-ability, and default values from an allocation site.
Differential Revision: http://reviews.llvm.org/D15820
llvm-svn: 256787
|