[opaque pointer types] [NFC] GEP: replace get(Pointer)ElementType uses with get{Source,Result}ElementType.

Summary:
GEPOperator: provide getResultElementType alongside getSourceElementType.
This is

[opaque pointer types] [NFC] GEP: replace get(Pointer)ElementType uses with 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

show more ...

[GC] Lower vectors-of-pointers directly by default

This commit changes the default on our lowering of vectors-of-pointers from splitting in RS4GC to reporting them in the final stack map. All of th

[GC] Lower vectors-of-pointers directly by default

This commit changes the default on our lowering of vectors-of-pointers from splitting in RS4GC to reporting them in the final stack map. All of the changes to do so are already in place and tested. Assuming no problems are unearthed in the next week, we will be deleting the old code entirely next Monday.

llvm-svn: 258111

show more ...

[opaque pointer types] Alloca: use getAllocatedType() instead of getType()->getPointerElementType().

Reviewers: mjacob

Subscribers: llvm-commits, dblaikie

Differential Revision: http://reviews.llv

[opaque pointer types] Alloca: use getAllocatedType() instead of getType()->getPointerElementType().

Reviewers: mjacob

Subscribers: llvm-commits, dblaikie

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

llvm-svn: 258028

show more ...

[RS4GC] Update and simplify handling of Constants in findBaseDefiningValueOfVector().

Summary:
This is analogous to r256079, which removed an overly strong assertion, and
r256812, which simplified t

[RS4GC] Update and simplify handling of Constants in findBaseDefiningValueOfVector().

Summary:
This is analogous to r256079, which removed an overly strong assertion, and
r256812, which simplified the code by replacing three conditionals by one.

Reviewers: reames

Subscribers: sanjoy, llvm-commits

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

llvm-svn: 257250

show more ...

[RS4GC] Unify two asserts. NFC.

llvm-svn: 257247

[rs4gc] Optionally directly relocated vector of pointers

This patch teaches rewrite-statepoints-for-gc to relocate vector-of-pointers directly rather than trying to split them. This builds on the re

[rs4gc] Optionally directly relocated vector of pointers

This patch teaches rewrite-statepoints-for-gc to relocate vector-of-pointers directly rather than trying to split them. This builds on the recent lowering/IR changes to allow vector typed gc.relocates.

The motivation for this is that we recently found a bug in the vector splitting code where depending on visit order, a vector might not be relocated at some safepoint. Specifically, the bug is that the splitting code wasn't updating the side tables (live vector) of other safepoints. As a result, a vector which was live at two safepoints might not be updated at one of them. However, if you happened to visit safepoints in post order over the dominator tree, everything worked correctly. Weirdly, it turns out that post order is actually an incredibly common order to visit instructions in in practice. Frustratingly, I have not managed to write a test case which actually hits this. I can only reproduce it in large IR files produced by actual applications.

Rather than continue to make this code more complicated, we can remove all of the complexity by just representing the relocation of the entire vector natively in the IR.

At the moment, the new functionality is hidden behind a flag. To use this code, you need to pass "-rs4gc-split-vector-values=0". Once I have a chance to stress test with this option and get feedback from other users, my plan is to flip the default and remove the original splitting code. I would just remove it now, but given the rareness of the bug, I figured it was better to leave it in place until the new approach has been stress tested.

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

llvm-svn: 257244

show more ...

Remove static global GCNames from Function.cpp and move it to the Context

This remove the need for locking when deleting a function.

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

From: Meh

Remove static global GCNames from Function.cpp and move it to the Context

This remove the need for locking when deleting a function.

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

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 257139

show more ...

[RS4GC] Add an option to suppress vector splitting

At the moment, this is essentially a diangostic option so that I can start collecting failing test cases, but we will eventually migrate to removin

[RS4GC] Add an option to suppress vector splitting

At the moment, this is essentially a diangostic option so that I can start collecting failing test cases, but we will eventually migrate to removing the vector splitting code entirely.

