2017-05-13 00:25:07 +02:00
|
|
|
//===- llvm/IR/Statepoint.h - gc.statepoint utilities -----------*- C++ -*-===//
|
[Statepoints 3/4] Statepoint infrastructure for garbage collection: SelectionDAGBuilder
This is the third patch in a small series. It contains the CodeGen support for lowering the gc.statepoint intrinsic sequences (223078) to the STATEPOINT pseudo machine instruction (223085). The change also includes the set of helper routines and classes for working with gc.statepoints, gc.relocates, and gc.results since the lowering code uses them.
With this change, gc.statepoints should be functionally complete. The documentation will follow in the fourth change, and there will likely be some cleanup changes, but interested parties can start experimenting now.
I'm not particularly happy with the amount of code or complexity involved with the lowering step, but at least it's fairly well isolated. The statepoint lowering code is split into it's own files and anyone not working on the statepoint support itself should be able to ignore it.
During the lowering process, we currently spill aggressively to stack. This is not entirely ideal (and we have plans to do better), but it's functional, relatively straight forward, and matches closely the implementations of the patchpoint intrinsics. Most of the complexity comes from trying to keep relocated copies of values in the same stack slots across statepoints. Doing so avoids the insertion of pointless load and store instructions to reshuffle the stack. The current implementation isn't as effective as I'd like, but it is functional and 'good enough' for many common use cases.
In the long term, I'd like to figure out how to integrate the statepoint lowering with the register allocator. In principal, we shouldn't need to eagerly spill at all. The register allocator should do any spilling required and the statepoint should simply record that fact. Depending on how challenging that turns out to be, we may invest in a smarter global stack slot assignment mechanism as a stop gap measure.
Reviewed by: atrick, ributzka
llvm-svn: 223137
2014-12-02 19:50:36 +01:00
|
|
|
//
|
2019-01-19 09:50:56 +01:00
|
|
|
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
|
|
|
|
// See https://llvm.org/LICENSE.txt for license information.
|
|
|
|
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
[Statepoints 3/4] Statepoint infrastructure for garbage collection: SelectionDAGBuilder
This is the third patch in a small series. It contains the CodeGen support for lowering the gc.statepoint intrinsic sequences (223078) to the STATEPOINT pseudo machine instruction (223085). The change also includes the set of helper routines and classes for working with gc.statepoints, gc.relocates, and gc.results since the lowering code uses them.
With this change, gc.statepoints should be functionally complete. The documentation will follow in the fourth change, and there will likely be some cleanup changes, but interested parties can start experimenting now.
I'm not particularly happy with the amount of code or complexity involved with the lowering step, but at least it's fairly well isolated. The statepoint lowering code is split into it's own files and anyone not working on the statepoint support itself should be able to ignore it.
During the lowering process, we currently spill aggressively to stack. This is not entirely ideal (and we have plans to do better), but it's functional, relatively straight forward, and matches closely the implementations of the patchpoint intrinsics. Most of the complexity comes from trying to keep relocated copies of values in the same stack slots across statepoints. Doing so avoids the insertion of pointless load and store instructions to reshuffle the stack. The current implementation isn't as effective as I'd like, but it is functional and 'good enough' for many common use cases.
In the long term, I'd like to figure out how to integrate the statepoint lowering with the register allocator. In principal, we shouldn't need to eagerly spill at all. The register allocator should do any spilling required and the statepoint should simply record that fact. Depending on how challenging that turns out to be, we may invest in a smarter global stack slot assignment mechanism as a stop gap measure.
Reviewed by: atrick, ributzka
llvm-svn: 223137
2014-12-02 19:50:36 +01:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// This file contains utility functions and a wrapper class analogous to
|
2019-02-11 08:42:30 +01:00
|
|
|
// CallBase for accessing the fields of gc.statepoint, gc.relocate,
|
2016-03-17 02:56:10 +01:00
|
|
|
// gc.result intrinsics; and some general utilities helpful when dealing with
|
|
|
|
// gc.statepoint.
|
[Statepoints 3/4] Statepoint infrastructure for garbage collection: SelectionDAGBuilder
This is the third patch in a small series. It contains the CodeGen support for lowering the gc.statepoint intrinsic sequences (223078) to the STATEPOINT pseudo machine instruction (223085). The change also includes the set of helper routines and classes for working with gc.statepoints, gc.relocates, and gc.results since the lowering code uses them.
With this change, gc.statepoints should be functionally complete. The documentation will follow in the fourth change, and there will likely be some cleanup changes, but interested parties can start experimenting now.
I'm not particularly happy with the amount of code or complexity involved with the lowering step, but at least it's fairly well isolated. The statepoint lowering code is split into it's own files and anyone not working on the statepoint support itself should be able to ignore it.
During the lowering process, we currently spill aggressively to stack. This is not entirely ideal (and we have plans to do better), but it's functional, relatively straight forward, and matches closely the implementations of the patchpoint intrinsics. Most of the complexity comes from trying to keep relocated copies of values in the same stack slots across statepoints. Doing so avoids the insertion of pointless load and store instructions to reshuffle the stack. The current implementation isn't as effective as I'd like, but it is functional and 'good enough' for many common use cases.
In the long term, I'd like to figure out how to integrate the statepoint lowering with the register allocator. In principal, we shouldn't need to eagerly spill at all. The register allocator should do any spilling required and the statepoint should simply record that fact. Depending on how challenging that turns out to be, we may invest in a smarter global stack slot assignment mechanism as a stop gap measure.
Reviewed by: atrick, ributzka
llvm-svn: 223137
2014-12-02 19:50:36 +01:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2015-06-20 02:00:58 +02:00
|
|
|
#ifndef LLVM_IR_STATEPOINT_H
|
|
|
|
#define LLVM_IR_STATEPOINT_H
|
[Statepoints 3/4] Statepoint infrastructure for garbage collection: SelectionDAGBuilder
This is the third patch in a small series. It contains the CodeGen support for lowering the gc.statepoint intrinsic sequences (223078) to the STATEPOINT pseudo machine instruction (223085). The change also includes the set of helper routines and classes for working with gc.statepoints, gc.relocates, and gc.results since the lowering code uses them.
With this change, gc.statepoints should be functionally complete. The documentation will follow in the fourth change, and there will likely be some cleanup changes, but interested parties can start experimenting now.
I'm not particularly happy with the amount of code or complexity involved with the lowering step, but at least it's fairly well isolated. The statepoint lowering code is split into it's own files and anyone not working on the statepoint support itself should be able to ignore it.
During the lowering process, we currently spill aggressively to stack. This is not entirely ideal (and we have plans to do better), but it's functional, relatively straight forward, and matches closely the implementations of the patchpoint intrinsics. Most of the complexity comes from trying to keep relocated copies of values in the same stack slots across statepoints. Doing so avoids the insertion of pointless load and store instructions to reshuffle the stack. The current implementation isn't as effective as I'd like, but it is functional and 'good enough' for many common use cases.
In the long term, I'd like to figure out how to integrate the statepoint lowering with the register allocator. In principal, we shouldn't need to eagerly spill at all. The register allocator should do any spilling required and the statepoint should simply record that fact. Depending on how challenging that turns out to be, we may invest in a smarter global stack slot assignment mechanism as a stop gap measure.
Reviewed by: atrick, ributzka
llvm-svn: 223137
2014-12-02 19:50:36 +01:00
|
|
|
|
2016-03-17 02:56:10 +01:00
|
|
|
#include "llvm/ADT/Optional.h"
|
2017-06-06 13:49:48 +02:00
|
|
|
#include "llvm/ADT/iterator_range.h"
|
2016-12-06 23:00:57 +01:00
|
|
|
#include "llvm/IR/Attributes.h"
|
2015-02-20 16:28:35 +01:00
|
|
|
#include "llvm/IR/BasicBlock.h"
|
2015-05-12 00:41:07 +02:00
|
|
|
#include "llvm/IR/Constants.h"
|
2015-07-02 04:53:45 +02:00
|
|
|
#include "llvm/IR/Function.h"
|
2017-05-13 00:25:07 +02:00
|
|
|
#include "llvm/IR/Instruction.h"
|
[Statepoints 3/4] Statepoint infrastructure for garbage collection: SelectionDAGBuilder
This is the third patch in a small series. It contains the CodeGen support for lowering the gc.statepoint intrinsic sequences (223078) to the STATEPOINT pseudo machine instruction (223085). The change also includes the set of helper routines and classes for working with gc.statepoints, gc.relocates, and gc.results since the lowering code uses them.
With this change, gc.statepoints should be functionally complete. The documentation will follow in the fourth change, and there will likely be some cleanup changes, but interested parties can start experimenting now.
I'm not particularly happy with the amount of code or complexity involved with the lowering step, but at least it's fairly well isolated. The statepoint lowering code is split into it's own files and anyone not working on the statepoint support itself should be able to ignore it.
During the lowering process, we currently spill aggressively to stack. This is not entirely ideal (and we have plans to do better), but it's functional, relatively straight forward, and matches closely the implementations of the patchpoint intrinsics. Most of the complexity comes from trying to keep relocated copies of values in the same stack slots across statepoints. Doing so avoids the insertion of pointless load and store instructions to reshuffle the stack. The current implementation isn't as effective as I'd like, but it is functional and 'good enough' for many common use cases.
In the long term, I'd like to figure out how to integrate the statepoint lowering with the register allocator. In principal, we shouldn't need to eagerly spill at all. The register allocator should do any spilling required and the statepoint should simply record that fact. Depending on how challenging that turns out to be, we may invest in a smarter global stack slot assignment mechanism as a stop gap measure.
Reviewed by: atrick, ributzka
llvm-svn: 223137
2014-12-02 19:50:36 +01:00
|
|
|
#include "llvm/IR/Instructions.h"
|
2016-01-05 05:03:00 +01:00
|
|
|
#include "llvm/IR/IntrinsicInst.h"
|
[Statepoints 3/4] Statepoint infrastructure for garbage collection: SelectionDAGBuilder
This is the third patch in a small series. It contains the CodeGen support for lowering the gc.statepoint intrinsic sequences (223078) to the STATEPOINT pseudo machine instruction (223085). The change also includes the set of helper routines and classes for working with gc.statepoints, gc.relocates, and gc.results since the lowering code uses them.
With this change, gc.statepoints should be functionally complete. The documentation will follow in the fourth change, and there will likely be some cleanup changes, but interested parties can start experimenting now.
I'm not particularly happy with the amount of code or complexity involved with the lowering step, but at least it's fairly well isolated. The statepoint lowering code is split into it's own files and anyone not working on the statepoint support itself should be able to ignore it.
During the lowering process, we currently spill aggressively to stack. This is not entirely ideal (and we have plans to do better), but it's functional, relatively straight forward, and matches closely the implementations of the patchpoint intrinsics. Most of the complexity comes from trying to keep relocated copies of values in the same stack slots across statepoints. Doing so avoids the insertion of pointless load and store instructions to reshuffle the stack. The current implementation isn't as effective as I'd like, but it is functional and 'good enough' for many common use cases.
In the long term, I'd like to figure out how to integrate the statepoint lowering with the register allocator. In principal, we shouldn't need to eagerly spill at all. The register allocator should do any spilling required and the statepoint should simply record that fact. Depending on how challenging that turns out to be, we may invest in a smarter global stack slot assignment mechanism as a stop gap measure.
Reviewed by: atrick, ributzka
llvm-svn: 223137
2014-12-02 19:50:36 +01:00
|
|
|
#include "llvm/IR/Intrinsics.h"
|
2016-12-06 23:00:57 +01:00
|
|
|
#include "llvm/Support/Casting.h"
|
2017-05-13 00:25:07 +02:00
|
|
|
#include "llvm/Support/MathExtras.h"
|
2016-12-06 23:00:57 +01:00
|
|
|
#include <cassert>
|
|
|
|
#include <cstddef>
|
|
|
|
#include <cstdint>
|
|
|
|
#include <vector>
|
[Statepoints 3/4] Statepoint infrastructure for garbage collection: SelectionDAGBuilder
This is the third patch in a small series. It contains the CodeGen support for lowering the gc.statepoint intrinsic sequences (223078) to the STATEPOINT pseudo machine instruction (223085). The change also includes the set of helper routines and classes for working with gc.statepoints, gc.relocates, and gc.results since the lowering code uses them.
With this change, gc.statepoints should be functionally complete. The documentation will follow in the fourth change, and there will likely be some cleanup changes, but interested parties can start experimenting now.
I'm not particularly happy with the amount of code or complexity involved with the lowering step, but at least it's fairly well isolated. The statepoint lowering code is split into it's own files and anyone not working on the statepoint support itself should be able to ignore it.
During the lowering process, we currently spill aggressively to stack. This is not entirely ideal (and we have plans to do better), but it's functional, relatively straight forward, and matches closely the implementations of the patchpoint intrinsics. Most of the complexity comes from trying to keep relocated copies of values in the same stack slots across statepoints. Doing so avoids the insertion of pointless load and store instructions to reshuffle the stack. The current implementation isn't as effective as I'd like, but it is functional and 'good enough' for many common use cases.
In the long term, I'd like to figure out how to integrate the statepoint lowering with the register allocator. In principal, we shouldn't need to eagerly spill at all. The register allocator should do any spilling required and the statepoint should simply record that fact. Depending on how challenging that turns out to be, we may invest in a smarter global stack slot assignment mechanism as a stop gap measure.
Reviewed by: atrick, ributzka
llvm-svn: 223137
2014-12-02 19:50:36 +01:00
|
|
|
|
|
|
|
namespace llvm {
|
2016-12-06 23:00:57 +01:00
|
|
|
|
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/D9501
llvm-svn: 236888
2015-05-08 20:07:42 +02:00
|
|
|
/// The statepoint intrinsic accepts a set of flags as its third argument.
|
|
|
|
/// Valid values come out of this set.
|
|
|
|
enum class StatepointFlags {
|
|
|
|
None = 0,
|
|
|
|
GCTransition = 1, ///< Indicates that this statepoint is a transition from
|
|
|
|
///< GC-aware code to code that is not GC-aware.
|
[statepoints][experimental] Add support for live-in semantics of values in 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
2016-08-31 17:12:17 +02:00
|
|
|
/// Mark the deopt arguments associated with the statepoint as only being
|
|
|
|
/// "live-in". By default, deopt arguments are "live-through". "live-through"
|
|
|
|
/// requires that they the value be live on entry, on exit, and at any point
|
|
|
|
/// during the call. "live-in" only requires the value be available at the
|
|
|
|
/// start of the call. In particular, "live-in" values can be placed in
|
|
|
|
/// unused argument registers or other non-callee saved registers.
|
|
|
|
DeoptLiveIn = 2,
|
|
|
|
|
|
|
|
MaskAll = 3 ///< A bitmask that includes all valid flags.
|
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/D9501
llvm-svn: 236888
2015-05-08 20:07:42 +02:00
|
|
|
};
|
[Statepoints 3/4] Statepoint infrastructure for garbage collection: SelectionDAGBuilder
This is the third patch in a small series. It contains the CodeGen support for lowering the gc.statepoint intrinsic sequences (223078) to the STATEPOINT pseudo machine instruction (223085). The change also includes the set of helper routines and classes for working with gc.statepoints, gc.relocates, and gc.results since the lowering code uses them.
With this change, gc.statepoints should be functionally complete. The documentation will follow in the fourth change, and there will likely be some cleanup changes, but interested parties can start experimenting now.
I'm not particularly happy with the amount of code or complexity involved with the lowering step, but at least it's fairly well isolated. The statepoint lowering code is split into it's own files and anyone not working on the statepoint support itself should be able to ignore it.
During the lowering process, we currently spill aggressively to stack. This is not entirely ideal (and we have plans to do better), but it's functional, relatively straight forward, and matches closely the implementations of the patchpoint intrinsics. Most of the complexity comes from trying to keep relocated copies of values in the same stack slots across statepoints. Doing so avoids the insertion of pointless load and store instructions to reshuffle the stack. The current implementation isn't as effective as I'd like, but it is functional and 'good enough' for many common use cases.
In the long term, I'd like to figure out how to integrate the statepoint lowering with the register allocator. In principal, we shouldn't need to eagerly spill at all. The register allocator should do any spilling required and the statepoint should simply record that fact. Depending on how challenging that turns out to be, we may invest in a smarter global stack slot assignment mechanism as a stop gap measure.
Reviewed by: atrick, ributzka
llvm-svn: 223137
2014-12-02 19:50:36 +01:00
|
|
|
|
2016-01-05 05:03:00 +01:00
|
|
|
class GCRelocateInst;
|
2016-04-12 20:05:10 +02:00
|
|
|
class GCResultInst;
|
2015-02-19 12:02:11 +01:00
|
|
|
|
2019-02-11 08:42:30 +01:00
|
|
|
bool isStatepoint(const CallBase *Call);
|
2015-07-02 04:53:39 +02:00
|
|
|
bool isStatepoint(const Value *V);
|
|
|
|
bool isStatepoint(const Value &V);
|
[Statepoints 3/4] Statepoint infrastructure for garbage collection: SelectionDAGBuilder
This is the third patch in a small series. It contains the CodeGen support for lowering the gc.statepoint intrinsic sequences (223078) to the STATEPOINT pseudo machine instruction (223085). The change also includes the set of helper routines and classes for working with gc.statepoints, gc.relocates, and gc.results since the lowering code uses them.
With this change, gc.statepoints should be functionally complete. The documentation will follow in the fourth change, and there will likely be some cleanup changes, but interested parties can start experimenting now.
I'm not particularly happy with the amount of code or complexity involved with the lowering step, but at least it's fairly well isolated. The statepoint lowering code is split into it's own files and anyone not working on the statepoint support itself should be able to ignore it.
During the lowering process, we currently spill aggressively to stack. This is not entirely ideal (and we have plans to do better), but it's functional, relatively straight forward, and matches closely the implementations of the patchpoint intrinsics. Most of the complexity comes from trying to keep relocated copies of values in the same stack slots across statepoints. Doing so avoids the insertion of pointless load and store instructions to reshuffle the stack. The current implementation isn't as effective as I'd like, but it is functional and 'good enough' for many common use cases.
In the long term, I'd like to figure out how to integrate the statepoint lowering with the register allocator. In principal, we shouldn't need to eagerly spill at all. The register allocator should do any spilling required and the statepoint should simply record that fact. Depending on how challenging that turns out to be, we may invest in a smarter global stack slot assignment mechanism as a stop gap measure.
Reviewed by: atrick, ributzka
llvm-svn: 223137
2014-12-02 19:50:36 +01:00
|
|
|
|
2019-02-11 08:42:30 +01:00
|
|
|
bool isGCRelocate(const CallBase *Call);
|
2017-06-20 22:54:57 +02:00
|
|
|
bool isGCRelocate(const Value *V);
|
|
|
|
|
2019-02-11 08:42:30 +01:00
|
|
|
bool isGCResult(const CallBase *Call);
|
2017-06-20 22:54:57 +02:00
|
|
|
bool isGCResult(const Value *V);
|
[Statepoints 3/4] Statepoint infrastructure for garbage collection: SelectionDAGBuilder
This is the third patch in a small series. It contains the CodeGen support for lowering the gc.statepoint intrinsic sequences (223078) to the STATEPOINT pseudo machine instruction (223085). The change also includes the set of helper routines and classes for working with gc.statepoints, gc.relocates, and gc.results since the lowering code uses them.
With this change, gc.statepoints should be functionally complete. The documentation will follow in the fourth change, and there will likely be some cleanup changes, but interested parties can start experimenting now.
I'm not particularly happy with the amount of code or complexity involved with the lowering step, but at least it's fairly well isolated. The statepoint lowering code is split into it's own files and anyone not working on the statepoint support itself should be able to ignore it.
During the lowering process, we currently spill aggressively to stack. This is not entirely ideal (and we have plans to do better), but it's functional, relatively straight forward, and matches closely the implementations of the patchpoint intrinsics. Most of the complexity comes from trying to keep relocated copies of values in the same stack slots across statepoints. Doing so avoids the insertion of pointless load and store instructions to reshuffle the stack. The current implementation isn't as effective as I'd like, but it is functional and 'good enough' for many common use cases.
In the long term, I'd like to figure out how to integrate the statepoint lowering with the register allocator. In principal, we shouldn't need to eagerly spill at all. The register allocator should do any spilling required and the statepoint should simply record that fact. Depending on how challenging that turns out to be, we may invest in a smarter global stack slot assignment mechanism as a stop gap measure.
Reviewed by: atrick, ributzka
llvm-svn: 223137
2014-12-02 19:50:36 +01:00
|
|
|
|
2020-05-28 02:16:41 +02:00
|
|
|
/// Represents a gc.statepoint intrinsic call. This extends directly from
|
|
|
|
/// CallBase as the IntrinsicInst only supports calls and gc.statepoint is
|
|
|
|
/// invokable.
|
|
|
|
class GCStatepointInst : public CallBase {
|
|
|
|
public:
|
|
|
|
GCStatepointInst() = delete;
|
|
|
|
GCStatepointInst(const GCStatepointInst &) = delete;
|
|
|
|
GCStatepointInst &operator=(const GCStatepointInst &) = delete;
|
|
|
|
|
|
|
|
static bool classof(const CallBase *I) {
|
|
|
|
if (const Function *CF = I->getCalledFunction())
|
|
|
|
return CF->getIntrinsicID() == Intrinsic::experimental_gc_statepoint;
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool classof(const Value *V) {
|
|
|
|
return isa<CallBase>(V) && classof(cast<CallBase>(V));
|
|
|
|
}
|
2020-05-28 03:02:49 +02:00
|
|
|
|
|
|
|
enum {
|
|
|
|
IDPos = 0,
|
|
|
|
NumPatchBytesPos = 1,
|
|
|
|
CalledFunctionPos = 2,
|
|
|
|
NumCallArgsPos = 3,
|
|
|
|
FlagsPos = 4,
|
|
|
|
CallArgsBeginPos = 5,
|
|
|
|
};
|
|
|
|
|
|
|
|
/// Return the ID associated with this statepoint.
|
|
|
|
uint64_t getID() const {
|
|
|
|
return cast<ConstantInt>(getArgOperand(IDPos))->getZExtValue();
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Return the number of patchable bytes associated with this statepoint.
|
|
|
|
uint32_t getNumPatchBytes() const {
|
|
|
|
const Value *NumPatchBytesVal = getArgOperand(NumPatchBytesPos);
|
|
|
|
uint64_t NumPatchBytes =
|
|
|
|
cast<ConstantInt>(NumPatchBytesVal)->getZExtValue();
|
|
|
|
assert(isInt<32>(NumPatchBytes) && "should fit in 32 bits!");
|
|
|
|
return NumPatchBytes;
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Number of arguments to be passed to the actual callee.
|
|
|
|
int getNumCallArgs() const {
|
|
|
|
return cast<ConstantInt>(getArgOperand(NumCallArgsPos))->getZExtValue();
|
|
|
|
}
|
|
|
|
|
|
|
|
uint64_t getFlags() const {
|
|
|
|
return cast<ConstantInt>(getArgOperand(FlagsPos))->getZExtValue();
|
|
|
|
}
|
2020-05-28 19:45:07 +02:00
|
|
|
|
|
|
|
/// Return the value actually being called or invoked.
|
|
|
|
Value *getActualCalledOperand() const {
|
|
|
|
return getArgOperand(CalledFunctionPos);
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Returns the function called if this is a wrapping a direct call, and null
|
|
|
|
/// otherwise.
|
|
|
|
Function *getActualCalledFunction() const {
|
|
|
|
return dyn_cast_or_null<Function>(getActualCalledOperand());
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Return the type of the value returned by the call underlying the
|
|
|
|
/// statepoint.
|
|
|
|
Type *getActualReturnType() const {
|
|
|
|
auto *CalleeTy =
|
|
|
|
cast<PointerType>(getActualCalledOperand()->getType())->getElementType();
|
|
|
|
return cast<FunctionType>(CalleeTy)->getReturnType();
|
|
|
|
}
|
2020-05-28 22:34:12 +02:00
|
|
|
|
|
|
|
|
|
|
|
/// Return the number of arguments to the underlying call.
|
|
|
|
size_t actual_arg_size() const { return getNumCallArgs(); }
|
|
|
|
/// Return an iterator to the begining of the arguments to the underlying call
|
|
|
|
const_op_iterator actual_arg_begin() const {
|
|
|
|
assert(CallArgsBeginPos <= (int)arg_size());
|
|
|
|
return arg_begin() + CallArgsBeginPos;
|
|
|
|
}
|
|
|
|
/// Return an end iterator of the arguments to the underlying call
|
|
|
|
const_op_iterator actual_arg_end() const {
|
|
|
|
auto I = actual_arg_begin() + actual_arg_size();
|
|
|
|
assert((arg_end() - I) >= 0);
|
|
|
|
return I;
|
|
|
|
}
|
|
|
|
/// range adapter for actual call arguments
|
|
|
|
iterator_range<const_op_iterator> actual_args() const {
|
|
|
|
return make_range(actual_arg_begin(), actual_arg_end());
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Returns an iterator to the begining of the argument range describing gc
|
|
|
|
/// values for the statepoint.
|
|
|
|
const_op_iterator gc_args_begin() const {
|
|
|
|
// The current format has two length prefix bundles between call args and
|
|
|
|
// start of gc args. This will be removed in the near future.
|
|
|
|
const Value *NumGCTransitionArgs = *actual_arg_end();
|
|
|
|
uint64_t NumTrans = cast<ConstantInt>(NumGCTransitionArgs)->getZExtValue();
|
|
|
|
const_op_iterator trans_end = actual_arg_end() + 1 + NumTrans;
|
|
|
|
const Value *NumDeoptArgs = *trans_end;
|
|
|
|
uint64_t NumDeopt = cast<ConstantInt>(NumDeoptArgs)->getZExtValue();
|
|
|
|
auto I = trans_end + 1 + NumDeopt;
|
|
|
|
assert((arg_end() - I) >= 0);
|
|
|
|
return I;
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Return an end iterator for the gc argument range
|
|
|
|
const_op_iterator gc_args_end() const { return arg_end(); }
|
|
|
|
|
|
|
|
/// Return the operand index at which the gc args begin
|
|
|
|
unsigned gcArgsStartIdx() const {
|
|
|
|
return gc_args_begin() - op_begin();
|
|
|
|
}
|
|
|
|
|
|
|
|
/// range adapter for gc arguments
|
|
|
|
iterator_range<const_op_iterator> gc_args() const {
|
|
|
|
return make_range(gc_args_begin(), gc_args_end());
|
|
|
|
}
|
2020-05-28 02:16:41 +02:00
|
|
|
};
|
|
|
|
|
2019-02-11 08:42:30 +01:00
|
|
|
/// A wrapper around a GC intrinsic call, this provides most of the actual
|
[Statepoints 3/4] Statepoint infrastructure for garbage collection: SelectionDAGBuilder
This is the third patch in a small series. It contains the CodeGen support for lowering the gc.statepoint intrinsic sequences (223078) to the STATEPOINT pseudo machine instruction (223085). The change also includes the set of helper routines and classes for working with gc.statepoints, gc.relocates, and gc.results since the lowering code uses them.
With this change, gc.statepoints should be functionally complete. The documentation will follow in the fourth change, and there will likely be some cleanup changes, but interested parties can start experimenting now.
I'm not particularly happy with the amount of code or complexity involved with the lowering step, but at least it's fairly well isolated. The statepoint lowering code is split into it's own files and anyone not working on the statepoint support itself should be able to ignore it.
During the lowering process, we currently spill aggressively to stack. This is not entirely ideal (and we have plans to do better), but it's functional, relatively straight forward, and matches closely the implementations of the patchpoint intrinsics. Most of the complexity comes from trying to keep relocated copies of values in the same stack slots across statepoints. Doing so avoids the insertion of pointless load and store instructions to reshuffle the stack. The current implementation isn't as effective as I'd like, but it is functional and 'good enough' for many common use cases.
In the long term, I'd like to figure out how to integrate the statepoint lowering with the register allocator. In principal, we shouldn't need to eagerly spill at all. The register allocator should do any spilling required and the statepoint should simply record that fact. Depending on how challenging that turns out to be, we may invest in a smarter global stack slot assignment mechanism as a stop gap measure.
Reviewed by: atrick, ributzka
llvm-svn: 223137
2014-12-02 19:50:36 +01:00
|
|
|
/// functionality for Statepoint and ImmutableStatepoint. It is
|
|
|
|
/// templatized to allow easily specializing of const and non-const
|
2019-02-11 08:42:30 +01:00
|
|
|
/// concrete subtypes.
|
2015-07-02 04:53:45 +02:00
|
|
|
template <typename FunTy, typename InstructionTy, typename ValueTy,
|
2020-05-28 02:16:41 +02:00
|
|
|
typename CallTy>
|
[Statepoints 3/4] Statepoint infrastructure for garbage collection: SelectionDAGBuilder
This is the third patch in a small series. It contains the CodeGen support for lowering the gc.statepoint intrinsic sequences (223078) to the STATEPOINT pseudo machine instruction (223085). The change also includes the set of helper routines and classes for working with gc.statepoints, gc.relocates, and gc.results since the lowering code uses them.
With this change, gc.statepoints should be functionally complete. The documentation will follow in the fourth change, and there will likely be some cleanup changes, but interested parties can start experimenting now.
I'm not particularly happy with the amount of code or complexity involved with the lowering step, but at least it's fairly well isolated. The statepoint lowering code is split into it's own files and anyone not working on the statepoint support itself should be able to ignore it.
During the lowering process, we currently spill aggressively to stack. This is not entirely ideal (and we have plans to do better), but it's functional, relatively straight forward, and matches closely the implementations of the patchpoint intrinsics. Most of the complexity comes from trying to keep relocated copies of values in the same stack slots across statepoints. Doing so avoids the insertion of pointless load and store instructions to reshuffle the stack. The current implementation isn't as effective as I'd like, but it is functional and 'good enough' for many common use cases.
In the long term, I'd like to figure out how to integrate the statepoint lowering with the register allocator. In principal, we shouldn't need to eagerly spill at all. The register allocator should do any spilling required and the statepoint should simply record that fact. Depending on how challenging that turns out to be, we may invest in a smarter global stack slot assignment mechanism as a stop gap measure.
Reviewed by: atrick, ributzka
llvm-svn: 223137
2014-12-02 19:50:36 +01:00
|
|
|
class StatepointBase {
|
2020-05-28 02:16:41 +02:00
|
|
|
CallTy *StatepointCall;
|
[Statepoints 3/4] Statepoint infrastructure for garbage collection: SelectionDAGBuilder
This is the third patch in a small series. It contains the CodeGen support for lowering the gc.statepoint intrinsic sequences (223078) to the STATEPOINT pseudo machine instruction (223085). The change also includes the set of helper routines and classes for working with gc.statepoints, gc.relocates, and gc.results since the lowering code uses them.
With this change, gc.statepoints should be functionally complete. The documentation will follow in the fourth change, and there will likely be some cleanup changes, but interested parties can start experimenting now.
I'm not particularly happy with the amount of code or complexity involved with the lowering step, but at least it's fairly well isolated. The statepoint lowering code is split into it's own files and anyone not working on the statepoint support itself should be able to ignore it.
During the lowering process, we currently spill aggressively to stack. This is not entirely ideal (and we have plans to do better), but it's functional, relatively straight forward, and matches closely the implementations of the patchpoint intrinsics. Most of the complexity comes from trying to keep relocated copies of values in the same stack slots across statepoints. Doing so avoids the insertion of pointless load and store instructions to reshuffle the stack. The current implementation isn't as effective as I'd like, but it is functional and 'good enough' for many common use cases.
In the long term, I'd like to figure out how to integrate the statepoint lowering with the register allocator. In principal, we shouldn't need to eagerly spill at all. The register allocator should do any spilling required and the statepoint should simply record that fact. Depending on how challenging that turns out to be, we may invest in a smarter global stack slot assignment mechanism as a stop gap measure.
Reviewed by: atrick, ributzka
llvm-svn: 223137
2014-12-02 19:50:36 +01:00
|
|
|
|
2015-05-06 04:36:28 +02:00
|
|
|
protected:
|
2015-07-02 04:53:36 +02:00
|
|
|
explicit StatepointBase(InstructionTy *I) {
|
2020-05-28 20:28:58 +02:00
|
|
|
StatepointCall = dyn_cast<GCStatepointInst>(I);
|
[Statepoints 3/4] Statepoint infrastructure for garbage collection: SelectionDAGBuilder
This is the third patch in a small series. It contains the CodeGen support for lowering the gc.statepoint intrinsic sequences (223078) to the STATEPOINT pseudo machine instruction (223085). The change also includes the set of helper routines and classes for working with gc.statepoints, gc.relocates, and gc.results since the lowering code uses them.
With this change, gc.statepoints should be functionally complete. The documentation will follow in the fourth change, and there will likely be some cleanup changes, but interested parties can start experimenting now.
I'm not particularly happy with the amount of code or complexity involved with the lowering step, but at least it's fairly well isolated. The statepoint lowering code is split into it's own files and anyone not working on the statepoint support itself should be able to ignore it.
During the lowering process, we currently spill aggressively to stack. This is not entirely ideal (and we have plans to do better), but it's functional, relatively straight forward, and matches closely the implementations of the patchpoint intrinsics. Most of the complexity comes from trying to keep relocated copies of values in the same stack slots across statepoints. Doing so avoids the insertion of pointless load and store instructions to reshuffle the stack. The current implementation isn't as effective as I'd like, but it is functional and 'good enough' for many common use cases.
In the long term, I'd like to figure out how to integrate the statepoint lowering with the register allocator. In principal, we shouldn't need to eagerly spill at all. The register allocator should do any spilling required and the statepoint should simply record that fact. Depending on how challenging that turns out to be, we may invest in a smarter global stack slot assignment mechanism as a stop gap measure.
Reviewed by: atrick, ributzka
llvm-svn: 223137
2014-12-02 19:50:36 +01:00
|
|
|
}
|
2016-12-06 23:00:57 +01:00
|
|
|
|
2020-05-28 02:16:41 +02:00
|
|
|
explicit StatepointBase(CallTy *Call) {
|
2020-05-28 20:28:58 +02:00
|
|
|
StatepointCall = dyn_cast<GCStatepointInst>(Call);
|
[Statepoints 3/4] Statepoint infrastructure for garbage collection: SelectionDAGBuilder
This is the third patch in a small series. It contains the CodeGen support for lowering the gc.statepoint intrinsic sequences (223078) to the STATEPOINT pseudo machine instruction (223085). The change also includes the set of helper routines and classes for working with gc.statepoints, gc.relocates, and gc.results since the lowering code uses them.
With this change, gc.statepoints should be functionally complete. The documentation will follow in the fourth change, and there will likely be some cleanup changes, but interested parties can start experimenting now.
I'm not particularly happy with the amount of code or complexity involved with the lowering step, but at least it's fairly well isolated. The statepoint lowering code is split into it's own files and anyone not working on the statepoint support itself should be able to ignore it.
During the lowering process, we currently spill aggressively to stack. This is not entirely ideal (and we have plans to do better), but it's functional, relatively straight forward, and matches closely the implementations of the patchpoint intrinsics. Most of the complexity comes from trying to keep relocated copies of values in the same stack slots across statepoints. Doing so avoids the insertion of pointless load and store instructions to reshuffle the stack. The current implementation isn't as effective as I'd like, but it is functional and 'good enough' for many common use cases.
In the long term, I'd like to figure out how to integrate the statepoint lowering with the register allocator. In principal, we shouldn't need to eagerly spill at all. The register allocator should do any spilling required and the statepoint should simply record that fact. Depending on how challenging that turns out to be, we may invest in a smarter global stack slot assignment mechanism as a stop gap measure.
Reviewed by: atrick, ributzka
llvm-svn: 223137
2014-12-02 19:50:36 +01:00
|
|
|
}
|
|
|
|
|
2015-05-06 04:36:28 +02:00
|
|
|
public:
|
2020-05-28 02:16:41 +02:00
|
|
|
using arg_iterator = typename CallTy::const_op_iterator;
|
[Statepoints 3/4] Statepoint infrastructure for garbage collection: SelectionDAGBuilder
This is the third patch in a small series. It contains the CodeGen support for lowering the gc.statepoint intrinsic sequences (223078) to the STATEPOINT pseudo machine instruction (223085). The change also includes the set of helper routines and classes for working with gc.statepoints, gc.relocates, and gc.results since the lowering code uses them.
With this change, gc.statepoints should be functionally complete. The documentation will follow in the fourth change, and there will likely be some cleanup changes, but interested parties can start experimenting now.
I'm not particularly happy with the amount of code or complexity involved with the lowering step, but at least it's fairly well isolated. The statepoint lowering code is split into it's own files and anyone not working on the statepoint support itself should be able to ignore it.
During the lowering process, we currently spill aggressively to stack. This is not entirely ideal (and we have plans to do better), but it's functional, relatively straight forward, and matches closely the implementations of the patchpoint intrinsics. Most of the complexity comes from trying to keep relocated copies of values in the same stack slots across statepoints. Doing so avoids the insertion of pointless load and store instructions to reshuffle the stack. The current implementation isn't as effective as I'd like, but it is functional and 'good enough' for many common use cases.
In the long term, I'd like to figure out how to integrate the statepoint lowering with the register allocator. In principal, we shouldn't need to eagerly spill at all. The register allocator should do any spilling required and the statepoint should simply record that fact. Depending on how challenging that turns out to be, we may invest in a smarter global stack slot assignment mechanism as a stop gap measure.
Reviewed by: atrick, ributzka
llvm-svn: 223137
2014-12-02 19:50:36 +01:00
|
|
|
|
2015-05-06 04:36:31 +02:00
|
|
|
enum {
|
2020-05-28 03:02:49 +02:00
|
|
|
CallArgsBeginPos = GCStatepointInst::CallArgsBeginPos,
|
2015-05-06 04:36:31 +02:00
|
|
|
};
|
|
|
|
|
2016-12-06 23:00:57 +01:00
|
|
|
void *operator new(size_t, unsigned) = delete;
|
|
|
|
void *operator new(size_t s) = delete;
|
|
|
|
|
2015-07-02 20:15:18 +02:00
|
|
|
explicit operator bool() const {
|
2019-02-11 08:42:30 +01:00
|
|
|
// We do not assign non-statepoint call instructions to StatepointCall.
|
|
|
|
return (bool)StatepointCall;
|
2015-07-02 04:53:36 +02:00
|
|
|
}
|
|
|
|
|
2019-02-11 08:42:30 +01:00
|
|
|
/// Return the underlying call instruction.
|
2020-05-28 02:16:41 +02:00
|
|
|
CallTy *getCall() const {
|
2015-07-02 04:53:36 +02:00
|
|
|
assert(*this && "check validity first!");
|
2019-02-11 08:42:30 +01:00
|
|
|
return StatepointCall;
|
2015-07-02 04:53:36 +02:00
|
|
|
}
|
[Statepoints 3/4] Statepoint infrastructure for garbage collection: SelectionDAGBuilder
This is the third patch in a small series. It contains the CodeGen support for lowering the gc.statepoint intrinsic sequences (223078) to the STATEPOINT pseudo machine instruction (223085). The change also includes the set of helper routines and classes for working with gc.statepoints, gc.relocates, and gc.results since the lowering code uses them.
With this change, gc.statepoints should be functionally complete. The documentation will follow in the fourth change, and there will likely be some cleanup changes, but interested parties can start experimenting now.
I'm not particularly happy with the amount of code or complexity involved with the lowering step, but at least it's fairly well isolated. The statepoint lowering code is split into it's own files and anyone not working on the statepoint support itself should be able to ignore it.
During the lowering process, we currently spill aggressively to stack. This is not entirely ideal (and we have plans to do better), but it's functional, relatively straight forward, and matches closely the implementations of the patchpoint intrinsics. Most of the complexity comes from trying to keep relocated copies of values in the same stack slots across statepoints. Doing so avoids the insertion of pointless load and store instructions to reshuffle the stack. The current implementation isn't as effective as I'd like, but it is functional and 'good enough' for many common use cases.
In the long term, I'd like to figure out how to integrate the statepoint lowering with the register allocator. In principal, we shouldn't need to eagerly spill at all. The register allocator should do any spilling required and the statepoint should simply record that fact. Depending on how challenging that turns out to be, we may invest in a smarter global stack slot assignment mechanism as a stop gap measure.
Reviewed by: atrick, ributzka
llvm-svn: 223137
2014-12-02 19:50:36 +01:00
|
|
|
|
2020-05-28 03:02:49 +02:00
|
|
|
// Deprecated shims (update all callers to remove)
|
|
|
|
uint64_t getFlags() const { return getCall()->getFlags(); }
|
|
|
|
uint64_t getID() const { return getCall()->getID(); }
|
|
|
|
uint32_t getNumPatchBytes() const { return getCall()->getNumPatchBytes(); }
|
|
|
|
int getNumCallArgs() const { return getCall()->getNumCallArgs(); }
|
2015-07-02 04:53:45 +02:00
|
|
|
ValueTy *getCalledValue() const {
|
2020-05-28 19:45:07 +02:00
|
|
|
return getCall()->getActualCalledOperand();
|
|
|
|
}
|
|
|
|
Type *getActualReturnType() const { return getCall()->getActualReturnType(); }
|
|
|
|
FunTy *getCalledFunction() const {
|
|
|
|
return getCall()->getActualCalledFunction();
|
2015-07-02 04:53:45 +02:00
|
|
|
}
|
|
|
|
|
2020-05-28 19:45:07 +02:00
|
|
|
|
2019-02-11 08:42:30 +01:00
|
|
|
// FIXME: Migrate users of this to `getCall` and remove it.
|
|
|
|
InstructionTy *getInstruction() const { return getCall(); }
|
2015-07-02 04:53:45 +02:00
|
|
|
|
|
|
|
/// Return the caller function for this statepoint.
|
2019-02-11 08:42:30 +01:00
|
|
|
FunTy *getCaller() const { return getCall()->getCaller(); }
|
2015-07-02 04:53:45 +02:00
|
|
|
|
|
|
|
/// Determine if the statepoint cannot unwind.
|
|
|
|
bool doesNotThrow() const {
|
|
|
|
Function *F = getCalledFunction();
|
2019-02-11 08:42:30 +01:00
|
|
|
return getCall()->doesNotThrow() || (F ? F->doesNotThrow() : false);
|
2015-05-06 04:36:31 +02:00
|
|
|
}
|
2015-05-06 04:36:26 +02:00
|
|
|
|
2020-05-28 22:34:12 +02:00
|
|
|
size_t arg_size() const { return getCall()->actual_arg_size(); }
|
|
|
|
arg_iterator arg_begin() const { return getCall()->actual_arg_begin(); }
|
|
|
|
arg_iterator arg_end() const { return getCall()->actual_arg_end(); }
|
|
|
|
iterator_range<arg_iterator> call_args() const {
|
|
|
|
return getCall()->actual_args();
|
[Statepoints 3/4] Statepoint infrastructure for garbage collection: SelectionDAGBuilder
This is the third patch in a small series. It contains the CodeGen support for lowering the gc.statepoint intrinsic sequences (223078) to the STATEPOINT pseudo machine instruction (223085). The change also includes the set of helper routines and classes for working with gc.statepoints, gc.relocates, and gc.results since the lowering code uses them.
With this change, gc.statepoints should be functionally complete. The documentation will follow in the fourth change, and there will likely be some cleanup changes, but interested parties can start experimenting now.
I'm not particularly happy with the amount of code or complexity involved with the lowering step, but at least it's fairly well isolated. The statepoint lowering code is split into it's own files and anyone not working on the statepoint support itself should be able to ignore it.
During the lowering process, we currently spill aggressively to stack. This is not entirely ideal (and we have plans to do better), but it's functional, relatively straight forward, and matches closely the implementations of the patchpoint intrinsics. Most of the complexity comes from trying to keep relocated copies of values in the same stack slots across statepoints. Doing so avoids the insertion of pointless load and store instructions to reshuffle the stack. The current implementation isn't as effective as I'd like, but it is functional and 'good enough' for many common use cases.
In the long term, I'd like to figure out how to integrate the statepoint lowering with the register allocator. In principal, we shouldn't need to eagerly spill at all. The register allocator should do any spilling required and the statepoint should simply record that fact. Depending on how challenging that turns out to be, we may invest in a smarter global stack slot assignment mechanism as a stop gap measure.
Reviewed by: atrick, ributzka
llvm-svn: 223137
2014-12-02 19:50:36 +01:00
|
|
|
}
|
|
|
|
|
2015-07-02 04:53:45 +02:00
|
|
|
ValueTy *getArgument(unsigned Index) {
|
|
|
|
assert(Index < arg_size() && "out of bounds!");
|
|
|
|
return *(arg_begin() + Index);
|
|
|
|
}
|
|
|
|
|
2018-05-01 17:54:18 +02:00
|
|
|
/// Return true if the call or the callee has the given attribute.
|
2015-07-02 04:53:45 +02:00
|
|
|
bool paramHasAttr(unsigned i, Attribute::AttrKind A) const {
|
|
|
|
Function *F = getCalledFunction();
|
2019-02-11 08:42:30 +01:00
|
|
|
return getCall()->paramHasAttr(i + CallArgsBeginPos, A) ||
|
|
|
|
(F ? F->getAttributes().hasAttribute(i, A) : false);
|
[Statepoints 3/4] Statepoint infrastructure for garbage collection: SelectionDAGBuilder
This is the third patch in a small series. It contains the CodeGen support for lowering the gc.statepoint intrinsic sequences (223078) to the STATEPOINT pseudo machine instruction (223085). The change also includes the set of helper routines and classes for working with gc.statepoints, gc.relocates, and gc.results since the lowering code uses them.
With this change, gc.statepoints should be functionally complete. The documentation will follow in the fourth change, and there will likely be some cleanup changes, but interested parties can start experimenting now.
I'm not particularly happy with the amount of code or complexity involved with the lowering step, but at least it's fairly well isolated. The statepoint lowering code is split into it's own files and anyone not working on the statepoint support itself should be able to ignore it.
During the lowering process, we currently spill aggressively to stack. This is not entirely ideal (and we have plans to do better), but it's functional, relatively straight forward, and matches closely the implementations of the patchpoint intrinsics. Most of the complexity comes from trying to keep relocated copies of values in the same stack slots across statepoints. Doing so avoids the insertion of pointless load and store instructions to reshuffle the stack. The current implementation isn't as effective as I'd like, but it is functional and 'good enough' for many common use cases.
In the long term, I'd like to figure out how to integrate the statepoint lowering with the register allocator. In principal, we shouldn't need to eagerly spill at all. The register allocator should do any spilling required and the statepoint should simply record that fact. Depending on how challenging that turns out to be, we may invest in a smarter global stack slot assignment mechanism as a stop gap measure.
Reviewed by: atrick, ributzka
llvm-svn: 223137
2014-12-02 19:50:36 +01:00
|
|
|
}
|
|
|
|
|
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/D9501
llvm-svn: 236888
2015-05-08 20:07:42 +02:00
|
|
|
/// Number of GC transition args.
|
2015-07-02 04:53:41 +02:00
|
|
|
int getNumTotalGCTransitionArgs() const {
|
2015-07-02 04:53:45 +02:00
|
|
|
const Value *NumGCTransitionArgs = *arg_end();
|
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/D9501
llvm-svn: 236888
2015-05-08 20:07:42 +02:00
|
|
|
return cast<ConstantInt>(NumGCTransitionArgs)->getZExtValue();
|
|
|
|
}
|
2019-02-11 08:42:30 +01:00
|
|
|
arg_iterator gc_transition_args_begin() const {
|
2015-07-02 04:53:45 +02:00
|
|
|
auto I = arg_end() + 1;
|
2019-02-11 08:42:30 +01:00
|
|
|
assert((getCall()->arg_end() - I) >= 0);
|
2015-05-12 23:33:48 +02:00
|
|
|
return I;
|
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/D9501
llvm-svn: 236888
2015-05-08 20:07:42 +02:00
|
|
|
}
|
2019-02-11 08:42:30 +01:00
|
|
|
arg_iterator gc_transition_args_end() const {
|
2015-05-12 23:33:48 +02:00
|
|
|
auto I = gc_transition_args_begin() + getNumTotalGCTransitionArgs();
|
2019-02-11 08:42:30 +01:00
|
|
|
assert((getCall()->arg_end() - I) >= 0);
|
2015-05-12 23:33:48 +02:00
|
|
|
return I;
|
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/D9501
llvm-svn: 236888
2015-05-08 20:07:42 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/// range adapter for GC transition arguments
|
2015-07-02 04:53:41 +02:00
|
|
|
iterator_range<arg_iterator> gc_transition_args() const {
|
2015-12-06 06:08:07 +01:00
|
|
|
return make_range(gc_transition_args_begin(), gc_transition_args_end());
|
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/D9501
llvm-svn: 236888
2015-05-08 20:07:42 +02:00
|
|
|
}
|
|
|
|
|
2015-05-06 04:36:31 +02:00
|
|
|
/// Number of additional arguments excluding those intended
|
|
|
|
/// for garbage collection.
|
2015-07-02 04:53:41 +02:00
|
|
|
int getNumTotalVMSArgs() const {
|
2015-05-12 23:33:48 +02:00
|
|
|
const Value *NumVMSArgs = *gc_transition_args_end();
|
2015-05-06 04:36:31 +02:00
|
|
|
return cast<ConstantInt>(NumVMSArgs)->getZExtValue();
|
|
|
|
}
|
|
|
|
|
2019-02-11 08:42:30 +01:00
|
|
|
arg_iterator deopt_begin() const {
|
2015-05-12 23:33:48 +02:00
|
|
|
auto I = gc_transition_args_end() + 1;
|
2019-02-11 08:42:30 +01:00
|
|
|
assert((getCall()->arg_end() - I) >= 0);
|
2015-05-12 23:33:48 +02:00
|
|
|
return I;
|
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/D9501
llvm-svn: 236888
2015-05-08 20:07:42 +02:00
|
|
|
}
|
2019-02-11 08:42:30 +01:00
|
|
|
arg_iterator deopt_end() const {
|
2017-06-03 01:03:26 +02:00
|
|
|
auto I = deopt_begin() + getNumTotalVMSArgs();
|
2019-02-11 08:42:30 +01:00
|
|
|
assert((getCall()->arg_end() - I) >= 0);
|
2015-05-12 23:33:48 +02:00
|
|
|
return I;
|
[Statepoints 3/4] Statepoint infrastructure for garbage collection: SelectionDAGBuilder
This is the third patch in a small series. It contains the CodeGen support for lowering the gc.statepoint intrinsic sequences (223078) to the STATEPOINT pseudo machine instruction (223085). The change also includes the set of helper routines and classes for working with gc.statepoints, gc.relocates, and gc.results since the lowering code uses them.
With this change, gc.statepoints should be functionally complete. The documentation will follow in the fourth change, and there will likely be some cleanup changes, but interested parties can start experimenting now.
I'm not particularly happy with the amount of code or complexity involved with the lowering step, but at least it's fairly well isolated. The statepoint lowering code is split into it's own files and anyone not working on the statepoint support itself should be able to ignore it.
During the lowering process, we currently spill aggressively to stack. This is not entirely ideal (and we have plans to do better), but it's functional, relatively straight forward, and matches closely the implementations of the patchpoint intrinsics. Most of the complexity comes from trying to keep relocated copies of values in the same stack slots across statepoints. Doing so avoids the insertion of pointless load and store instructions to reshuffle the stack. The current implementation isn't as effective as I'd like, but it is functional and 'good enough' for many common use cases.
In the long term, I'd like to figure out how to integrate the statepoint lowering with the register allocator. In principal, we shouldn't need to eagerly spill at all. The register allocator should do any spilling required and the statepoint should simply record that fact. Depending on how challenging that turns out to be, we may invest in a smarter global stack slot assignment mechanism as a stop gap measure.
Reviewed by: atrick, ributzka
llvm-svn: 223137
2014-12-02 19:50:36 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
/// range adapter for vm state arguments
|
2017-06-03 01:03:26 +02:00
|
|
|
iterator_range<arg_iterator> deopt_operands() const {
|
|
|
|
return make_range(deopt_begin(), deopt_end());
|
[Statepoints 3/4] Statepoint infrastructure for garbage collection: SelectionDAGBuilder
This is the third patch in a small series. It contains the CodeGen support for lowering the gc.statepoint intrinsic sequences (223078) to the STATEPOINT pseudo machine instruction (223085). The change also includes the set of helper routines and classes for working with gc.statepoints, gc.relocates, and gc.results since the lowering code uses them.
With this change, gc.statepoints should be functionally complete. The documentation will follow in the fourth change, and there will likely be some cleanup changes, but interested parties can start experimenting now.
I'm not particularly happy with the amount of code or complexity involved with the lowering step, but at least it's fairly well isolated. The statepoint lowering code is split into it's own files and anyone not working on the statepoint support itself should be able to ignore it.
During the lowering process, we currently spill aggressively to stack. This is not entirely ideal (and we have plans to do better), but it's functional, relatively straight forward, and matches closely the implementations of the patchpoint intrinsics. Most of the complexity comes from trying to keep relocated copies of values in the same stack slots across statepoints. Doing so avoids the insertion of pointless load and store instructions to reshuffle the stack. The current implementation isn't as effective as I'd like, but it is functional and 'good enough' for many common use cases.
In the long term, I'd like to figure out how to integrate the statepoint lowering with the register allocator. In principal, we shouldn't need to eagerly spill at all. The register allocator should do any spilling required and the statepoint should simply record that fact. Depending on how challenging that turns out to be, we may invest in a smarter global stack slot assignment mechanism as a stop gap measure.
Reviewed by: atrick, ributzka
llvm-svn: 223137
2014-12-02 19:50:36 +01:00
|
|
|
}
|
|
|
|
|
2020-05-28 22:34:12 +02:00
|
|
|
arg_iterator gc_args_begin() const {
|
|
|
|
auto I = getCall()->gc_args_begin();
|
|
|
|
assert(I == deopt_end());
|
|
|
|
return I;
|
2015-10-09 01:18:38 +02:00
|
|
|
}
|
2020-05-28 22:34:12 +02:00
|
|
|
arg_iterator gc_args_end() const { return getCall()->gc_args_end(); }
|
|
|
|
unsigned gcArgsStartIdx() const { return getCall()->gcArgsStartIdx(); }
|
2015-07-02 04:53:41 +02:00
|
|
|
iterator_range<arg_iterator> gc_args() const {
|
2020-05-28 22:34:12 +02:00
|
|
|
return getCall()->gc_args();
|
[Statepoints 3/4] Statepoint infrastructure for garbage collection: SelectionDAGBuilder
This is the third patch in a small series. It contains the CodeGen support for lowering the gc.statepoint intrinsic sequences (223078) to the STATEPOINT pseudo machine instruction (223085). The change also includes the set of helper routines and classes for working with gc.statepoints, gc.relocates, and gc.results since the lowering code uses them.
With this change, gc.statepoints should be functionally complete. The documentation will follow in the fourth change, and there will likely be some cleanup changes, but interested parties can start experimenting now.
I'm not particularly happy with the amount of code or complexity involved with the lowering step, but at least it's fairly well isolated. The statepoint lowering code is split into it's own files and anyone not working on the statepoint support itself should be able to ignore it.
During the lowering process, we currently spill aggressively to stack. This is not entirely ideal (and we have plans to do better), but it's functional, relatively straight forward, and matches closely the implementations of the patchpoint intrinsics. Most of the complexity comes from trying to keep relocated copies of values in the same stack slots across statepoints. Doing so avoids the insertion of pointless load and store instructions to reshuffle the stack. The current implementation isn't as effective as I'd like, but it is functional and 'good enough' for many common use cases.
In the long term, I'd like to figure out how to integrate the statepoint lowering with the register allocator. In principal, we shouldn't need to eagerly spill at all. The register allocator should do any spilling required and the statepoint should simply record that fact. Depending on how challenging that turns out to be, we may invest in a smarter global stack slot assignment mechanism as a stop gap measure.
Reviewed by: atrick, ributzka
llvm-svn: 223137
2014-12-02 19:50:36 +01:00
|
|
|
}
|
|
|
|
|
2015-02-19 12:02:11 +01:00
|
|
|
/// Get list of all gc reloactes linked to this statepoint
|
|
|
|
/// May contain several relocations for the same base/derived pair.
|
|
|
|
/// For example this could happen due to relocations on unwinding
|
|
|
|
/// path of invoke.
|
2016-01-05 05:03:00 +01:00
|
|
|
std::vector<const GCRelocateInst *> getRelocates() const;
|
[Statepoints 3/4] Statepoint infrastructure for garbage collection: SelectionDAGBuilder
This is the third patch in a small series. It contains the CodeGen support for lowering the gc.statepoint intrinsic sequences (223078) to the STATEPOINT pseudo machine instruction (223085). The change also includes the set of helper routines and classes for working with gc.statepoints, gc.relocates, and gc.results since the lowering code uses them.
With this change, gc.statepoints should be functionally complete. The documentation will follow in the fourth change, and there will likely be some cleanup changes, but interested parties can start experimenting now.
I'm not particularly happy with the amount of code or complexity involved with the lowering step, but at least it's fairly well isolated. The statepoint lowering code is split into it's own files and anyone not working on the statepoint support itself should be able to ignore it.
During the lowering process, we currently spill aggressively to stack. This is not entirely ideal (and we have plans to do better), but it's functional, relatively straight forward, and matches closely the implementations of the patchpoint intrinsics. Most of the complexity comes from trying to keep relocated copies of values in the same stack slots across statepoints. Doing so avoids the insertion of pointless load and store instructions to reshuffle the stack. The current implementation isn't as effective as I'd like, but it is functional and 'good enough' for many common use cases.
In the long term, I'd like to figure out how to integrate the statepoint lowering with the register allocator. In principal, we shouldn't need to eagerly spill at all. The register allocator should do any spilling required and the statepoint should simply record that fact. Depending on how challenging that turns out to be, we may invest in a smarter global stack slot assignment mechanism as a stop gap measure.
Reviewed by: atrick, ributzka
llvm-svn: 223137
2014-12-02 19:50:36 +01:00
|
|
|
|
2015-07-02 04:53:34 +02:00
|
|
|
/// Get the experimental_gc_result call tied to this statepoint. Can be
|
|
|
|
/// nullptr if there isn't a gc_result tied to this statepoint. Guaranteed to
|
|
|
|
/// be a CallInst if non-null.
|
2016-04-12 20:05:10 +02:00
|
|
|
const GCResultInst *getGCResult() const {
|
2015-07-02 04:53:45 +02:00
|
|
|
for (auto *U : getInstruction()->users())
|
2016-04-12 20:05:10 +02:00
|
|
|
if (auto *GRI = dyn_cast<GCResultInst>(U))
|
|
|
|
return GRI;
|
2015-07-02 04:53:34 +02:00
|
|
|
return nullptr;
|
|
|
|
}
|
|
|
|
|
[Statepoints 3/4] Statepoint infrastructure for garbage collection: SelectionDAGBuilder
This is the third patch in a small series. It contains the CodeGen support for lowering the gc.statepoint intrinsic sequences (223078) to the STATEPOINT pseudo machine instruction (223085). The change also includes the set of helper routines and classes for working with gc.statepoints, gc.relocates, and gc.results since the lowering code uses them.
With this change, gc.statepoints should be functionally complete. The documentation will follow in the fourth change, and there will likely be some cleanup changes, but interested parties can start experimenting now.
I'm not particularly happy with the amount of code or complexity involved with the lowering step, but at least it's fairly well isolated. The statepoint lowering code is split into it's own files and anyone not working on the statepoint support itself should be able to ignore it.
During the lowering process, we currently spill aggressively to stack. This is not entirely ideal (and we have plans to do better), but it's functional, relatively straight forward, and matches closely the implementations of the patchpoint intrinsics. Most of the complexity comes from trying to keep relocated copies of values in the same stack slots across statepoints. Doing so avoids the insertion of pointless load and store instructions to reshuffle the stack. The current implementation isn't as effective as I'd like, but it is functional and 'good enough' for many common use cases.
In the long term, I'd like to figure out how to integrate the statepoint lowering with the register allocator. In principal, we shouldn't need to eagerly spill at all. The register allocator should do any spilling required and the statepoint should simply record that fact. Depending on how challenging that turns out to be, we may invest in a smarter global stack slot assignment mechanism as a stop gap measure.
Reviewed by: atrick, ributzka
llvm-svn: 223137
2014-12-02 19:50:36 +01:00
|
|
|
#ifndef NDEBUG
|
2014-12-02 22:01:48 +01:00
|
|
|
/// Asserts if this statepoint is malformed. Common cases for failure
|
|
|
|
/// include incorrect length prefixes for variable length sections or
|
|
|
|
/// illegal values for parameters.
|
[Statepoints 3/4] Statepoint infrastructure for garbage collection: SelectionDAGBuilder
This is the third patch in a small series. It contains the CodeGen support for lowering the gc.statepoint intrinsic sequences (223078) to the STATEPOINT pseudo machine instruction (223085). The change also includes the set of helper routines and classes for working with gc.statepoints, gc.relocates, and gc.results since the lowering code uses them.
With this change, gc.statepoints should be functionally complete. The documentation will follow in the fourth change, and there will likely be some cleanup changes, but interested parties can start experimenting now.
I'm not particularly happy with the amount of code or complexity involved with the lowering step, but at least it's fairly well isolated. The statepoint lowering code is split into it's own files and anyone not working on the statepoint support itself should be able to ignore it.
During the lowering process, we currently spill aggressively to stack. This is not entirely ideal (and we have plans to do better), but it's functional, relatively straight forward, and matches closely the implementations of the patchpoint intrinsics. Most of the complexity comes from trying to keep relocated copies of values in the same stack slots across statepoints. Doing so avoids the insertion of pointless load and store instructions to reshuffle the stack. The current implementation isn't as effective as I'd like, but it is functional and 'good enough' for many common use cases.
In the long term, I'd like to figure out how to integrate the statepoint lowering with the register allocator. In principal, we shouldn't need to eagerly spill at all. The register allocator should do any spilling required and the statepoint should simply record that fact. Depending on how challenging that turns out to be, we may invest in a smarter global stack slot assignment mechanism as a stop gap measure.
Reviewed by: atrick, ributzka
llvm-svn: 223137
2014-12-02 19:50:36 +01:00
|
|
|
void verify() {
|
2015-05-06 04:36:26 +02:00
|
|
|
assert(getNumCallArgs() >= 0 &&
|
2014-12-02 22:01:48 +01:00
|
|
|
"number of arguments to actually callee can't be negative");
|
|
|
|
|
[Statepoints 3/4] Statepoint infrastructure for garbage collection: SelectionDAGBuilder
This is the third patch in a small series. It contains the CodeGen support for lowering the gc.statepoint intrinsic sequences (223078) to the STATEPOINT pseudo machine instruction (223085). The change also includes the set of helper routines and classes for working with gc.statepoints, gc.relocates, and gc.results since the lowering code uses them.
With this change, gc.statepoints should be functionally complete. The documentation will follow in the fourth change, and there will likely be some cleanup changes, but interested parties can start experimenting now.
I'm not particularly happy with the amount of code or complexity involved with the lowering step, but at least it's fairly well isolated. The statepoint lowering code is split into it's own files and anyone not working on the statepoint support itself should be able to ignore it.
During the lowering process, we currently spill aggressively to stack. This is not entirely ideal (and we have plans to do better), but it's functional, relatively straight forward, and matches closely the implementations of the patchpoint intrinsics. Most of the complexity comes from trying to keep relocated copies of values in the same stack slots across statepoints. Doing so avoids the insertion of pointless load and store instructions to reshuffle the stack. The current implementation isn't as effective as I'd like, but it is functional and 'good enough' for many common use cases.
In the long term, I'd like to figure out how to integrate the statepoint lowering with the register allocator. In principal, we shouldn't need to eagerly spill at all. The register allocator should do any spilling required and the statepoint should simply record that fact. Depending on how challenging that turns out to be, we may invest in a smarter global stack slot assignment mechanism as a stop gap measure.
Reviewed by: atrick, ributzka
llvm-svn: 223137
2014-12-02 19:50:36 +01:00
|
|
|
// The internal asserts in the iterator accessors do the rest.
|
2015-07-02 04:53:45 +02:00
|
|
|
(void)arg_begin();
|
|
|
|
(void)arg_end();
|
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/D9501
llvm-svn: 236888
2015-05-08 20:07:42 +02:00
|
|
|
(void)gc_transition_args_begin();
|
|
|
|
(void)gc_transition_args_end();
|
2017-06-03 01:03:26 +02:00
|
|
|
(void)deopt_begin();
|
|
|
|
(void)deopt_end();
|
[Statepoints 3/4] Statepoint infrastructure for garbage collection: SelectionDAGBuilder
This is the third patch in a small series. It contains the CodeGen support for lowering the gc.statepoint intrinsic sequences (223078) to the STATEPOINT pseudo machine instruction (223085). The change also includes the set of helper routines and classes for working with gc.statepoints, gc.relocates, and gc.results since the lowering code uses them.
With this change, gc.statepoints should be functionally complete. The documentation will follow in the fourth change, and there will likely be some cleanup changes, but interested parties can start experimenting now.
I'm not particularly happy with the amount of code or complexity involved with the lowering step, but at least it's fairly well isolated. The statepoint lowering code is split into it's own files and anyone not working on the statepoint support itself should be able to ignore it.
During the lowering process, we currently spill aggressively to stack. This is not entirely ideal (and we have plans to do better), but it's functional, relatively straight forward, and matches closely the implementations of the patchpoint intrinsics. Most of the complexity comes from trying to keep relocated copies of values in the same stack slots across statepoints. Doing so avoids the insertion of pointless load and store instructions to reshuffle the stack. The current implementation isn't as effective as I'd like, but it is functional and 'good enough' for many common use cases.
In the long term, I'd like to figure out how to integrate the statepoint lowering with the register allocator. In principal, we shouldn't need to eagerly spill at all. The register allocator should do any spilling required and the statepoint should simply record that fact. Depending on how challenging that turns out to be, we may invest in a smarter global stack slot assignment mechanism as a stop gap measure.
Reviewed by: atrick, ributzka
llvm-svn: 223137
2014-12-02 19:50:36 +01:00
|
|
|
(void)gc_args_begin();
|
|
|
|
(void)gc_args_end();
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
};
|
|
|
|
|
|
|
|
/// A specialization of it's base class for read only access
|
|
|
|
/// to a gc.statepoint.
|
|
|
|
class ImmutableStatepoint
|
2015-07-02 04:53:45 +02:00
|
|
|
: public StatepointBase<const Function, const Instruction, const Value,
|
2020-05-28 02:16:41 +02:00
|
|
|
const GCStatepointInst> {
|
2019-02-11 08:42:30 +01:00
|
|
|
using Base = StatepointBase<const Function, const Instruction, const Value,
|
2020-05-28 02:16:41 +02:00
|
|
|
const GCStatepointInst>;
|
[Statepoints 3/4] Statepoint infrastructure for garbage collection: SelectionDAGBuilder
This is the third patch in a small series. It contains the CodeGen support for lowering the gc.statepoint intrinsic sequences (223078) to the STATEPOINT pseudo machine instruction (223085). The change also includes the set of helper routines and classes for working with gc.statepoints, gc.relocates, and gc.results since the lowering code uses them.
With this change, gc.statepoints should be functionally complete. The documentation will follow in the fourth change, and there will likely be some cleanup changes, but interested parties can start experimenting now.
I'm not particularly happy with the amount of code or complexity involved with the lowering step, but at least it's fairly well isolated. The statepoint lowering code is split into it's own files and anyone not working on the statepoint support itself should be able to ignore it.
During the lowering process, we currently spill aggressively to stack. This is not entirely ideal (and we have plans to do better), but it's functional, relatively straight forward, and matches closely the implementations of the patchpoint intrinsics. Most of the complexity comes from trying to keep relocated copies of values in the same stack slots across statepoints. Doing so avoids the insertion of pointless load and store instructions to reshuffle the stack. The current implementation isn't as effective as I'd like, but it is functional and 'good enough' for many common use cases.
In the long term, I'd like to figure out how to integrate the statepoint lowering with the register allocator. In principal, we shouldn't need to eagerly spill at all. The register allocator should do any spilling required and the statepoint should simply record that fact. Depending on how challenging that turns out to be, we may invest in a smarter global stack slot assignment mechanism as a stop gap measure.
Reviewed by: atrick, ributzka
llvm-svn: 223137
2014-12-02 19:50:36 +01:00
|
|
|
|
|
|
|
public:
|
|
|
|
explicit ImmutableStatepoint(const Instruction *I) : Base(I) {}
|
2019-02-11 08:42:30 +01:00
|
|
|
explicit ImmutableStatepoint(const CallBase *Call) : Base(Call) {}
|
[Statepoints 3/4] Statepoint infrastructure for garbage collection: SelectionDAGBuilder
This is the third patch in a small series. It contains the CodeGen support for lowering the gc.statepoint intrinsic sequences (223078) to the STATEPOINT pseudo machine instruction (223085). The change also includes the set of helper routines and classes for working with gc.statepoints, gc.relocates, and gc.results since the lowering code uses them.
With this change, gc.statepoints should be functionally complete. The documentation will follow in the fourth change, and there will likely be some cleanup changes, but interested parties can start experimenting now.
I'm not particularly happy with the amount of code or complexity involved with the lowering step, but at least it's fairly well isolated. The statepoint lowering code is split into it's own files and anyone not working on the statepoint support itself should be able to ignore it.
During the lowering process, we currently spill aggressively to stack. This is not entirely ideal (and we have plans to do better), but it's functional, relatively straight forward, and matches closely the implementations of the patchpoint intrinsics. Most of the complexity comes from trying to keep relocated copies of values in the same stack slots across statepoints. Doing so avoids the insertion of pointless load and store instructions to reshuffle the stack. The current implementation isn't as effective as I'd like, but it is functional and 'good enough' for many common use cases.
In the long term, I'd like to figure out how to integrate the statepoint lowering with the register allocator. In principal, we shouldn't need to eagerly spill at all. The register allocator should do any spilling required and the statepoint should simply record that fact. Depending on how challenging that turns out to be, we may invest in a smarter global stack slot assignment mechanism as a stop gap measure.
Reviewed by: atrick, ributzka
llvm-svn: 223137
2014-12-02 19:50:36 +01:00
|
|
|
};
|
|
|
|
|
|
|
|
/// A specialization of it's base class for read-write access
|
|
|
|
/// to a gc.statepoint.
|
2015-07-02 04:53:45 +02:00
|
|
|
class Statepoint
|
2020-05-28 02:16:41 +02:00
|
|
|
: public StatepointBase<Function, Instruction, Value, GCStatepointInst> {
|
|
|
|
using Base = StatepointBase<Function, Instruction, Value, GCStatepointInst>;
|
[Statepoints 3/4] Statepoint infrastructure for garbage collection: SelectionDAGBuilder
This is the third patch in a small series. It contains the CodeGen support for lowering the gc.statepoint intrinsic sequences (223078) to the STATEPOINT pseudo machine instruction (223085). The change also includes the set of helper routines and classes for working with gc.statepoints, gc.relocates, and gc.results since the lowering code uses them.
With this change, gc.statepoints should be functionally complete. The documentation will follow in the fourth change, and there will likely be some cleanup changes, but interested parties can start experimenting now.
I'm not particularly happy with the amount of code or complexity involved with the lowering step, but at least it's fairly well isolated. The statepoint lowering code is split into it's own files and anyone not working on the statepoint support itself should be able to ignore it.
During the lowering process, we currently spill aggressively to stack. This is not entirely ideal (and we have plans to do better), but it's functional, relatively straight forward, and matches closely the implementations of the patchpoint intrinsics. Most of the complexity comes from trying to keep relocated copies of values in the same stack slots across statepoints. Doing so avoids the insertion of pointless load and store instructions to reshuffle the stack. The current implementation isn't as effective as I'd like, but it is functional and 'good enough' for many common use cases.
In the long term, I'd like to figure out how to integrate the statepoint lowering with the register allocator. In principal, we shouldn't need to eagerly spill at all. The register allocator should do any spilling required and the statepoint should simply record that fact. Depending on how challenging that turns out to be, we may invest in a smarter global stack slot assignment mechanism as a stop gap measure.
Reviewed by: atrick, ributzka
llvm-svn: 223137
2014-12-02 19:50:36 +01:00
|
|
|
|
|
|
|
public:
|
|
|
|
explicit Statepoint(Instruction *I) : Base(I) {}
|
2019-02-11 08:42:30 +01:00
|
|
|
explicit Statepoint(CallBase *Call) : Base(Call) {}
|
[Statepoints 3/4] Statepoint infrastructure for garbage collection: SelectionDAGBuilder
This is the third patch in a small series. It contains the CodeGen support for lowering the gc.statepoint intrinsic sequences (223078) to the STATEPOINT pseudo machine instruction (223085). The change also includes the set of helper routines and classes for working with gc.statepoints, gc.relocates, and gc.results since the lowering code uses them.
With this change, gc.statepoints should be functionally complete. The documentation will follow in the fourth change, and there will likely be some cleanup changes, but interested parties can start experimenting now.
I'm not particularly happy with the amount of code or complexity involved with the lowering step, but at least it's fairly well isolated. The statepoint lowering code is split into it's own files and anyone not working on the statepoint support itself should be able to ignore it.
During the lowering process, we currently spill aggressively to stack. This is not entirely ideal (and we have plans to do better), but it's functional, relatively straight forward, and matches closely the implementations of the patchpoint intrinsics. Most of the complexity comes from trying to keep relocated copies of values in the same stack slots across statepoints. Doing so avoids the insertion of pointless load and store instructions to reshuffle the stack. The current implementation isn't as effective as I'd like, but it is functional and 'good enough' for many common use cases.
In the long term, I'd like to figure out how to integrate the statepoint lowering with the register allocator. In principal, we shouldn't need to eagerly spill at all. The register allocator should do any spilling required and the statepoint should simply record that fact. Depending on how challenging that turns out to be, we may invest in a smarter global stack slot assignment mechanism as a stop gap measure.
Reviewed by: atrick, ributzka
llvm-svn: 223137
2014-12-02 19:50:36 +01:00
|
|
|
};
|
|
|
|
|
2018-07-30 21:41:25 +02:00
|
|
|
/// Common base class for representing values projected from a statepoint.
|
2016-04-12 20:05:10 +02:00
|
|
|
/// Currently, the only projections available are gc.result and gc.relocate.
|
|
|
|
class GCProjectionInst : public IntrinsicInst {
|
2015-05-06 04:36:28 +02:00
|
|
|
public:
|
2017-06-29 21:35:17 +02:00
|
|
|
static bool classof(const IntrinsicInst *I) {
|
2016-04-12 20:05:10 +02:00
|
|
|
return I->getIntrinsicID() == Intrinsic::experimental_gc_relocate ||
|
|
|
|
I->getIntrinsicID() == Intrinsic::experimental_gc_result;
|
2016-01-05 05:03:00 +01:00
|
|
|
}
|
2017-05-13 00:25:07 +02:00
|
|
|
|
2017-06-29 21:35:17 +02:00
|
|
|
static bool classof(const Value *V) {
|
2016-01-05 05:03:00 +01:00
|
|
|
return isa<IntrinsicInst>(V) && classof(cast<IntrinsicInst>(V));
|
[Statepoints 3/4] Statepoint infrastructure for garbage collection: SelectionDAGBuilder
This is the third patch in a small series. It contains the CodeGen support for lowering the gc.statepoint intrinsic sequences (223078) to the STATEPOINT pseudo machine instruction (223085). The change also includes the set of helper routines and classes for working with gc.statepoints, gc.relocates, and gc.results since the lowering code uses them.
With this change, gc.statepoints should be functionally complete. The documentation will follow in the fourth change, and there will likely be some cleanup changes, but interested parties can start experimenting now.
I'm not particularly happy with the amount of code or complexity involved with the lowering step, but at least it's fairly well isolated. The statepoint lowering code is split into it's own files and anyone not working on the statepoint support itself should be able to ignore it.
During the lowering process, we currently spill aggressively to stack. This is not entirely ideal (and we have plans to do better), but it's functional, relatively straight forward, and matches closely the implementations of the patchpoint intrinsics. Most of the complexity comes from trying to keep relocated copies of values in the same stack slots across statepoints. Doing so avoids the insertion of pointless load and store instructions to reshuffle the stack. The current implementation isn't as effective as I'd like, but it is functional and 'good enough' for many common use cases.
In the long term, I'd like to figure out how to integrate the statepoint lowering with the register allocator. In principal, we shouldn't need to eagerly spill at all. The register allocator should do any spilling required and the statepoint should simply record that fact. Depending on how challenging that turns out to be, we may invest in a smarter global stack slot assignment mechanism as a stop gap measure.
Reviewed by: atrick, ributzka
llvm-svn: 223137
2014-12-02 19:50:36 +01:00
|
|
|
}
|
|
|
|
|
2015-02-19 12:02:11 +01:00
|
|
|
/// Return true if this relocate is tied to the invoke statepoint.
|
|
|
|
/// This includes relocates which are on the unwinding path.
|
|
|
|
bool isTiedToInvoke() const {
|
2016-01-05 05:03:00 +01:00
|
|
|
const Value *Token = getArgOperand(0);
|
2015-02-19 12:02:11 +01:00
|
|
|
|
2015-12-26 08:54:32 +01:00
|
|
|
return isa<LandingPadInst>(Token) || isa<InvokeInst>(Token);
|
2015-02-19 12:02:11 +01:00
|
|
|
}
|
|
|
|
|
[Statepoints 3/4] Statepoint infrastructure for garbage collection: SelectionDAGBuilder
This is the third patch in a small series. It contains the CodeGen support for lowering the gc.statepoint intrinsic sequences (223078) to the STATEPOINT pseudo machine instruction (223085). The change also includes the set of helper routines and classes for working with gc.statepoints, gc.relocates, and gc.results since the lowering code uses them.
With this change, gc.statepoints should be functionally complete. The documentation will follow in the fourth change, and there will likely be some cleanup changes, but interested parties can start experimenting now.
I'm not particularly happy with the amount of code or complexity involved with the lowering step, but at least it's fairly well isolated. The statepoint lowering code is split into it's own files and anyone not working on the statepoint support itself should be able to ignore it.
During the lowering process, we currently spill aggressively to stack. This is not entirely ideal (and we have plans to do better), but it's functional, relatively straight forward, and matches closely the implementations of the patchpoint intrinsics. Most of the complexity comes from trying to keep relocated copies of values in the same stack slots across statepoints. Doing so avoids the insertion of pointless load and store instructions to reshuffle the stack. The current implementation isn't as effective as I'd like, but it is functional and 'good enough' for many common use cases.
In the long term, I'd like to figure out how to integrate the statepoint lowering with the register allocator. In principal, we shouldn't need to eagerly spill at all. The register allocator should do any spilling required and the statepoint should simply record that fact. Depending on how challenging that turns out to be, we may invest in a smarter global stack slot assignment mechanism as a stop gap measure.
Reviewed by: atrick, ributzka
llvm-svn: 223137
2014-12-02 19:50:36 +01:00
|
|
|
/// The statepoint with which this gc.relocate is associated.
|
2020-05-28 20:28:58 +02:00
|
|
|
const GCStatepointInst *getStatepoint() const {
|
2016-01-05 05:03:00 +01:00
|
|
|
const Value *Token = getArgOperand(0);
|
2015-02-19 12:02:11 +01:00
|
|
|
|
|
|
|
// This takes care both of relocates for call statepoints and relocates
|
|
|
|
// on normal path of invoke statepoint.
|
2020-05-28 20:28:58 +02:00
|
|
|
if (!isa<LandingPadInst>(Token))
|
|
|
|
return cast<GCStatepointInst>(Token);
|
2015-02-19 12:02:11 +01:00
|
|
|
|
|
|
|
// This relocate is on exceptional path of an invoke statepoint
|
2015-05-06 04:36:26 +02:00
|
|
|
const BasicBlock *InvokeBB =
|
|
|
|
cast<Instruction>(Token)->getParent()->getUniquePredecessor();
|
2015-02-19 12:02:11 +01:00
|
|
|
|
2015-05-06 04:36:26 +02:00
|
|
|
assert(InvokeBB && "safepoints should have unique landingpads");
|
|
|
|
assert(InvokeBB->getTerminator() &&
|
|
|
|
"safepoint block should be well formed");
|
2015-02-19 12:02:11 +01:00
|
|
|
|
2020-05-28 20:28:58 +02:00
|
|
|
return cast<GCStatepointInst>(InvokeBB->getTerminator());
|
[Statepoints 3/4] Statepoint infrastructure for garbage collection: SelectionDAGBuilder
This is the third patch in a small series. It contains the CodeGen support for lowering the gc.statepoint intrinsic sequences (223078) to the STATEPOINT pseudo machine instruction (223085). The change also includes the set of helper routines and classes for working with gc.statepoints, gc.relocates, and gc.results since the lowering code uses them.
With this change, gc.statepoints should be functionally complete. The documentation will follow in the fourth change, and there will likely be some cleanup changes, but interested parties can start experimenting now.
I'm not particularly happy with the amount of code or complexity involved with the lowering step, but at least it's fairly well isolated. The statepoint lowering code is split into it's own files and anyone not working on the statepoint support itself should be able to ignore it.
During the lowering process, we currently spill aggressively to stack. This is not entirely ideal (and we have plans to do better), but it's functional, relatively straight forward, and matches closely the implementations of the patchpoint intrinsics. Most of the complexity comes from trying to keep relocated copies of values in the same stack slots across statepoints. Doing so avoids the insertion of pointless load and store instructions to reshuffle the stack. The current implementation isn't as effective as I'd like, but it is functional and 'good enough' for many common use cases.
In the long term, I'd like to figure out how to integrate the statepoint lowering with the register allocator. In principal, we shouldn't need to eagerly spill at all. The register allocator should do any spilling required and the statepoint should simply record that fact. Depending on how challenging that turns out to be, we may invest in a smarter global stack slot assignment mechanism as a stop gap measure.
Reviewed by: atrick, ributzka
llvm-svn: 223137
2014-12-02 19:50:36 +01:00
|
|
|
}
|
2016-04-12 20:05:10 +02:00
|
|
|
};
|
|
|
|
|
2016-04-21 18:15:19 +02:00
|
|
|
/// Represents calls to the gc.relocate intrinsic.
|
2016-04-12 20:05:10 +02:00
|
|
|
class GCRelocateInst : public GCProjectionInst {
|
|
|
|
public:
|
2017-06-29 21:35:17 +02:00
|
|
|
static bool classof(const IntrinsicInst *I) {
|
2016-04-12 20:05:10 +02:00
|
|
|
return I->getIntrinsicID() == Intrinsic::experimental_gc_relocate;
|
|
|
|
}
|
2017-05-13 00:25:07 +02:00
|
|
|
|
2017-06-29 21:35:17 +02:00
|
|
|
static bool classof(const Value *V) {
|
2016-04-12 20:05:10 +02:00
|
|
|
return isa<IntrinsicInst>(V) && classof(cast<IntrinsicInst>(V));
|
|
|
|
}
|
2015-05-06 04:36:26 +02:00
|
|
|
|
[Statepoints 3/4] Statepoint infrastructure for garbage collection: SelectionDAGBuilder
This is the third patch in a small series. It contains the CodeGen support for lowering the gc.statepoint intrinsic sequences (223078) to the STATEPOINT pseudo machine instruction (223085). The change also includes the set of helper routines and classes for working with gc.statepoints, gc.relocates, and gc.results since the lowering code uses them.
With this change, gc.statepoints should be functionally complete. The documentation will follow in the fourth change, and there will likely be some cleanup changes, but interested parties can start experimenting now.
I'm not particularly happy with the amount of code or complexity involved with the lowering step, but at least it's fairly well isolated. The statepoint lowering code is split into it's own files and anyone not working on the statepoint support itself should be able to ignore it.
During the lowering process, we currently spill aggressively to stack. This is not entirely ideal (and we have plans to do better), but it's functional, relatively straight forward, and matches closely the implementations of the patchpoint intrinsics. Most of the complexity comes from trying to keep relocated copies of values in the same stack slots across statepoints. Doing so avoids the insertion of pointless load and store instructions to reshuffle the stack. The current implementation isn't as effective as I'd like, but it is functional and 'good enough' for many common use cases.
In the long term, I'd like to figure out how to integrate the statepoint lowering with the register allocator. In principal, we shouldn't need to eagerly spill at all. The register allocator should do any spilling required and the statepoint should simply record that fact. Depending on how challenging that turns out to be, we may invest in a smarter global stack slot assignment mechanism as a stop gap measure.
Reviewed by: atrick, ributzka
llvm-svn: 223137
2014-12-02 19:50:36 +01:00
|
|
|
/// The index into the associate statepoint's argument list
|
|
|
|
/// which contains the base pointer of the pointer whose
|
|
|
|
/// relocation this gc.relocate describes.
|
2016-01-05 05:03:00 +01:00
|
|
|
unsigned getBasePtrIndex() const {
|
|
|
|
return cast<ConstantInt>(getArgOperand(1))->getZExtValue();
|
[Statepoints 3/4] Statepoint infrastructure for garbage collection: SelectionDAGBuilder
This is the third patch in a small series. It contains the CodeGen support for lowering the gc.statepoint intrinsic sequences (223078) to the STATEPOINT pseudo machine instruction (223085). The change also includes the set of helper routines and classes for working with gc.statepoints, gc.relocates, and gc.results since the lowering code uses them.
With this change, gc.statepoints should be functionally complete. The documentation will follow in the fourth change, and there will likely be some cleanup changes, but interested parties can start experimenting now.
I'm not particularly happy with the amount of code or complexity involved with the lowering step, but at least it's fairly well isolated. The statepoint lowering code is split into it's own files and anyone not working on the statepoint support itself should be able to ignore it.
During the lowering process, we currently spill aggressively to stack. This is not entirely ideal (and we have plans to do better), but it's functional, relatively straight forward, and matches closely the implementations of the patchpoint intrinsics. Most of the complexity comes from trying to keep relocated copies of values in the same stack slots across statepoints. Doing so avoids the insertion of pointless load and store instructions to reshuffle the stack. The current implementation isn't as effective as I'd like, but it is functional and 'good enough' for many common use cases.
In the long term, I'd like to figure out how to integrate the statepoint lowering with the register allocator. In principal, we shouldn't need to eagerly spill at all. The register allocator should do any spilling required and the statepoint should simply record that fact. Depending on how challenging that turns out to be, we may invest in a smarter global stack slot assignment mechanism as a stop gap measure.
Reviewed by: atrick, ributzka
llvm-svn: 223137
2014-12-02 19:50:36 +01:00
|
|
|
}
|
2015-05-06 04:36:26 +02:00
|
|
|
|
[Statepoints 3/4] Statepoint infrastructure for garbage collection: SelectionDAGBuilder
This is the third patch in a small series. It contains the CodeGen support for lowering the gc.statepoint intrinsic sequences (223078) to the STATEPOINT pseudo machine instruction (223085). The change also includes the set of helper routines and classes for working with gc.statepoints, gc.relocates, and gc.results since the lowering code uses them.
With this change, gc.statepoints should be functionally complete. The documentation will follow in the fourth change, and there will likely be some cleanup changes, but interested parties can start experimenting now.
I'm not particularly happy with the amount of code or complexity involved with the lowering step, but at least it's fairly well isolated. The statepoint lowering code is split into it's own files and anyone not working on the statepoint support itself should be able to ignore it.
During the lowering process, we currently spill aggressively to stack. This is not entirely ideal (and we have plans to do better), but it's functional, relatively straight forward, and matches closely the implementations of the patchpoint intrinsics. Most of the complexity comes from trying to keep relocated copies of values in the same stack slots across statepoints. Doing so avoids the insertion of pointless load and store instructions to reshuffle the stack. The current implementation isn't as effective as I'd like, but it is functional and 'good enough' for many common use cases.
In the long term, I'd like to figure out how to integrate the statepoint lowering with the register allocator. In principal, we shouldn't need to eagerly spill at all. The register allocator should do any spilling required and the statepoint should simply record that fact. Depending on how challenging that turns out to be, we may invest in a smarter global stack slot assignment mechanism as a stop gap measure.
Reviewed by: atrick, ributzka
llvm-svn: 223137
2014-12-02 19:50:36 +01:00
|
|
|
/// The index into the associate statepoint's argument list which
|
|
|
|
/// contains the pointer whose relocation this gc.relocate describes.
|
2016-01-05 05:03:00 +01:00
|
|
|
unsigned getDerivedPtrIndex() const {
|
|
|
|
return cast<ConstantInt>(getArgOperand(2))->getZExtValue();
|
[Statepoints 3/4] Statepoint infrastructure for garbage collection: SelectionDAGBuilder
This is the third patch in a small series. It contains the CodeGen support for lowering the gc.statepoint intrinsic sequences (223078) to the STATEPOINT pseudo machine instruction (223085). The change also includes the set of helper routines and classes for working with gc.statepoints, gc.relocates, and gc.results since the lowering code uses them.
With this change, gc.statepoints should be functionally complete. The documentation will follow in the fourth change, and there will likely be some cleanup changes, but interested parties can start experimenting now.
I'm not particularly happy with the amount of code or complexity involved with the lowering step, but at least it's fairly well isolated. The statepoint lowering code is split into it's own files and anyone not working on the statepoint support itself should be able to ignore it.
During the lowering process, we currently spill aggressively to stack. This is not entirely ideal (and we have plans to do better), but it's functional, relatively straight forward, and matches closely the implementations of the patchpoint intrinsics. Most of the complexity comes from trying to keep relocated copies of values in the same stack slots across statepoints. Doing so avoids the insertion of pointless load and store instructions to reshuffle the stack. The current implementation isn't as effective as I'd like, but it is functional and 'good enough' for many common use cases.
In the long term, I'd like to figure out how to integrate the statepoint lowering with the register allocator. In principal, we shouldn't need to eagerly spill at all. The register allocator should do any spilling required and the statepoint should simply record that fact. Depending on how challenging that turns out to be, we may invest in a smarter global stack slot assignment mechanism as a stop gap measure.
Reviewed by: atrick, ributzka
llvm-svn: 223137
2014-12-02 19:50:36 +01:00
|
|
|
}
|
2015-05-06 04:36:26 +02:00
|
|
|
|
2016-01-05 05:03:00 +01:00
|
|
|
Value *getBasePtr() const {
|
2019-02-11 08:42:30 +01:00
|
|
|
return *(getStatepoint()->arg_begin() + getBasePtrIndex());
|
[Statepoints 3/4] Statepoint infrastructure for garbage collection: SelectionDAGBuilder
This is the third patch in a small series. It contains the CodeGen support for lowering the gc.statepoint intrinsic sequences (223078) to the STATEPOINT pseudo machine instruction (223085). The change also includes the set of helper routines and classes for working with gc.statepoints, gc.relocates, and gc.results since the lowering code uses them.
With this change, gc.statepoints should be functionally complete. The documentation will follow in the fourth change, and there will likely be some cleanup changes, but interested parties can start experimenting now.
I'm not particularly happy with the amount of code or complexity involved with the lowering step, but at least it's fairly well isolated. The statepoint lowering code is split into it's own files and anyone not working on the statepoint support itself should be able to ignore it.
During the lowering process, we currently spill aggressively to stack. This is not entirely ideal (and we have plans to do better), but it's functional, relatively straight forward, and matches closely the implementations of the patchpoint intrinsics. Most of the complexity comes from trying to keep relocated copies of values in the same stack slots across statepoints. Doing so avoids the insertion of pointless load and store instructions to reshuffle the stack. The current implementation isn't as effective as I'd like, but it is functional and 'good enough' for many common use cases.
In the long term, I'd like to figure out how to integrate the statepoint lowering with the register allocator. In principal, we shouldn't need to eagerly spill at all. The register allocator should do any spilling required and the statepoint should simply record that fact. Depending on how challenging that turns out to be, we may invest in a smarter global stack slot assignment mechanism as a stop gap measure.
Reviewed by: atrick, ributzka
llvm-svn: 223137
2014-12-02 19:50:36 +01:00
|
|
|
}
|
2015-05-06 04:36:26 +02:00
|
|
|
|
2016-01-05 05:03:00 +01:00
|
|
|
Value *getDerivedPtr() const {
|
2019-02-11 08:42:30 +01:00
|
|
|
return *(getStatepoint()->arg_begin() + getDerivedPtrIndex());
|
[Statepoints 3/4] Statepoint infrastructure for garbage collection: SelectionDAGBuilder
This is the third patch in a small series. It contains the CodeGen support for lowering the gc.statepoint intrinsic sequences (223078) to the STATEPOINT pseudo machine instruction (223085). The change also includes the set of helper routines and classes for working with gc.statepoints, gc.relocates, and gc.results since the lowering code uses them.
With this change, gc.statepoints should be functionally complete. The documentation will follow in the fourth change, and there will likely be some cleanup changes, but interested parties can start experimenting now.
I'm not particularly happy with the amount of code or complexity involved with the lowering step, but at least it's fairly well isolated. The statepoint lowering code is split into it's own files and anyone not working on the statepoint support itself should be able to ignore it.
During the lowering process, we currently spill aggressively to stack. This is not entirely ideal (and we have plans to do better), but it's functional, relatively straight forward, and matches closely the implementations of the patchpoint intrinsics. Most of the complexity comes from trying to keep relocated copies of values in the same stack slots across statepoints. Doing so avoids the insertion of pointless load and store instructions to reshuffle the stack. The current implementation isn't as effective as I'd like, but it is functional and 'good enough' for many common use cases.
In the long term, I'd like to figure out how to integrate the statepoint lowering with the register allocator. In principal, we shouldn't need to eagerly spill at all. The register allocator should do any spilling required and the statepoint should simply record that fact. Depending on how challenging that turns out to be, we may invest in a smarter global stack slot assignment mechanism as a stop gap measure.
Reviewed by: atrick, ributzka
llvm-svn: 223137
2014-12-02 19:50:36 +01:00
|
|
|
}
|
|
|
|
};
|
2015-02-19 12:02:11 +01:00
|
|
|
|
2016-04-21 18:15:19 +02:00
|
|
|
/// Represents calls to the gc.result intrinsic.
|
2016-04-12 20:05:10 +02:00
|
|
|
class GCResultInst : public GCProjectionInst {
|
|
|
|
public:
|
2017-06-29 21:35:17 +02:00
|
|
|
static bool classof(const IntrinsicInst *I) {
|
2016-04-12 20:05:10 +02:00
|
|
|
return I->getIntrinsicID() == Intrinsic::experimental_gc_result;
|
|
|
|
}
|
2017-05-13 00:25:07 +02:00
|
|
|
|
2017-06-29 21:35:17 +02:00
|
|
|
static bool classof(const Value *V) {
|
2016-04-12 20:05:10 +02:00
|
|
|
return isa<IntrinsicInst>(V) && classof(cast<IntrinsicInst>(V));
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
2015-07-02 04:53:45 +02:00
|
|
|
template <typename FunTy, typename InstructionTy, typename ValueTy,
|
2020-05-28 02:16:41 +02:00
|
|
|
typename CallTy>
|
2016-01-05 05:03:00 +01:00
|
|
|
std::vector<const GCRelocateInst *>
|
2020-05-28 02:16:41 +02:00
|
|
|
StatepointBase<FunTy, InstructionTy, ValueTy, CallTy>::getRelocates()
|
2015-07-02 04:53:45 +02:00
|
|
|
const {
|
2016-01-05 05:03:00 +01:00
|
|
|
std::vector<const GCRelocateInst *> Result;
|
2015-02-19 12:02:11 +01:00
|
|
|
|
|
|
|
// Search for relocated pointers. Note that working backwards from the
|
|
|
|
// gc_relocates ensures that we only get pairs which are actually relocated
|
|
|
|
// and used after the statepoint.
|
2019-02-11 08:42:30 +01:00
|
|
|
for (const User *U : StatepointCall->users())
|
2016-01-05 05:03:00 +01:00
|
|
|
if (auto *Relocate = dyn_cast<GCRelocateInst>(U))
|
|
|
|
Result.push_back(Relocate);
|
2015-02-19 12:02:11 +01:00
|
|
|
|
2019-02-11 08:42:30 +01:00
|
|
|
auto *StatepointInvoke = dyn_cast<InvokeInst>(StatepointCall);
|
|
|
|
if (!StatepointInvoke)
|
2015-05-06 04:36:26 +02:00
|
|
|
return Result;
|
2015-02-19 12:02:11 +01:00
|
|
|
|
|
|
|
// We need to scan thorough exceptional relocations if it is invoke statepoint
|
2019-02-11 08:42:30 +01:00
|
|
|
LandingPadInst *LandingPad = StatepointInvoke->getLandingPadInst();
|
2015-02-19 12:02:11 +01:00
|
|
|
|
2015-12-26 08:54:32 +01:00
|
|
|
// Search for gc relocates that are attached to this landingpad.
|
2015-02-19 12:02:11 +01:00
|
|
|
for (const User *LandingPadUser : LandingPad->users()) {
|
2016-01-05 05:03:00 +01:00
|
|
|
if (auto *Relocate = dyn_cast<GCRelocateInst>(LandingPadUser))
|
|
|
|
Result.push_back(Relocate);
|
2015-02-19 12:02:11 +01:00
|
|
|
}
|
2015-05-06 04:36:26 +02:00
|
|
|
return Result;
|
2015-02-19 12:02:11 +01:00
|
|
|
}
|
2016-03-17 02:56:10 +01:00
|
|
|
|
|
|
|
/// Call sites that get wrapped by a gc.statepoint (currently only in
|
|
|
|
/// RewriteStatepointsForGC and potentially in other passes in the future) can
|
|
|
|
/// have attributes that describe properties of gc.statepoint call they will be
|
|
|
|
/// eventually be wrapped in. This struct is used represent such directives.
|
|
|
|
struct StatepointDirectives {
|
|
|
|
Optional<uint32_t> NumPatchBytes;
|
|
|
|
Optional<uint64_t> StatepointID;
|
2016-03-17 19:42:17 +01:00
|
|
|
|
|
|
|
static const uint64_t DefaultStatepointID = 0xABCDEF00;
|
2016-03-22 01:59:13 +01:00
|
|
|
static const uint64_t DeoptBundleStatepointID = 0xABCDEF0F;
|
2016-03-17 02:56:10 +01:00
|
|
|
};
|
|
|
|
|
|
|
|
/// Parse out statepoint directives from the function attributes present in \p
|
|
|
|
/// AS.
|
Rename AttributeSet to AttributeList
Summary:
This class is a list of AttributeSetNodes corresponding the function
prototype of a call or function declaration. This class used to be
called ParamAttrListPtr, then AttrListPtr, then AttributeSet. It is
typically accessed by parameter and return value index, so
"AttributeList" seems like a more intuitive name.
Rename AttributeSetImpl to AttributeListImpl to follow suit.
It's useful to rename this class so that we can rename AttributeSetNode
to AttributeSet later. AttributeSet is the set of attributes that apply
to a single function, argument, or return value.
Reviewers: sanjoy, javed.absar, chandlerc, pete
Reviewed By: pete
Subscribers: pete, jholewinski, arsenm, dschuff, mehdi_amini, jfb, nhaehnle, sbc100, void, llvm-commits
Differential Revision: https://reviews.llvm.org/D31102
llvm-svn: 298393
2017-03-21 17:57:19 +01:00
|
|
|
StatepointDirectives parseStatepointDirectivesFromAttrs(AttributeList AS);
|
2016-03-17 02:56:10 +01:00
|
|
|
|
2018-01-23 06:49:30 +01:00
|
|
|
/// Return \c true if the \p Attr is an attribute that is a statepoint
|
2016-03-17 02:56:10 +01:00
|
|
|
/// directive.
|
|
|
|
bool isStatepointDirectiveAttr(Attribute Attr);
|
2015-05-06 04:36:26 +02:00
|
|
|
|
2016-12-06 23:00:57 +01:00
|
|
|
} // end namespace llvm
|
|
|
|
|
|
|
|
#endif // LLVM_IR_STATEPOINT_H
|