[RewriteStatepointsForGC] Cleanup - replace std::vector usage [NFC]

Migrate std::vector usage to a combination of SmallVector and ArrayRef.

llvm-svn: 230079

[RewriteStatepointsForGC] More style cleanup [NFC]

Use llvm_unreachable where appropriate, use SmallVector where easy to do so, introduce typedefs for planned type migrations.

llvm-svn: 230068

[RewriteStatepointsForGC] Remove notion of SafepointBounds [NFC]

The notion of a range of inserted safepoint related code is no longer really applicable. This survived over from an earlier implemen

[RewriteStatepointsForGC] Remove notion of SafepointBounds [NFC]

The notion of a range of inserted safepoint related code is no longer really applicable. This survived over from an earlier implementation. Just saving the inserted gc.statepoint and working from that is far clearer given the current code structure. Particularly when invokable statepoints get involved.

llvm-svn: 230063

show more ...

[GC, RewriteStatepointsForGC] Style cleanup and bug fix

When doing style cleanup, I noticed a minor bug in this code. If we have a pointer that we think is unused after a statepoint and thus doesn'

[GC, RewriteStatepointsForGC] Style cleanup and bug fix

When doing style cleanup, I noticed a minor bug in this code. If we have a pointer that we think is unused after a statepoint and thus doesn't need relocation, we store a null pointer into the alloca we're about to promote. This helps turn a mistake in liveness analysis into an easily debuggable crash. It turned out this code had never been updated to handle invoke statepoints.

There's no test for this. Without a bug in liveness, it appears impossible to make this trigger in a way which is visible in the resulting IR. We might store the null, but when promoting the alloca, there will be no uses and thus nothing to test against. Suggestions on how to test are very welcome.

llvm-svn: 230047

show more ...

Use unreachable instead of assert(false) to silence MSVC warning

llvm-svn: 230045

[GC] Style cleanup for RewriteStatepointForGC (1 of many) [NFC]

Starting to update variable naming and types to match LLVM style. This will be an incremental process to minimize the chance of break

[GC] Style cleanup for RewriteStatepointForGC (1 of many) [NFC]

Starting to update variable naming and types to match LLVM style. This will be an incremental process to minimize the chance of breakage as I work. Step one, rename member variables to LLVM CamelCase and use llvm's ADT. Much more to come.

llvm-svn: 230042

show more ...

Bugfix for 229954

Before calling Function::getGC to test for enablement, we need to make sure there's actually a GC at all via Function::hasGC. Otherwise, we'd crash on functions without a GC. Tha

Bugfix for 229954

Before calling Function::getGC to test for enablement, we need to make sure there's actually a GC at all via Function::hasGC. Otherwise, we'd crash on functions without a GC. Thankfully, this only mattered if you manually scheduled the pass, but still, oops. :(

llvm-svn: 230040

show more ...

RewriteStatepointsForGC: Move details into anonymous namespaces. NFC.

While there reduce the number of duplicated std::map lookups.

llvm-svn: 230012

Wrap recursive function only used in assert in #ifndef NDEBUG.

Avoids unused function warnings in Release builds.

llvm-svn: 230009

Fix build in release mode, four cases of -Wunused-variable.

llvm-svn: 229976

Adjust enablement of RewriteStatepointsForGC

When back merging the changes in 229945 I noticed that I forgot to mark the test cases with the appropriate GC. We want the rewriting to be off by defau

Adjust enablement of RewriteStatepointsForGC

When back merging the changes in 229945 I noticed that I forgot to mark the test cases with the appropriate GC. We want the rewriting to be off by default (even when manually added to the pass order), not on-by default. To keep the current test working, mark them as using the statepoint-example GC and whitelist that GC.

Longer term, we need a better selection mechanism here for both actual usage and testing. As I migrate more tests to the in tree version of this pass, I will probably need to update the enable/disable logic as well.

llvm-svn: 229954

show more ...

Add a pass for constructing gc.statepoint sequences w/explicit relocations

This patch consists of a single pass whose only purpose is to visit previous inserted gc.statepoints which do not have gc.r

Add a pass for constructing gc.statepoint sequences w/explicit relocations

This patch consists of a single pass whose only purpose is to visit previous inserted gc.statepoints which do not have gc.relocates inserted yet, and insert them. This can be used either immediately after IR generation to perform 'early safepoint insertion' or late in the pass order to perform 'late insertion'.

This patch is setting the stage for work to continue in tree. In particular, there are known naming and style violations in the current patch. I'll try to get those resolved over the next week or so. As I touch each area to make style changes, I need to make sure we have adequate testing in place. As part of the cleanup, I will be cleaning up a collection of test cases we have out of tree and submitting them upstream. The tests included in this change are very basic and mostly to provide examples of usage.

The pass has several main subproblems it needs to address:
- First, it has identify any live pointers. In the current code, the use of address spaces to distinguish pointers to GC managed objects is hard coded, but this will become parametrizable in the near future. Note that the current change doesn't actually contain a useful liveness analysis. It was seperated into a followup change as the code wasn't ready to be shared. Instead, the current implementation just considers any dominating def of appropriate pointer type to be live.
- Second, it has to identify base pointers for each live pointer. This is a fairly straight forward data flow algorithm.
- Third, the information in the previous steps is used to actually introduce rewrites. Rather than trying to do this by hand, we simply re-purpose the code behind Mem2Reg to do this for us.

llvm-svn: 229945

show more ...