[LLVMdev] Getting the DSNode from a Pool Descriptor?

Andrew Lenharth andrewl at lenharth.org
Fri Mar 19 05:55:09 PDT 2010


On Fri, Mar 19, 2010 at 5:10 AM, Harmen van der Spek <hvdspek at liacs.nl> wrote:
> All those mappings are quite confusing. I've been thinking about splitting Pool allocation in two phases,
> one in which the clones are generated (which should be internal functions) and then, instead of maintaining all these mappings, just
> rerun Top-Down DSA on that result. In that case, it would be much easier to find DSNodes. Anyway, this was just
> a thought, I've not really tried anything like that.

You would have to rerun the entire DSA stack, not just TD (and a
number of PA clients don't want TD).  Your problem is then the
PoolDescriptors will masquarade as normal pointers, so you already
have to maintain some mapping of Expected DSNode -> Expected PA and
hope it is stable (DSA didn't not use to be deterministic (I think
because the type merging code was not symetric)).

I would argue (and have partially implemented) that the main problem
is that PA clients must be DSA clients.  PA should import and make
available a sane set of information about each pool such that going to
the DSNodes would not be useful.  Then a PA client would never have to
manage that mapping.  Further, PA is really 2 transforms in one:  the
first associates PoolDescriptors with nodes creating a runtime
representation of the points-to graph; the second uses that mapping to
change heap structure (hijacking the PoolDescriptors to be allocation
pools (which is a fine thing to do with them)).  I've split the two up
(well I haven't implemented the second over the first yet) and
currently have a pass that just does the transform and should, when it
is done, free clients from having to know about DSA.

Andrew



More information about the llvm-dev mailing list