[LLVMdev] ocaml+llvm
Gordon Henriksen
gordonhenriksen at mac.com
Tue Aug 14 04:35:25 PDT 2007
On Aug 14, 2007, at 06:24, Gordon Henriksen wrote:
> The two major problems I had really boil down to identifying GC
> points in machine code and statically identifying live roots at
> those GC points, both problems common to many collection
> techniques. Looking at the problem from that perspective makes the
> problem much more tractable, actually…
Chris,
This is much more generic than what I was originally thinking, but
what do you think of providing a facility like this?
enum GCPointKind {
GCPSubroutineReturn,
GCPFunctionExit,
GCPSubroutineCall,
GCPBackBranch
};
class ??? {
public:
// Allows the code generator to avoid inserting unnecessary GC
points.
bool RequiresGCPointsOfKind(GCPointKind Kind) const;
// If false, instructs the code generator to keep all GC roots
on the
// stack at GC points.
bool SupportsRegisterRoots() const; // false for now...
// Visits a GC point, including information necessary to
identify all
// live GC roots in the stack frame.
virtual bool VisitGCPoint(MachineInstruction *Point,
GCPointKind Kind,
intptr_t *StackRoots, size_t
StackCount,
int *RegisterRoots, size_t
RegisterCount);
};
That could enable several kinds of conservative collectors.
The code generator would need to cooperate by:
1. Inserting nodes for GC points if required, recording the
corresponding original Instruction*.
2. Recording the physical location of each llvm.gcroot'd alloca.
Later, a MachineFunctionPass could walk the MachineFunction to lower
these nodes. Live roots can be identified using domination information.
In addition to providing a stack and register map for building
tables, such an interface offers a collector a chance to insert any
necessary landing pads at exit/call/back-branch.
If the collector supports it, LLVM could be allowed to scalarize GC
roots down the road.
— Gordon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070814/62d71db8/attachment.html>
More information about the llvm-dev
mailing list