[RewriteStatepointsForGC] Pull a function out of anon namespace [NFC]

Thanks to David Blaikie for noticing in previous commit.

llvm-svn: 246721

[RewriteStatepointsForGC] Bugfix for change 246133

Fix a bug in change 246133. I didn't handle the case where we had a cycle in the use graph and could add an instruction we were about to erase back

[RewriteStatepointsForGC] Bugfix for change 246133

Fix a bug in change 246133. I didn't handle the case where we had a cycle in the use graph and could add an instruction we were about to erase back on to the worklist. Oddly, I have not been able to write a small test case for this, even with the AssertingVH added. I have confirmed the basic theory for the fix on a large failing example, but all attempts to reduce that to something appropriate for a test case have failed.

Differential Revision: http://reviews.llvm.org/D12575

llvm-svn: 246718

show more ...

Fix release build warning for unused function

llvm-svn: 246717

[RewriteStatepointsForGC] Improve debug output [NFC]

llvm-svn: 246713

[RewriteStatepointsForGC] Reduce the number of new instructions for base pointers

When computing base pointers, we introduce new instructions to propagate the base of existing instructions which mig

[RewriteStatepointsForGC] Reduce the number of new instructions for base pointers

When computing base pointers, we introduce new instructions to propagate the base of existing instructions which might not be bases. However, the algorithm doesn't make any effort to recognize when the new instruction to be inserted is the same as an existing one already in the IR. Since this is happening immediately before rewriting, we don't really have a chance to fix it after the pass runs without teaching loop passes about statepoints.

I'm really not thrilled with this patch. I've rewritten it 4 different ways now, but this is the best I've come up with. The case where the new instruction is just the original base defining value could be merged into the existing algorithm with some complexity. The problem is that we might have something like an extractelement from a phi of two vectors. It may be trivially obvious that the base of the 0th element is an existing instruction, but I can't see how to make the algorithm itself figure that out. Thus, I resort to the call to SimplifyInstruction instead.

Note that we can only adjust the instructions we've inserted ourselves. The live sets are still being tracked in side structures at this point in the code. We can't easily muck with instructions which might be in them. Long term, I'm really thinking we need to materialize the live pointer sets explicitly in the IR somehow rather than using side structures to track them.

Differential Revision: http://reviews.llvm.org/D12004

llvm-svn: 246133

show more ...

[RewriteStatepointsForGC] Avoid using unrelocated pointers after safepoints

To be clear: this is an *optimization* not a correctness change.

CodeGenPrep likes to duplicate icmps feeding branch inst

[RewriteStatepointsForGC] Avoid using unrelocated pointers after safepoints

To be clear: this is an *optimization* not a correctness change.

CodeGenPrep likes to duplicate icmps feeding branch instructions to take advantage of x86's ability to fuze many comparison/branch patterns into a single micro-op and to reduce the need for materializing i1s into general registers. PlaceSafepoints likes to place safepoint polls right at the end of basic blocks (immediately before terminators) when inserting entry and backedge safepoints. These two heuristics interact in a somewhat unfortunate way where the branch terminating the original block will be controlled by a condition driven by unrelocated pointers. This forces the register allocator to keep both the relocated and unrelocated values of the pointers feeding the icmp alive over the safepoint poll.

One simple fix would have been to just adjust PlaceSafepoints to move one back in the basic block, but you can reach similar cases as a result of LICM or other hoisting passes. As a result, doing a post insertion fixup seems to be more robust.

I considered doing this in CodeGenPrep itself, but having to update the live sets of already rewritten safepoints gets complicated fast. In particular, you can't just use def/use information because by moving the icmp, we're extending the live range of it's inputs potentially.

Instead, this patch teaches RewriteStatepointsForGC to make the required adjustments before making the relocations explicit in the IR. This change really highlights the fact that RSForGC is a CodeGenPrep-like pass which is performing target specific lowering. In the long run, we may even want to combine the two though this would require a lot more smarts to be integrated into RSForGC first. We currently rely on being able to run a set of cleanup passes post rewriting because the IR RSForGC generates is pretty damn ugly.

Differential Revision: http://reviews.llvm.org/D11819

llvm-svn: 244821

show more ...

[RewriteStatepointsForGC] Handle extractelement fully in the base pointer algorithm

When rewriting the IR such that base pointers are available for every live pointer, we potentially need to duplica

[RewriteStatepointsForGC] Handle extractelement fully in the base pointer algorithm

When rewriting the IR such that base pointers are available for every live pointer, we potentially need to duplicate instructions to propagate the base. The original code had only handled PHI and Select under the belief those were the only instructions which would need duplicated. When I added support for vector instructions, I'd added a collection of hacks for ExtractElement which caught most of the common cases. Of course, I then found the one test case my hacks couldn't cover. :)

This change removes all of the early hacks for extract element. By defining extractelement as a BDV (rather than trying to look through it), we can extend the rewriting algorithm to duplicate the extract as needed. Note that a couple of peephole optimizations were left in for the moment, because while we now handle extractelement as a first class citizen, we're not yet handling insertelement. That change will follow in the near future.

llvm-svn: 244808

show more ...

Fix some comment typos.

llvm-svn: 244402

Rename inst_range() to instructions() for consistency. NFC

llvm-svn: 244248

De-constify pointers to Type since they can't be modified. NFC

This was already done in most places a while ago. This just fixes the ones that crept in over time.

llvm-svn: 243842

[RewriteStatepointsForGC] Adjust naming scheme to be more stable

The names for instructions inserted were previous dependent on iteration order. By deriving the names from the original instructions