llvm-svn: 257015

show more ...

[RS4GC] Simplify handling of Constants in findBaseDefiningValue(). NFC.

Summary:
Previously there were three conditionals, checking for global
variables, undef values and everything constant except

[RS4GC] Simplify handling of Constants in findBaseDefiningValue(). NFC.

Summary:
Previously there were three conditionals, checking for global
variables, undef values and everything constant except these two, all three
returning the same value. This commit replaces them by one conditional.

Reviewers: reames

Subscribers: llvm-commits

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

llvm-svn: 256812

show more ...

[Statepoints] Refactor GCRelocateOperands into an intrinsic wrapper. NFC.

Summary:
This commit renames GCRelocateOperands to GCRelocateInst and makes it an
intrinsic wrapper, similar to e.g. MemCpy

[Statepoints] Refactor GCRelocateOperands into an intrinsic wrapper. NFC.

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

show more ...

[RS4GC] Use DenseMap::count() instead of DenseMap::find()/DenseMap::end(). NFC.

llvm-svn: 256586

[RS4GC] Fix rematerialization of bitcast of bitcast.

Summary:
Previously, only the outer (last) bitcast was rematerialized, resulting in a
use of the unrelocated inner (first) bitcast after the stat

[RS4GC] Fix rematerialization of bitcast of bitcast.

Summary:
Previously, only the outer (last) bitcast was rematerialized, resulting in a
use of the unrelocated inner (first) bitcast after the statepoint. See the
test case for an example.

Reviewers: igor-laevsky, reames

Subscribers: reames, alex, llvm-commits, sanjoy

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

llvm-svn: 256520

show more ...

[gc.statepoint] Change gc.statepoint intrinsic's return type to token type instead of i32 type

Summary: This patch changes gc.statepoint intrinsic's return type to token type instead of i32 type. Us

[gc.statepoint] Change gc.statepoint intrinsic's return type to token type instead of i32 type

Summary: This patch changes gc.statepoint intrinsic's return type to token type instead of i32 type. Using token types could prevent LLVM to merge different gc.statepoint nodes into PHI nodes and cause further problems with gc relocations. The patch also changes the way on how gc.relocate and gc.result look for their corresponding gc.statepoint on unwind path. The current implementation uses the selector value extracted from a { i8*, i32 } landingpad as a hook to find the gc.statepoint, while the patch directly uses a token type landingpad (http://reviews.llvm.org/D15405) to find the gc.statepoint.

Reviewers: sanjoy, JosephTremoulet, pgavlin, igor-laevsky, mjacob

Subscribers: reames, mjacob, sanjoy, llvm-commits

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

llvm-svn: 256443

show more ...

[GC] Make GCStrategy::isGCManagedPointer a type predicate not a value predicate [NFC]

Reasons:
1) The existing form was a form of false generality. None of the implemented GCStrategies use anything

[GC] Make GCStrategy::isGCManagedPointer a type predicate not a value predicate [NFC]

Reasons:
1) The existing form was a form of false generality. None of the implemented GCStrategies use anything other than a type. Its becoming more and more clear we're going to need some type of strong GC pointer in the type system and we shouldn't pretend otherwise at this point.
2) The API was awkward when applied to vectors-of-pointers. The old one could have been made to work, but calling isGCManagedPointer(Ty->getScalarType()) is much cleaner than the Value alternatives.
3) The rewriting implementation effectively assumes the type based predicate as well. We should be consistent.

llvm-svn: 256312

show more ...

[RS4GC] Fix base pair printing for constants.

Previously, "%" + name of the value was printed for each derived and base
pointer. This is correct for instructions, but wrong for e.g. globals.

llvm-

[RS4GC] Fix base pair printing for constants.

Previously, "%" + name of the value was printed for each derived and base
pointer. This is correct for instructions, but wrong for e.g. globals.

llvm-svn: 256305

show more ...

Remove deprecated llvm.experimental.gc.result.{int,float,ptr} intrinsics.

