| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
Use early-return style that's preferred in LLVM and updating the naming in places I touched with other changes in the last few days. Hopefully, NFC.
llvm-svn: 234785
|
| |
|
|
|
|
| |
We use dummy calls to adjust the liveness of values over statepoints in the midst of the insertion. If there are no values which need held live, there's no point in actually inserting the holder.
llvm-svn: 234779
|
| |
|
|
|
|
|
|
|
|
| |
statepoint [NFC]
Since we're restructuring the CFG, we also need to make sure to update the analsis passes. While I'm touching the code, I dedicided to restructure it a bit. The code involved here was very confusing. This change moves the normalization to essentially being a pre-pass before the main insertion work and updates a few comments to actually say what is happening and *why*.
The restructuring should be covered by existing tests. I couldn't easily see how to create a test for the invalidation bug. Suggestions welcome.
llvm-svn: 234769
|
| |
|
|
|
|
| |
This is related to the issues addressed in 234651. These assertions check the properties ensured by that change at the place of use. Note that a similiar property is checked in checkBasicSSA, but without the reachability constraint. Technically, the liveness would be correct to include unreachable values, but this would be problematic for actual relocation.
llvm-svn: 234766
|
| |
|
|
|
|
|
|
|
|
| |
The check in question is attempting to help find cases where we haven't relocated a pointer at a safepoint we should have. It does this by coercing the value to null at any safepoint which doesn't relocate it.
Unfortunately, this turns out to be rather expensive in terms of memory usage and time. The number of stores inserted can grow with O(number of values x number of statepoints). On at least one example I looked at, over half of peak memory usage was coming from this check.
With this change, the check is no longer enabled by default in Asserts builds. It is enabled for expensive asserts builds and has a command line option to enable it in both Asserts and non-Asserts builds.
llvm-svn: 234761
|
| |
|
|
|
|
| |
NFC
llvm-svn: 234694
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The patch is generated using clang-tidy misc-use-override check.
This command was used:
tools/clang/tools/extra/clang-tidy/tool/run-clang-tidy.py \
-checks='-*,misc-use-override' -header-filter='llvm|clang' \
-j=32 -fix -format
http://reviews.llvm.org/D8925
llvm-svn: 234679
|
| |
|
|
|
|
| |
A function which is used only in Asserts builds needs to be defined only in Asserts builds.
llvm-svn: 234667
|
| |
|
|
|
|
| |
Using a SetVector to replace equivelent but more verbose functionality.
llvm-svn: 234662
|
| |
|
|
|
|
|
|
| |
When rewriting statepoints to make relocations explicit, we need to have a conservative but consistent notion of where a particular pointer is live at a particular site. The old code just used dominance, which is correct, but decidedly more conservative then it needed to be. This patch implements a simple dataflow algorithm that's run one per function (well, twice counting fixup after base pointer insertion). There's still lots of room to make this faster, but it's fast enough for all practical purposes today.
Differential Revision: http://reviews.llvm.org/D8674
llvm-svn: 234657
|
| |
|
|
|
|
| |
Format the entire file to reduce diff of change to follow.
llvm-svn: 234656
|
| |
|
|
|
|
| |
After submitting 234651, I noticed I hadn't responded to a review comment by mjacob. This patch addresses that comment and fixes a Release only build problem due to an unused variable.
llvm-svn: 234653
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
single entry phis
Two related small changes:
Various dominance based queries about liveness can get confused if we're talking about unreachable blocks. To avoid reasoning about such cases, just remove them before rewriting statepoints.
Remove single entry phis (likely left behind by LCSSA) to reduce the number of live values.
Both of these are motivated by http://reviews.llvm.org/D8674 which will be submitted shortly.
Differential Revision: http://reviews.llvm.org/D8675
llvm-svn: 234651
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This patch adds limited support for inserting explicit relocations when there's a vector of pointers live over the statepoint. This doesn't handle the case where the vector contains a mix of base and non-base pointers; that's future work.
The current implementation just scalarizes the vector over the gc.statepoint before doing the explicit rewrite. An alternate approach would be to plumb the vector all the way though the backend lowering, but doing that appears challenging. In particular, the size of the indirect spill slot is currently assumed to be sizeof(pointer) throughout the backend.
In practice, this is enough to allow running the SLP and Loop vectorizers before RewriteStatepointsForGC.
Differential Revision: http://reviews.llvm.org/D8671
llvm-svn: 234647
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
CallSite roughly behaves as a common base CallInst and InvokeInst. Bring
the behavior closer to that model by making upcasts explicit. Downcasts
remain implicit and work as before.
Following dyn_cast as a mental model checking whether a Value *V isa
CallSite now looks like this:
if (auto CS = CallSite(V)) // think dyn_cast
instead of:
if (CallSite CS = V)
This is an extra token but I think it is slightly clearer. Making the
ctor explicit has the advantage of not accidentally creating nullptr
CallSites, e.g. when you pass a Value * to a function taking a CallSite
argument.
llvm-svn: 234601
|
| |
|
|
|
|
| |
Same as r234255, but for lib/Analysis and lib/Transforms.
llvm-svn: 234257
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: This reduces handling &B[(1 << i) * s] to handling &B[i * S].
Test Plan: slsr-gep.ll
Reviewers: meheff
Subscribers: sanjoy, llvm-commits
Differential Revision: http://reviews.llvm.org/D8837
llvm-svn: 234180
|
| |
|
|
| |
llvm-svn: 234064
|
| |
|
|
| |
llvm-svn: 234058
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The plan here is to push the API changes out from the common components
(like Constant::getGetElementPtr and IRBuilder::CreateGEP related
functions) and just update callers to either pass the type if it's
obvious, or pass null.
Do this with LoadInst as well and anything else that comes up, then to
start porting specific uses to not pass null anymore - this may require
some refactoring in each case.
llvm-svn: 234042
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The old requirement on GEP candidates being in bounds is unnecessary.
For off-bound GEPs, we still have
&B[i * S] = B + (i * S) * e = B + (i * e) * S
Test Plan: slsr_offbound_gep in slsr-gep.ll
Reviewers: meheff
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D8809
llvm-svn: 233949
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Require the pointee type to be passed explicitly and assert that it is
correct. For now it's possible to pass nullptr here (and I've done so in
a few places in this patch) but eventually that will be disallowed once
all clients have been updated or removed. It'll be a long road to get
all the way there... but if you have the cahnce to update your callers
to pass the type explicitly without depending on a pointer's element
type, that would be a good thing to do soon and a necessary thing to do
eventually.
llvm-svn: 233938
|
| |
|
|
|
|
| |
Update lib/Analysis and lib/Transforms to use the new `DebugLoc` API.
llvm-svn: 233587
|
| |
|
|
|
|
|
|
| |
This re-adds float2int to the tree, after fixing PR23038. It turns
out the argument to APSInt() is true-if-unsigned, rather than
true-if-signed :(. Added testcase and explanatory comment.
llvm-svn: 233370
|
| |
|
|
| |
llvm-svn: 233363
|
| |
|
|
|
|
| |
The assertion here was more expensive then it needed to be. We're only inserting allocas in the entry block, so we only need to consider ones in the entry block.
llvm-svn: 233362
|
| |
|
|
| |
llvm-svn: 233361
|
| |
|
|
|
|
| |
Minor naming, one potentially unsafe cast
llvm-svn: 233359
|
| |
|
|
|
|
| |
All the removed assertions are either implied locally by the assert at the top of the function or properties of the verifier.
llvm-svn: 233358
|
| |
|
|
|
|
| |
tree, due to PR23038.
llvm-svn: 233350
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch enhances SLSR to handle another candidate form &B[i * S]. If
we found two candidates
S1: X = &B[i * S]
S2: Y = &B[i' * S]
and S1 dominates S2, we can replace S2 with
Y = &X[(i' - i) * S]
Test Plan:
slsr-gep.ll
X86/no-slsr.ll: verify that we do not run SLSR on GEPs that already fit into
an addressing mode
Reviewers: eliben, atrick, meheff, hfinkel
Reviewed By: hfinkel
Subscribers: sanjoy, llvm-commits
Differential Revision: http://reviews.llvm.org/D7459
llvm-svn: 233286
|
| |
|
|
|
|
|
| |
Added test Float2Int/float2int-optnone.ll to verify that pass Float2Int
is not run on optnone functions.
llvm-svn: 233183
|
| |
|
|
|
|
|
|
| |
where possible.
Now with a fix for PR23008 and extra regression test.
llvm-svn: 233175
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The changes to InstCombine do seem a bit silly - it doesn't make
anything obviously better to have the caller access the pointers element
type (the thing I'm trying to remove) than the GEP itself, but it's a
helpful migration step. This will allow me to more obviously lock down
GEP (& Load, etc) API usage, then fix all the code that accesses pointer
element types except the places that need to be removed (most of the
InstCombines) anyway - at which point I'll need to just remove all that
code because it won't be meaningful anymore (there will be no pointer
types, so no bitcasts to combine)
llvm-svn: 233126
|
| |
|
|
|
|
|
|
|
|
|
| |
where possible."
This caused PR23008, compiles failing with: "Use still stuck around after Def is
destroyed: %.sroa.speculated"
Also reverting follow-up r233064.
llvm-svn: 233105
|
| |
|
|
|
|
|
|
|
| |
IRCE requires the induction variables it handles to not sign-overflow.
The current scheme of checking if sext({X,+,S}) == {sext(X),+,sext(S)}
fails when SCEV simplifies sext(X) too. After this change we //also//
check no-signed-wrap by looking at the flags set on the SCEVAddRecExpr.
llvm-svn: 233102
|
| |
|
|
|
|
|
| |
IRCE should not try to eliminate range checks that check an induction
variable against a loop-varying length.
llvm-svn: 233101
|
| |
|
|
| |
llvm-svn: 233064
|
| |
|
|
|
|
|
|
|
|
|
|
| |
It is possible to have code that converts from integer to float, performs operations then converts back, and the result is provably the same as if integers were used.
This can come from different sources, but the most obvious is a helper function that uses floats but the arguments given at an inlined callsites are integers.
This pass considers all integers requiring a bitwidth less than or equal to the bitwidth of the mantissa of a floating point type (23 for floats, 52 for doubles) as exactly representable in floating point.
To reduce the risk of harming efficient code, the pass only attempts to perform complete removal of inttofp/fptoint operations, not just move them around.
llvm-svn: 233062
|
| |
|
|
| |
llvm-svn: 232998
|
| |
|
|
| |
llvm-svn: 232993
|
| |
|
|
|
|
| |
NFC.
llvm-svn: 232944
|
| |
|
|
|
|
|
|
|
| |
Don't use `DebugLoc` accessors if we're pointing at null, which will be
a problem after a WIP patch to make the `DIDescriptor` accessors more
strict. Caught by Frontend/profile-sample-use-loc-tracking.c (in
clang).
llvm-svn: 232792
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Remove `DebugInfoVerifierLegacyPass` and the `-verify-di` pass.
Instead, call into the `DebugInfoVerifier` from inside
`VerifierLegacyPass::finalizeModule()`. This better matches the logic
in `verifyModule()` (used by the new PassManager), avoids requiring two
separate passes to verify the IR, and makes the API for "add a pass to
verify the IR" simple.
Note: the `-verify-debug-info` flag still works (for now, at least;
eventually it might make sense to just remove it).
llvm-svn: 232772
|
| |
|
|
|
|
|
| |
Benign warning (clang deliberately suppresses this case) but does
regularly produce bad formatting, so it's nice to fix/reformat.
llvm-svn: 232508
|
| |
|
|
|
|
| |
about being unable to put (unsigned)-1 into the default underyling type of int
llvm-svn: 232498
|
| |
|
|
|
|
|
| |
-irce-print-range-checks prints out the set of range checks recognized
by IRCE.
llvm-svn: 232451
|
| |
|
|
|
|
|
| |
This change adds some comments that justify why a potentially
overflowing operation is safe.
llvm-svn: 232445
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This change to IRCE gets it to recognize "half" range checks. Half
range checks are range checks that only either check if the index is
`slt` some positive integer ("length") or if the index is `sge` `0`.
The range solver does not try to be clever / aggressive about solving
half-range checks -- it transforms "I < L" to "0 <= I < L" and "0 <= I"
to "0 <= I < INT_SMAX". This is safe, but not always optimal.
llvm-svn: 232444
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
pointee type
I'm just going to migrate these in a pretty ad-hoc & incremental way -
providing the backwards compatible API for now, then locally removing
it, fixing a few callers, adding it back in and commiting those callers.
Rinse, repeat.
The assertions should ensure that if I get this wrong we'll find out
about it and not just have one giant patch to revert, recommit, revert,
recommit, etc.
llvm-svn: 232240
|