en Copyright 2015 Java http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/Transforms/RewriteStatepointsForGC/constants.ll#ac81cb7e Allow ptrtoint/inttoptr of non-integral pointer types in IRI don't like landing this change, but it's an acknowledgement of a practical reality. Despite not having well specified semantics for inttoptr and ptrtoint involving non-integral pointer types, they are used in practice. Here's a quick summary of the current pragmatic reality:* I happen to know that the main external user of non-integral pointers has effectively disabled the verifier rules.* RS4GC (the lowering pass for abstract GC machine model which is the key motivation for non-integral pointers), even supports them. We just have all the tests using an integral pointer space to let the verifier run.* Certain idioms (such as alignment checks for alignment N, where any relocation is guaranteed to be N byte aligned) are fine in practice.* As implemented, inttoptr/ptrtoint are CSEd and are not control dependent. This means that any code which is intending to check a particular bit pattern at site of use must be wrapped in an intrinsic or external function call.This change allows them in the Verifier, and updates the LangRef to specific them as implementation dependent. This allows us to acknowledge current reality while still leaving ourselves room to punt on figuring out "good" semantics until the future. List of files: /llvm-project-15.0.7/llvm/test/Transforms/RewriteStatepointsForGC/constants.ll Fri, 11 Jun 2021 20:30:10 +0000 Philip Reames <listmail@philipreames.com> http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/Transforms/RewriteStatepointsForGC/constants.ll#cee313d2 Revert "Temporarily Revert "Add basic loop fusion pass.""The reversion apparently deleted the test/Transforms directory.Will be re-reverting again.llvm-svn: 358552 List of files: /llvm-project-15.0.7/llvm/test/Transforms/RewriteStatepointsForGC/constants.ll Wed, 17 Apr 2019 04:52:47 +0000 Eric Christopher <echristo@gmail.com> http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/Transforms/RewriteStatepointsForGC/constants.ll#4b86d790 [PM] port Rewrite Statepoints For GC to the new pass manager.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 resultsof each function and disallows a single interface for run-on-modulepass action.Decided to copy-paste the main body of this pass.Most of its code is requesting analyses anyway, so not that muchof a copy-paste.The rest of the code movement is to transform all the implementationhelper functions like stripNonValidData into non-member statics.Extended all the related LLVM tests with new-pass-manager use.No failures.Reviewers: sanjoy, anna, reamesReviewed By: annaSubscribers: skatkov, llvm-commitsDifferential Revision: https://reviews.llvm.org/D41162llvm-svn: 320796 List of files: /llvm-project-15.0.7/llvm/test/Transforms/RewriteStatepointsForGC/constants.ll Fri, 15 Dec 2017 09:32:11 +0000 Fedor Sergeev <fedor.sergeev@azul.com> http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/Transforms/RewriteStatepointsForGC/constants.ll#df9db45c [RewriteStatepointsForGC] All constant should have null base pointerCurrently 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/D20584llvm-svn: 270993 List of files: /llvm-project-15.0.7/llvm/test/Transforms/RewriteStatepointsForGC/constants.ll Fri, 27 May 2016 13:13:59 +0000 Igor Laevsky <igmyrj@gmail.com> http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/Transforms/RewriteStatepointsForGC/constants.ll#953f2d2a [RewriteStatepointsForGC] Remove obsolete assertionThis is assertion is no longer necessary since we never recordconstants 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/D20293llvm-svn: 269764 List of files: /llvm-project-15.0.7/llvm/test/Transforms/RewriteStatepointsForGC/constants.ll Tue, 17 May 2016 13:54:10 +0000 Igor Laevsky <igmyrj@gmail.com> http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/Transforms/RewriteStatepointsForGC/constants.ll#f3a4ee75 [RS4GC] Add some missing tests and CHECK: linesI missed porting these in rL259129.llvm-svn: 259203 List of files: /llvm-project-15.0.7/llvm/test/Transforms/RewriteStatepointsForGC/constants.ll Fri, 29 Jan 2016 16:32:25 +0000 Sanjoy Das <sanjoy@playingwithpointers.com> http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/Transforms/RewriteStatepointsForGC/constants.ll#04071080 [RS4GC] Clamp UseDeoptBundles to true and update testsThe full diff for the test directory may be hard to read because of thefilename clash; so here's all that happened as far as the tests areconcerned:```cd test/Transforms/RewriteStatepointsForGCgit rm *llgit mv deopt-bundles/* ./rmdir deopt-bundlesfind . -name '*.ll' | xargs gsed -i 's/-rs4gc-use-deopt-bundles //g'```llvm-svn: 259129 List of files: /llvm-project-15.0.7/llvm/test/Transforms/RewriteStatepointsForGC/constants.ll Fri, 29 Jan 2016 00:28:57 +0000 Sanjoy Das <sanjoy@playingwithpointers.com> http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/Transforms/RewriteStatepointsForGC/constants.ll#734e7334 [RS4GC] Update and simplify handling of Constants in findBaseDefiningValueOfVector().Summary:This is analogous to r256079, which removed an overly strong assertion, andr256812, which simplified the code by replacing three conditionals by one.Reviewers: reamesSubscribers: sanjoy, llvm-commitsDifferential Revision: http://reviews.llvm.org/D16019llvm-svn: 257250 List of files: /llvm-project-15.0.7/llvm/test/Transforms/RewriteStatepointsForGC/constants.ll Sat, 09 Jan 2016 04:02:16 +0000 Manuel Jacob <me@manueljacob.de> http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/Transforms/RewriteStatepointsForGC/constants.ll#d71999ef [gc.statepoint] Change gc.statepoint intrinsic's return type to token type instead of i32 typeSummary: 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, mjacobSubscribers: reames, mjacob, sanjoy, llvm-commitsDifferential Revision: http://reviews.llvm.org/D15662llvm-svn: 256443 List of files: /llvm-project-15.0.7/llvm/test/Transforms/RewriteStatepointsForGC/constants.ll Sat, 26 Dec 2015 07:54:32 +0000 Chen Li <meloli87@gmail.com> http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/Transforms/RewriteStatepointsForGC/constants.ll#5d54689b [RS4GC] Remove an overly strong assertionAs 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 List of files: /llvm-project-15.0.7/llvm/test/Transforms/RewriteStatepointsForGC/constants.ll Sat, 19 Dec 2015 02:38:22 +0000 Philip Reames <listmail@philipreames.com> http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/Transforms/RewriteStatepointsForGC/constants.ll#a1d39ba9 [Statepoints] Support for "patchable" statepoints.Summary:This change adds two new parameters to the statepoint intrinsic, `i64 id`and `i32 num_patch_bytes`. `id` gets propagated to the ID fieldin the generated StackMap section. If the `num_patch_bytes` isnon-zero then the statepoint is lowered to `num_patch_bytes` bytes ofnops instead of a call (the spill and reload code remains unchanged).A non-zero `num_patch_bytes` is useful in situations where a languageruntime requires complete control over how a call is lowered.This change brings statepoints one step closer to patchpoints. Withsome additional work (that is not part of this patch) it should bepossible to get rid of `TargetOpcode::STATEPOINT` altogether.PlaceSafepoints generates `statepoint` wrappers with `id` set to`0xABCDEF00` (the old default value for the ID reported in the stackmap)and `num_patch_bytes` set to `0`. This can be made more sophisticatedlater.Reviewers: reames, pgavlin, swaroop.sridhar, AndyAyersSubscribers: llvm-commitsDifferential Revision: http://reviews.llvm.org/D9546llvm-svn: 237214 List of files: /llvm-project-15.0.7/llvm/test/Transforms/RewriteStatepointsForGC/constants.ll Tue, 12 May 2015 23:52:24 +0000 Sanjoy Das <sanjoy@playingwithpointers.com> http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/Transforms/RewriteStatepointsForGC/constants.ll#cc0431d1 Extend the statepoint intrinsic to allow statepoints to be marked as transitions from GC-aware code to code that is not GC-aware.This changes the shape of the statepoint intrinsic from: @llvm.experimental.gc.statepoint(anyptr target, i32 # call args, i32 unused, ...call args, i32 # deopt args, ...deopt args, ...gc args)to: @llvm.experimental.gc.statepoint(anyptr target, i32 # call args, i32 flags, ...call args, i32 # transition args, ...transition args, i32 # deopt args, ...deopt args, ...gc args)This extension offers the backend the opportunity to insert (somewhat) arbitrary code to manage the transition from GC-aware code to code that is not GC-aware and back.In order to support the injection of transition code, this extension wraps the STATEPOINT ISD node generated by the usual lowering lowering with two additional nodes: GC_TRANSITION_START and GC_TRANSITION_END. The transition arguments that were passed passed to the intrinsic (if any) are lowered and provided as operands to these nodes and may be used by the backend during code generation.Eventually, the lowering of the GC_TRANSITION_{START,END} nodes should be informed by the GC strategy in use for the function containing the intrinsic call; for now, these nodes are instead replaced with no-ops.Differential Revision: http://reviews.llvm.org/D9501llvm-svn: 236888 List of files: /llvm-project-15.0.7/llvm/test/Transforms/RewriteStatepointsForGC/constants.ll Fri, 08 May 2015 18:07:42 +0000 Pat Gavlin <pagavlin@microsoft.com> http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/Transforms/RewriteStatepointsForGC/constants.ll#63294cbb [RewriteStatepointsForGC] Exclude constant values from being considered live at a safepointThere can be various constant pointers in the IR which do not get relocated at a safepoint. One example is the address of a global variable. Another example is a pointer created via inttoptr. Note that the optimizer itself likes to create such inttoptrs when locally propagating constants through dynamically dead code.To deal with this, we need to exclude uses of constants from contributing to the liveness of a safepoint which might reach that use. At some later date, it might be worth exploring what could be done to support the relocation of various special types of "constants", but that's future work.Differential Revision: http://reviews.llvm.org/D9236llvm-svn: 235821 List of files: /llvm-project-15.0.7/llvm/test/Transforms/RewriteStatepointsForGC/constants.ll Sun, 26 Apr 2015 19:48:03 +0000 Philip Reames <listmail@philipreames.com>