Summary:
These were deprecated 11 months ago when a generic
llvm.experimental.gc.result intrinsic, which works for all types

Remove deprecated llvm.experimental.gc.result.{int,float,ptr} intrinsics.

Summary:
These were deprecated 11 months ago when a generic
llvm.experimental.gc.result intrinsic, which works for all types, was added.

Reviewers: sanjoy, reames

Subscribers: sanjoy, chenli, llvm-commits

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

llvm-svn: 256262

show more ...

[RS4GC] Fix crash in the case that a live variable has a constant base.

Summary:
Previously, RS4GC crashed in CreateGCRelocates() because it assumed
that every base is also in the array of live vari

[RS4GC] Fix crash in the case that a live variable has a constant base.

Summary:
Previously, RS4GC crashed in CreateGCRelocates() because it assumed
that every base is also in the array of live variables, which isn't true if a
live variable has a constant base.

This change fixes the crash by making sure CreateGCRelocates() won't try to
relocate a live variable with a constant base. This would be unnecessary
anyway because anything with a constant base won't move.

Reviewers: reames

Subscribers: llvm-commits, sanjoy

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

llvm-svn: 256252

show more ...

[RS4GC] Add an assert which fails if there is a (yet unsupported) addrspacecast.

The slightly strange indentation comes from clang-format.

llvm-svn: 256132

[RS4GC] Remove an overly strong assertion

As shown by the included test case, it's reasonable to end up with constant references during base pointer calculation. The code actually handled this case

[RS4GC] Remove an overly strong assertion

As shown by the included test case, it's reasonable to end up with constant references during base pointer calculation. The code actually handled this case just fine, we only had the assert to help isolate problems under the belief that constant references shouldn't be present in IR generated by managed frontends. This turned out to be wrong on two fronts: 1) Manual Jacobs is working on a language with constant references, and b) we found a case where the optimizer does create them in practice.

llvm-svn: 256079

show more ...

[RS4GC] Use an value handle to help isolate errors quickly

Inspired by the bug reported in 25846. Whatever we end up doing about that one, the value handle change is a generally good one since it w

[RS4GC] Use an value handle to help isolate errors quickly

Inspired by the bug reported in 25846. Whatever we end up doing about that one, the value handle change is a generally good one since it will help catch this type of mistake more quickly.

Patch by: Manuel Jacob

llvm-svn: 255984

show more ...

LPM: Stop threading `Pass *` through all of the loop utility APIs. NFC

A large number of loop utility functions take a `Pass *` and reach
into it to find out which analyses to preserve. There are a

LPM: Stop threading `Pass *` through all of the loop utility APIs. NFC

A large number of loop utility functions take a `Pass *` and reach
into it to find out which analyses to preserve. There are a number of
problems with this:

- The APIs have access to pretty well any Pass state they want, so
it's hard to tell what they may or may not do.

- Other APIs have copied these and pass around a `Pass *` even though
they don't even use it. Some of these just hand a nullptr to the API
since the callers don't even have a pass available.

- Passes in the new pass manager don't work like the current ones, so
the APIs can't be used as is there.

Instead, we should explicitly thread the analysis results that we
actually care about through these APIs. This is both simpler and more
reusable.

llvm-svn: 255669

show more ...

getParent() ^ 3 == getModule() ; NFCI

llvm-svn: 255511

Remove an intermediate lambda. NFC

llvm-svn: 254246

[RS4GC] Strip noalias attribute after statepoint rewrite

We should remove noalias along with dereference and dereference_or_null attributes
because statepoint could potentially touch the entire hea

[RS4GC] Strip noalias attribute after statepoint rewrite

We should remove noalias along with dereference and dereference_or_null attributes
because statepoint could potentially touch the entire heap including noalias objects.

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

llvm-svn: 251333

show more ...

[RS4GC] Rename stripDereferenceabilityInfo into stripNonValidAttributes.

llvm-svn: 251157