[RS4GC] Remove a redundant linear search, NFCI

Since LiveVariables is uniqued (we just created it from a `DenseSet`),
`FindIndex(LiveVariables, LiveVariables[i])` is always `i`.

llvm-svn: 250786

[RS4GC] Clean up `find_index`; NFC

- Bring it up to the LLVM Coding Style
- Sink it inside `CreateGCRelocates`, which is its only user

llvm-svn: 250785

[RS4GC] Re-purpose `normalizeForInvokeSafepoint`; NFC.

`normalizeForInvokeSafepoint` in RewriteStatepointsForGC.cpp, as it is
written today, deals with `gc.relocate` and `gc.result` uses of a
statep

[RS4GC] Re-purpose `normalizeForInvokeSafepoint`; NFC.

`normalizeForInvokeSafepoint` in RewriteStatepointsForGC.cpp, as it is
written today, deals with `gc.relocate` and `gc.result` uses of a
statepoint equally well. This change documents this fact and adds a
test case.

There is no functional change here -- only documentation of existing
functionality.

llvm-svn: 250784

show more ...

[RS4GC] Minor cleanup to `normalizeForInvokeSafepoint`; NFC

llvm-svn: 250783

[RS4GC] Dont' propagate call attrs related to patchable statepoints

The `"statepoint-id"` and `"statepoint-num-patch-bytes"` attributes are
used solely to determine properties of the `gc.statepoint`

[RS4GC] Dont' propagate call attrs related to patchable statepoints

The `"statepoint-id"` and `"statepoint-num-patch-bytes"` attributes are
used solely to determine properties of the `gc.statepoint` being
created. Once the `gc.statepoint` is in place, these should be removed.

llvm-svn: 250491

show more ...

[RS4GC] Bring legalizeCallAttributes up to LLVM coding style; NFC

llvm-svn: 250490

[RS4GC] Use "deopt" operand bundles

Summary:
This is a step towards using operand bundles to carry deopt state till
RewriteStatepointsForGC. The change adds a flag to
RewriteStatepointsForGC that t

[RS4GC] Use "deopt" operand bundles

Summary:
This is a step towards using operand bundles to carry deopt state till
RewriteStatepointsForGC. The change adds a flag to
RewriteStatepointsForGC that teaches it to pick up deopt state from a
`"deopt"` operand bundle attached to the `call` or `invoke` it is
wrapping.

The command line flag added, `-rs4gc-use-deopt-bundles`, will only exist
for a short while. Once we are able to pipe deopt bundle state through
the full optimization pipeline without problems, we will "constant fold"
`-rs4gc-use-deopt-bundles` to `true`.

Reviewers: swaroop.sridhar, reames

Subscribers: llvm-commits, sanjoy

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

llvm-svn: 250489

show more ...

Scalar: Remove remaining ilist iterator implicit conversions

Remove remaining `ilist_iterator` implicit conversions from
LLVMScalarOpts.

This change exposed some scary behaviour in
lib/Transforms/S

Scalar: Remove remaining ilist iterator implicit conversions

Remove remaining `ilist_iterator` implicit conversions from
LLVMScalarOpts.

This change exposed some scary behaviour in
lib/Transforms/Scalar/SCCP.cpp around line 1770. This patch changes a
call from `Function::begin()` to `&Function::front()`, since the return
was immediately being passed into another function that takes a
`Function*`. `Function::front()` started to assert, since the function
was empty. Note that `Function::end()` does not point at a legal
`Function*` -- it points at an `ilist_half_node` -- so the other
function was getting garbage before. (I added the missing check for
`Function::isDeclaration()`.)

Otherwise, no functionality change intended.

llvm-svn: 250211

show more ...

[RS4GC] Refactoring to make a later change easier, NFCI

Summary:
These non-semantic changes will help make a later change adding
support for deopt operand bundles more streamlined.

Reviewers: reame

[RS4GC] Refactoring to make a later change easier, NFCI

Summary:
These non-semantic changes will help make a later change adding
support for deopt operand bundles more streamlined.

Reviewers: reames, swaroop.sridhar

Subscribers: sanjoy, llvm-commits

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

llvm-svn: 249779

show more ...

[RS4GC] Don't copy ADT's unneccessarily, NFCI

Summary: Use `const auto &` instead of `auto` in `makeStatepointExplicit`.

Reviewers: reames, swaroop.sridhar

Subscribers: llvm-commits

Differential

[RS4GC] Don't copy ADT's unneccessarily, NFCI

Summary: Use `const auto &` instead of `auto` in `makeStatepointExplicit`.

Reviewers: reames, swaroop.sridhar

Subscribers: llvm-commits

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

llvm-svn: 249776

show more ...

[RS4GC] Use AssertingVH for RematerializedValueMapTy, NFCI

Reviewers: reames, swaroop.sridhar

Subscribers: llvm-commits

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

llvm-svn: 249620

