summaryrefslogtreecommitdiffstats
path: root/llvm/test/Transforms/RewriteStatepointsForGC
Commit message (Collapse)AuthorAgeFilesLines
* Revert "Temporarily Revert "Add basic loop fusion pass.""Eric Christopher2019-04-1746-0/+3421
| | | | | | | | The reversion apparently deleted the test/Transforms directory. Will be re-reverting again. llvm-svn: 358552
* Temporarily Revert "Add basic loop fusion pass."Eric Christopher2019-04-1746-3421/+0
| | | | | | | | As it's causing some bot failures (and per request from kbarton). This reverts commit r358543/ab70da07286e618016e78247e4a24fcb84077fda. llvm-svn: 358546
* [RS4GC] Expand/standardize tests introduced in rL352059Philip Reames2019-01-241-4/+121
| | | | | | Write a couple of variations on vector geps w/both scalars and vectors live over safepoints. Use update_test_checks to show all the IR. llvm-svn: 352062
* [RS4GC] Be slightly less conservative for gep vector_base, scalar_idxPhilip Reames2019-01-241-1/+1
| | | | | | | | After submitting https://reviews.llvm.org/D57138, I realized it was slightly more conservative than needed. The scalar indices don't appear to be a problem on a vector gep, we even had a test for that. Differential Revision: https://reviews.llvm.org/D57161 llvm-svn: 352061
* [RS4GC] Avoid crashing on gep scalar_base, vector_idxPhilip Reames2019-01-242-1/+27
| | | | | | | | | | | | This is an alternative to https://reviews.llvm.org/D57103. After discussion, we dedicided to check this in as a temporary workaround, and pursue a true fix under the original thread. The issue at hand is that the base rewriting algorithm doesn't consider the fact that GEPs can turn a scalar input into a vector of outputs. We had handling for scalar GEPs and fully vector GEPs (i.e. all vector operands), but not the scalar-base + vector-index forms. A true fix here requires treating GEP analogously to extractelement or shufflevector. This patch is merely a workaround. It simply hides the crash at the cost of some ugly code gen for this presumable very rare pattern. Differential Revision: https://reviews.llvm.org/D57138 llvm-svn: 352059
* NFC - Various typo fixes in testsGabor Buella2018-07-041-1/+1
| | | | llvm-svn: 336268
* [RewriteStatepoints] Fix stale parse pointsDaniel Neilson2018-03-053-10/+52
| | | | | | | | | | | | | | | | | | | | | | | | Summary: RewriteStatepointsForGC collects parse points for further processing. During the collection if a callsite is found in an unreachable block (DominatorTree::isReachableFromEntry()) then all unreachable blocks are removed by removeUnreachableBlocks(). Some of the removed blocks could have been reachable according to DominatorTree::isReachableFromEntry(). In this case the collected parse points became stale and resulted in a crash when accessed. The fix is to unconditionally canonicalize the IR to removeUnreachableBlocks and then collect the parse points. The added test crashes with the old version and passes with this patch. Patch by Yevgeny Rouban! Reviewed by: Anna Differential Revision: https://reviews.llvm.org/D43929 llvm-svn: 326748
* [IR] Fix creating mutable versions of TBAA access tagsIvan A. Kosarev2018-02-131-10/+14
| | | | | | | | | | Due to a typo in D41565, mutable TBAA tags created with createMutableTBAAAccessTag() lose their base types. This patch fixes that typo and updates tests respectively. Differential Revision: https://reviews.llvm.org/D42364 llvm-svn: 325008
* [RS4GC] Handle call/invoke instructions as base defining values of vectorsDaniel Neilson2018-01-302-0/+42
| | | | | | | | | | | | | | | | | | Summary: There's an asymmetry in the definitions of findBaseDefiningValueOfVector() and findBaseDefiningValue() of RS4GC. The later handles call and invoke instructions, and the former does not. This appears to be simple oversight. This patch remedies the oversight by adding the call and invoke cases to findBaseDefiningValueOfVector(). Reviewers: DaniilSuchkov, anna Reviewed By: anna Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D42653 llvm-svn: 323764
* [Transforms] Support making mutable versions of new-format TBAA access tagsIvan A. Kosarev2018-01-171-7/+24
| | | | | | Differential Revision: https://reviews.llvm.org/D41565 llvm-svn: 322650
* [RewriteStatepoints] Fix incorrect assertionMax Kazantsev2017-12-281-0/+38
| | | | | | | | | | | | | | | | | | | | `RewriteStatepointsForGC` iterates over function blocks and their predecessors in order of declaration. One of outcomes of this is that callsites are placed in arbitrary order which has nothing to do with travelsar order. On the other hand, function `recomputeLiveInValues` asserts that bases are added to `Info.PointerToBase` before their deried pointers are updated. But if call sites are processed in order different from RPOT, this is not necessarily true. We cannot guarantee that the base was placed there before every pointer derived from it. All we can guarantee is that this base was marked as known base by this point. This patch replaces the fact that we assert from checking that the base was added to the map with assert that the base was marked as known base. Differential Revision: https://reviews.llvm.org/D41593 llvm-svn: 321517
* [PM] port Rewrite Statepoints For GC to the new pass manager.Fedor Sergeev2017-12-1543-0/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The port is nearly straightforward. The only complication is related to the analyses handling, since one of the analyses used in this module pass is domtree, which is a function analysis. That requires asking for the results of each function and disallows a single interface for run-on-module pass action. Decided to copy-paste the main body of this pass. Most of its code is requesting analyses anyway, so not that much of a copy-paste. The rest of the code movement is to transform all the implementation helper functions like stripNonValidData into non-member statics. Extended all the related LLVM tests with new-pass-manager use. No failures. Reviewers: sanjoy, anna, reames Reviewed By: anna Subscribers: skatkov, llvm-commits Differential Revision: https://reviews.llvm.org/D41162 llvm-svn: 320796
* Strip off invariant.start because memory locations arent invariantAnna Thomas2017-11-021-0/+48
| | | | | | | | | | | | The original change was reverted in rL317217 because of the failure in the RS4GC testcase. I couldn't reproduce the failure on my local machine (macbook) but could reproduce it on a linux box. The failure was around removing the uses of invariant.start. The fix here is to just RAUW undef (which was the first implementation in D39388). This is perfectly valid IR as discussed in the review. llvm-svn: 317225
* Revert "[RS4GC] Strip off invariant.start because memory locations arent ↵Anna Thomas2017-11-021-53/+0
| | | | | | | | invariant" This reverts commit r317215, investigating the test failure. llvm-svn: 317217
* [RS4GC] Strip off invariant.start because memory locations arent invariantAnna Thomas2017-11-021-0/+53
| | | | | | | | | | | | | | | | | | | | Summary: Invariant.start on memory locations has the property that the memory location is unchanging. However, this is not true in the face of rewriting statepoints for GC. Teach RS4GC about removing invariant.start so that optimizations after RS4GC does not incorrect sink a load from the memory location past a statepoint. Added test showcasing the issue. Reviewers: reames, apilipenko, dneilson Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D39388 llvm-svn: 317215
* [RS4GC] Look through vector bitcasts when looking for base pointerDaniel Neilson2017-10-131-0/+26
| | | | | | | | | | | | | | | | | | Summary: In RS4GC it is possible that a base pointer is contained in a vector that has undergone a bitcast from one element-pointertype to another. We teach RS4GC how to look through bitcasts of vector types when looking for a base pointer. Reviewers: anna Reviewed By: anna Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D38849 llvm-svn: 315694
* All libcalls should be considered to be GC-leaf functions.Daniel Neilson2017-07-271-0/+14
| | | | | | | | | | | | | | | | | | Summary: It is possible for some passes to materialize a call to a libcall (ex: ldexp, exp2, etc), but these passes will not mark the call as a gc-leaf-function. All libcalls are actually gc-leaf-functions, so we change llvm::callsGCLeafFunction() to tell us that available libcalls are equivalent to gc-leaf-function calls. Reviewers: sanjoy, anna, reames Reviewed By: anna Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D35840 llvm-svn: 309291
* [RS4GC] Drop invalid metadata after pointers are relocatedAnna Thomas2017-06-121-0/+92
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: After RS4GC, we should drop metadata that is no longer valid. These metadata is used by optimizations scheduled after RS4GC, and can cause a miscompile. One such metadata is invariant.load which is used by LICM sinking transform. After rewriting statepoints, the address of a load maybe relocated. With invariant.load metadata on a load instruction, LICM sinking assumes the loaded value (from a dererenceable address) to be invariant, and rematerializes the load operand and the load at the exit block. This transforms the IR to have an unrelocated use of the address after a statepoint, which is incorrect. Other metadata we conservatively remove are related to dereferenceability and noalias metadata. This patch drops such metadata on store and load instructions after rewriting statepoints. Reviewers: reames, sanjoy, apilipenko Reviewed by: reames Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D33756 llvm-svn: 305234
* [RSForGC] Handle vector GEPsSanjoy Das2017-03-171-0/+15
| | | | | | | | | We were not handling getelemenptr instructions of vector type before. Since getelemenptr instructions for vector types follow the same rule as getelementptr instructions for non-vector types, we can just handle them in the same way. llvm-svn: 298028
* [RS4GC] Strengthen coverage: add more testsAnna Thomas2016-10-072-0/+27
| | | | | | | | | | | | Summary: Add tests for cases where we have zero coverage in RS4GC. Reviewers: sanjoy, reames Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D25341 llvm-svn: 283591
* [RS4GC] Handle ShuffleVector instruction in findBasePointerAnna Thomas2016-10-041-0/+79
| | | | | | | | | | | | | | | Summary: This patch modifies the findBasePointer to handle the shufflevector instruction. Tests run: RS4GC tests, local downstream tests. Reviewers: reames, sanjoy Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D25197 llvm-svn: 283219
* [RS4GC] Remat in presence of phi and use live valueAnna Thomas2016-09-221-1/+33
| | | | | | | | | | Summary: Reviewers: Subscribers: llvm-svn: 282150
* [statepoints][experimental] Add support for live-in semantics of values in ↵Philip Reames2016-08-311-0/+23
| | | | | | | | | | | | | | | | deopt bundles This is a first step towards supporting deopt value lowering and reporting entirely with the register allocator. I hope to build on this in the near future to support live-on-return semantics, but I have a use case which allows me to test and investigate code quality with just the live-in semantics so I've chosen to start there. For those curious, my use cases is our implementation of the "__llvm_deoptimize" function we bind to @llvm.deoptimize. I'm choosing not to hard code that fact in the patch and instead make it configurable via function attributes. The basic approach here is modelled on what is done for the "Live In" values on stackmaps and patchpoints. (A secondary goal here is to remove one of the last barriers to merging the pseudo instructions.) We start by adding the operands directly to the STATEPOINT SDNode. Once we've lowered to MI, we extend the remat logic used by the register allocator to fold virtual register uses into StackMap::Indirect entries as needed. This does rely on the fact that the register allocator rematerializes. If it didn't along some code path, we could end up with more vregs than physical registers and fail to allocate. Today, we *only* fold in the register allocator. This can create some weird effects when combined with arguments passed on the stack because we don't fold them appropriately. I have an idea how to fix that, but it needs this patch in place to work on that effectively. (There's some weird interaction with the scheduler as well, more investigation needed.) My near term plan is to land this patch off-by-default, experiment in my local tree to identify any correctness issues and then start fixing codegen problems one by one as I find them. Once I have the live-in lowering fully working (both correctness and code quality), I'm hoping to move on to the live-on-return semantics. Note: I don't have any *known* miscompiles with this patch enabled, but I'm pretty sure I'll find at least a couple. Thus, the "experimental" tag and the fact it's off by default. Differential Revision: https://reviews.llvm.org/D24000 llvm-svn: 280250
* [StatepointsForGC] Rematerialize in the presence of PHIsAnna Thomas2016-08-291-0/+37
| | | | | | | | | | | | | | | | Summary: While walking the use chain for identifying rematerializable values in RS4GC, add the case where the current value and base value are the same PHI nodes. This will aid rematerialization of geps and casts instead of relocating. Reviewers: sanjoy, reames, igor Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D23920 llvm-svn: 279975
* [RewriteStatepointsForGC] All constant should have null base pointerIgor Laevsky2016-05-274-3/+147
| | | | | | | | | | | | | | | | | | Currently we consider that each constant has itself as a base value. I.e "base(const) = const". This introduces couple of problems when we are trying to avoid reporting constants in statepoint live sets: 1. When querying "base( phi(const1, const2) )" we will get "phi(const1, const2)" as a base pointer. Since it's not a constant we will record it in a stack map. However on practice we don't want this to happen (constant are never relocated). 2. base( phi(const, gc ptr) ) = phi( const, base(gc ptr) ). This particular case imposes challenge on our runtime - we don't expect to see constant base pointers other than null. This problems can be avoided by treating all constant as if they were derived from null pointer base. I.e in a first case we will not include constant pointer in a stack map at all. In a second case we will get "phi(null, base(gc ptr))" as a base pointer which is a lot more convenient. Differential Revision: http://reviews.llvm.org/D20584 llvm-svn: 270993
* [RewriteStatepointsForGC] Remove obsolete assertionIgor Laevsky2016-05-171-0/+22
| | | | | | | | | | This is assertion is no longer necessary since we never record constants in the live set anyway. (They are never recorded in the initial live set, and constant bases are removed near line 2119) Differential Revision: http://reviews.llvm.org/D20293 llvm-svn: 269764
* All llvm.deoptimize declarations must use the same calling conventionSanjoy Das2016-05-122-11/+16
| | | | | | | | | | | | | | | | | This new verifier rule lets us unambigously pick a calling convention when creating a new declaration for `@llvm.experimental.deoptimize.<ty>`. It is also congruent with our lowering strategy -- since all calls to `@llvm.experimental.deoptimize` are lowered to calls to `__llvm_deoptimize`, it is reasonable to enforce a unique calling convention. Some of the tests that were breaking this verifier rule have had to be split up into different .ll files. The inliner was violating this rule as well, and has been fixed to avoid producing invalid IR. llvm-svn: 269261
* [RS4GC] Use SetVector/MapVector instead of DenseSet/DenseMap to guarantee ↵Igor Laevsky2016-05-044-7/+7
| | | | | | | | | | | | | | | stable ordering Goal of this change is to guarantee stable ordering of the statepoint arguments and other newly inserted values such as gc.relocates. Previously we had explicit sorting in a couple of places. However for unnamed values ordering was partial and overall we didn't have any strong invariant regarding it. This change switches all data structures to use SetVector's and MapVector's which provide possibility for deterministic iteration over them. Explicit sorting is now redundant and was removed. Differential Revision: http://reviews.llvm.org/D19669 llvm-svn: 268502
* [RS4GC] Add a test case around calling conventions; NFCSanjoy Das2016-05-031-0/+11
| | | | llvm-svn: 268436
* [RS4GC] Better codegen for deoptimize callsSanjoy Das2016-04-051-2/+14
| | | | | | | | | Don't emit a gc.result for a statepoint lowered from @llvm.experimental.deoptimize since the call into __llvm_deoptimize is effectively noreturn. Instead follow the corresponding gc.statepoint with an "unreachable". llvm-svn: 265485
* [RS4GC] Lower calls to @llvm.experimental.deoptimizeSanjoy Das2016-03-251-0/+23
| | | | | | | | | | | | | | This changes RS4GC to lower calls to ``@llvm.experimental.deoptimize`` to gc.statepoints wrapping ``__llvm_deoptimize``, and changes ``callsGCLeafFunction`` to recognize ``@llvm.experimental.deoptimize`` as a non GC leaf function. I've had to hard code the ``"__llvm_deoptimize"`` name in RewriteStatepointsForGC; since ``TargetLibraryInfo`` is available only during codegen. This isn't without precedent in the codebase, so I'm not overtly concerned. llvm-svn: 264456
* [RS4GC] "Constant fold" the rs4gc-split-vector-values flagPhilip Reames2016-02-222-168/+1
| | | | | | This flag was part of a migration to a new means of handling vectors-of-points which was described in the llvm-dev thread "FYI: Relocating vector of pointers". The old code path has been off by default for a while without complaints, so time to cleanup. llvm-svn: 261569
* [RS4GC] Revert optimization attempt due to memory corruptionPhilip Reames2016-02-225-13/+41
| | | | | | | | This change reverts "246133 [RewriteStatepointsForGC] Reduce the number of new instructions for base pointers" and a follow on bugfix 12575. As pointed out in pr25846, this code suffers from a memory corruption bug. Since I'm (empirically) not going to get back to this any time soon, simply reverting the problematic change is the right answer. llvm-svn: 261565
* [RS4GC] Remove unnecessary redirections from tests; NFCSanjoy Das2016-01-293-3/+3
| | | | llvm-svn: 259204
* [RS4GC] Add some missing tests and CHECK: linesSanjoy Das2016-01-292-2/+159
| | | | | | I missed porting these in rL259129. llvm-svn: 259203
* [RS4GC] Clamp UseDeoptBundles to true and update testsSanjoy Das2016-01-2964-2655/+531
| | | | | | | | | | | | | | | | The full diff for the test directory may be hard to read because of the filename clash; so here's all that happened as far as the tests are concerned: ``` cd test/Transforms/RewriteStatepointsForGC git rm *ll git mv deopt-bundles/* ./ rmdir deopt-bundles find . -name '*.ll' | xargs gsed -i 's/-rs4gc-use-deopt-bundles //g' ``` llvm-svn: 259129
* [RS4GC] Port three tests to the deopt bundles directorySanjoy Das2016-01-293-0/+72
| | | | | | | | two-invokes-one-landingpad.ll was only moved (and not "ported"), but having everything in the `deopt-bundles` directory will make later changes more obvious. llvm-svn: 259125
* [RS4GC] Change opt %s to opt < %s; NFCSanjoy Das2016-01-2820-20/+20
| | | | | | | | This is as per http://llvm.org/docs/TestingGuide.html#fragile-tests. I didn't touch the tests outside deopt-bundles/ since they'll be gone soon. llvm-svn: 259097
* [PlaceSafepoints] Clamp NoStatepoints to trueSanjoy Das2016-01-286-0/+297
| | | | | | | | | This change permanently clamps -spp-no-statepoints to true (the code deletion will come later). Tests that specifically tested PlaceSafepoint's ability to wrap calls in gc.statepoint have been moved to RS4GC's test suite. llvm-svn: 259096
* Add a "gc-transition" operand bundleSanjoy Das2016-01-201-0/+8
| | | | | | | | | | | | | | | | | | | Summary: This adds a new kind of operand bundle to LLVM denoted by the `"gc-transition"` tag. Inputs to `"gc-transition"` operand bundle are lowered into the "transition args" section of `gc.statepoint` by `RewriteStatepointsForGC`. This removes the last bit of functionality that was unsupported in the deopt bundle based code path in `RewriteStatepointsForGC`. Reviewers: pgavlin, JosephTremoulet, reames Subscribers: sanjoy, mcrosier, llvm-commits Differential Revision: http://reviews.llvm.org/D16342 llvm-svn: 258338
* [RS4GC] Update and simplify handling of Constants in ↵Manuel Jacob2016-01-091-1/+10
| | | | | | | | | | | | | | | | 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
* [rs4gc] Optionally directly relocated vector of pointersPhilip Reames2016-01-093-2/+114
| | | | | | | | | | | | | | 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
* [SplitLandingPadPredecessors] Create a PHINode for the original landingpad ↵Chen Li2016-01-061-0/+33
| | | | | | | | | | | | | | only if it has some uses Summary: This patch adds a check in SplitLandingPadPredecessors to see if the original landingpad instruction has any uses. If not, we don't need to create a PHINode for it in the joint block since it's gonna be a dead code anyway. The motivation for this patch is that we found a bug that SplitLandingPadPredecessors created a PHINode of token type landingpad, which failed the verifier since PHINode can not be token type. However, the created PHINode will never be used in our code pattern. This patch will workaround this bug, and we might add supports in SplitLandingPadPredecessors to handle token type landingpad with uses in the future. Reviewers: reames Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D15835 llvm-svn: 256972
* [RS4GC] Fix rematerialization of bitcast of bitcast.Manuel Jacob2015-12-281-0/+34
| | | | | | | | | | | | | | | 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
* Fix safepoint intrinsic signatures in test.Benjamin Kramer2015-12-262-4/+4
| | | | | | Should bring back the bots after r256443. llvm-svn: 256450
* [gc.statepoint] Change gc.statepoint intrinsic's return type to token type ↵Chen Li2015-12-2632-162/+162
| | | | | | | | | | | | | | 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
* [RS4GC] Fix base pair printing for constants.Manuel Jacob2015-12-232-2/+2
| | | | | | | 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
* Remove deprecated llvm.experimental.gc.result.{int,float,ptr} intrinsics.Manuel Jacob2015-12-221-2/+2
| | | | | | | | | | | | | | 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
* [RS4GC] Fix crash in the case that a live variable has a constant base.Manuel Jacob2015-12-222-0/+39
| | | | | | | | | | | | | | | | | | | 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
* [RS4GC] Remove an overly strong assertionPhilip Reames2015-12-191-0/+35
| | | | | | 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
OpenPOWER on IntegriCloud