[RewriteStatepointsForGC] Adjust naming scheme to be more stable

The names for instructions inserted were previous dependent on iteration order. By deriving the names from the original instructions, we can avoid instability in tests without resorting to ordered traversals. It also makes the IR mildly easier to read at large scale.

llvm-svn: 243140

show more ...

[RewriteStatepointsForGC] Fix release build warning

llvm-svn: 243076

[RewriteStatepointsForGC] Use a worklist algorithm for first part of base pointer algorithm [NFC]

The new code should hopefully be equivalent to the old code; it just uses a worklist to track instru

[RewriteStatepointsForGC] Use a worklist algorithm for first part of base pointer algorithm [NFC]

The new code should hopefully be equivalent to the old code; it just uses a worklist to track instructions which need to visited rather than iterating over all instructions visited each time. This should be faster, but the primary benefit is that the purpose should be more clear and the diff of adding another instruction type (forthcoming) much more obvious.

Differential Revision: http://reviews.llvm.org/D11480

llvm-svn: 243071

show more ...

[RewriteStatepointsForGC] Rename PhiState to reflect that it's associated w/more than just PHIs

Today, Select instructions also have associated PhiStates. In the near future, so will ExtractElement

[RewriteStatepointsForGC] Rename PhiState to reflect that it's associated w/more than just PHIs

Today, Select instructions also have associated PhiStates. In the near future, so will ExtractElement and SuffleVector.

llvm-svn: 243056

show more ...

[RewriteStatepointsForGC] Use idomatic mechanisms for debug tracing [NFC]

Deleting much of the code using trace-rewrite-statepoints and use idiomatic DEBUG statements instead. This includes adding

[RewriteStatepointsForGC] Use idomatic mechanisms for debug tracing [NFC]

Deleting much of the code using trace-rewrite-statepoints and use idiomatic DEBUG statements instead. This includes adding operator<< to a helper class.

llvm-svn: 243054

show more ...

[RewriteStatepointsForGC] Simplify code around meet of PhiStates [NFC]

We don't need to pass in the map from BDV to PhiStates; we can instead handle that externally and let the MeetPhiStates helper

[RewriteStatepointsForGC] Simplify code around meet of PhiStates [NFC]

We don't need to pass in the map from BDV to PhiStates; we can instead handle that externally and let the MeetPhiStates helper class just meet PhiStates.

llvm-svn: 243045

show more ...

[PM/AA] Remove all of the dead AliasAnalysis pointers being threaded
through APIs that are no longer necessary now that the update API has
been removed.

This will make changes to the AA interfaces s

[PM/AA] Remove all of the dead AliasAnalysis pointers being threaded
through APIs that are no longer necessary now that the update API has
been removed.

This will make changes to the AA interfaces significantly less
disruptive (I hope). Either way, it seems like a really nice cleanup.

llvm-svn: 242882

show more ...

[RewriteStatepointsForGC] minor style cleanup

Use a named lambda for readability, common some code, remove a stale comments, and use llvm style variable names.

llvm-svn: 242827

[RewriteStatepointsForGC] Hoist some code out of a loop

llvm-svn: 242808

[RewriteStatepointsForGC] Delete trivial code

A bit more code cleanup: delete some a trivial true assertion and supporting code, remove a redundant cast, and use count in assertions where feasible.

[RewriteStatepointsForGC] Delete trivial code

A bit more code cleanup: delete some a trivial true assertion and supporting code, remove a redundant cast, and use count in assertions where feasible.

llvm-svn: 242805

show more ...

[RewriteStatepointsForGC] Minor code cleanup [NFC]

We can use builders to simplify part of the code and we only check for the existance of the metadata value; this enables us to delete some redundan

[RewriteStatepointsForGC] Minor code cleanup [NFC]

We can use builders to simplify part of the code and we only check for the existance of the metadata value; this enables us to delete some redundant code.

llvm-svn: 242751

show more ...

[RewriteStatepointsForGC] Generalized vector phi/select handling for base pointers

This change extends the detection of base pointers for vector constructs to handle arbitrary phi and select nodes.

[RewriteStatepointsForGC] Generalized vector phi/select handling for base pointers

This change extends the detection of base pointers for vector constructs to handle arbitrary phi and select nodes. The existing non-vector code already handles those, so this is basically just extending the vector special case to be less special cased. It still isn't generalized vector handling since we can't handle arbitrary vector instructions (e.g. shufflevectors), but it's a lot closer.

The general structure of the change is as follows:
* Extend the base defining value relation over a subset of vector instructions and vector typed phi & select instructions.
* Move scalarization from before base pointer rewriting to after base pointer rewriting. The extension of the BDV relation is sufficient to find vector base phis for vector inputs.
* Preserve the existing special case logic for when the base of a vector element is locally obvious. This general idea could be extended to the scalar case as well.

Differential Revision: http://reviews.llvm.org/D10461#inline-84275

llvm-svn: 240850

show more ...

Revert r240137 (Fixed/added namespace ending comments using clang-tidy. NFC)

Apparently, the style needs to be agreed upon first.

llvm-svn: 240390

Fixed/added namespace ending comments using clang-tidy. NFC

The patch is generated using this command:

tools/clang/tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \
-checks=-*,llvm-namespace-c

Fixed/added namespace ending comments using clang-tidy. NFC

The patch is generated using this command:

tools/clang/tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \
-checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \
llvm/lib/


Thanks to Eugene Kosov for the original patch!

llvm-svn: 240137

show more ...

[Statepoints] Skip a vector copy when uniquing values.

No functionality change intended.

llvm-svn: 239688