[RS4GC] Remove an unnecessary assert & related variables

I don't think this assert adds much value, and removing it and related
variables avoids an "unused variable" warning in release builds.

llvm

[RS4GC] Remove an unnecessary assert & related variables

I don't think this assert adds much value, and removing it and related
variables avoids an "unused variable" warning in release builds.

llvm-svn: 249511

show more ...

[RS4GC] Cosmetic cleanup, NFC

Summary:
A series of cosmetic cleanup changes to RewriteStatepointsForGC:

- Rename variables to LLVM style
- Remove some redundant asserts
- Remove an unsued `Pa

[RS4GC] Cosmetic cleanup, NFC

Summary:
A series of cosmetic cleanup changes to RewriteStatepointsForGC:

- Rename variables to LLVM style
- Remove some redundant asserts
- Remove an unsued `Pass *` parameter
- Remove unnecessary variables
- Use C++11 idioms where applicable
- Pass CallSite by value, not reference

Reviewers: reames, swaroop.sridhar

Subscribers: llvm-commits, sanjoy

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

llvm-svn: 249508

show more ...

[RewriteStatepointsForGC] Minor refactor to use shared implementation [NFC]

llvm-svn: 247223

[RewriteStatepointsForGC] Strengthen a confusingly weak assertion [NFC]

The assertion was weaker than it should be and gave the impression we're growing the number of base defining values being cons

[RewriteStatepointsForGC] Strengthen a confusingly weak assertion [NFC]

The assertion was weaker than it should be and gave the impression we're growing the number of base defining values being considered during the fixed point interation. That's not true. The tighter form of the assert is useful documentation.

llvm-svn: 247221

show more ...

[RewriteStatepointsForGC] One last bit of naming [NFCI]

llvm-svn: 247220

[RewriteStatepointsForGC] Further style/naming fixup [NFCI]

llvm-svn: 247217

[RewriteStatepointsForGC] More naming cleanup [NFCI]

llvm-svn: 247213

[RewriteStatepointsForGC] Code cleanup [NFC]

Factor out common code related to naming values, fix a small style issue. More to follow in separate changes.

llvm-svn: 247211

[RewriteStatepointsForGC] Extend base pointer inference to handle insertelement

This change is simply enhancing the existing inference algorithm to handle insertelement instructions by conservativel

[RewriteStatepointsForGC] Extend base pointer inference to handle insertelement

This change is simply enhancing the existing inference algorithm to handle insertelement instructions by conservatively inserting a new instruction to propagate the vector of associated base pointers. In the process, I'm ripping out the peephole optimizations which mostly helped cover the fact this hadn't been done.

Note that most of the newly inserted nodes will be nearly immediately removed by the post insertion optimization pass introduced in 246718. Arguably, we should be trying harder to avoid the malloc traffic here, but I'd rather get the code correct, then worry about compile time.

Unlike previous extensions of the algorithm to handle more case, I discovered the existing code was causing miscompiles in some cases. In particular, we had an implicit assumption that the peephole covered *all* insert element instructions, so if we had a value directly based on a insert element the peephole didn't cover, we proceeded as if it were a base anyways. Not good. I believe we had the same issue with shufflevector which is why I adjusted the predicate for them as well.

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

llvm-svn: 247210

show more ...

[RewriteStatepointsForGC] Make base pointer inference deterministic

Previously, the base pointer algorithm wasn't deterministic. The core fixed point was (of course), but we were inserting new nodes

[RewriteStatepointsForGC] Make base pointer inference deterministic

Previously, the base pointer algorithm wasn't deterministic. The core fixed point was (of course), but we were inserting new nodes and optimizing them in an order which was unspecified and variable. We'd somewhat hacked around this for testing by sorting by value name, but that doesn't solve the general determinism problem.

Instead, we can use the order of traversal over the def/use graph to give us a single consistent ordering. Today, this is a DFS order, but the exact order doesn't mater provided it's deterministic for a given input.

(Q: It is safe to rely on a deterministic order of operands right?)

Note that this only fixes the determinism within a single inference step. The inference step is currently invoked many times in a non-deterministic order. That's a future change in the sequence. :)

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

llvm-svn: 247208

show more ...

[RewriteStatepointsForGC] Extract common code, comment, and fix a build warning [NFC]

llvm-svn: 246810

[RewriteStatepointsForGC] Strengthen invariants around BDVs

As a first step towards a new implementation of the base pointer inference algorithm, introduce an abstraction for BDVs, strengthen the as

[RewriteStatepointsForGC] Strengthen invariants around BDVs

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

show more ...

[RewriteStatepointsForGC] Workaround a lack of determinism in visit order

The visit order being used in the base pointer inference algorithm is currently non-deterministic. When working on http://r

[RewriteStatepointsForGC] Workaround a lack of determinism in visit order

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

show more ...

[RewriteStatepointsForGC] Delete stale comment [NFC]

llvm-svn: 246722