[llvm-dev] Finding live values

Rob Lyerly via llvm-dev llvm-dev at lists.llvm.org
Wed Mar 30 06:48:24 PDT 2016


Hi Sanjoy & Daniel,

Thanks for your insights!

I've actually got kind of an esoteric use case -- we're exploring how to
efficiently transform application state between ABIs at runtime, and thus
we need a lot of info from the compiler on how things are laid out.  I'm
going to follow Daniel's suggestion and try to implement an analysis pass
based on the approaches detailed in [1].  If you think this is useful for
LLVM in general, I'd be happy to contribute it to the community.  A word of
warning -- I'll probably need some hand-holding to get it to an
LLVM-acceptable level :).

On representing this information -- I was planning on generating meta-data
based on the analysis (similar to what happens with "-g"), but I can
definitely explore using operand bundles to hold the data.

[1] https://hal.inria.fr/inria-00558509v1/document

On Sun, Mar 27, 2016 at 1:18 AM, Sanjoy Das <sanjoy at playingwithpointers.com>
wrote:

> On Sat, Mar 26, 2016 at 12:52 PM, Rob Lyerly <rlyerly at vt.edu> wrote:
> >
> > Hi Sanjoy,
> >
> > I'm interested in being able to reconstruct stack frames at runtime.
> > In particular, I'd like to be able to unwind frames from a thread's
> > stack and inspect the live values of each individual activation.  I'd
> > like to be able to find all live values (whether they be
> > programmer-defined variables or compiler-generated intermediates) at
> > arbitrary, but statically-known, locations in the the code.  Right
> > now, I need the locations of all live values at function call sites.
>
> This sound very interesting!  What do you intend to use this mechanism
> for, if you don't mind sharing?
>
> The liveness analysis in the statepoint lowering code cannot be
> directly used for this, but it should be possible to extract out a
> "liveness analysis utility" that is usable both by the statepoint
> lowering code and by whatever it is that you're trying to do.  I'll be
> happy to review changes in this direction -- let me know if you're
> interested in taking this on, and we can work out the details.
>
> As an aside, have you thought about how you'd represent and lower this
> information ("this information" == the set of values live over a
> function call)?  LLVM has a notion called operand bundles which may be
> useful for you here -- we use it to represent deoptimization state for
> specific physical frames, that lets the runtime replace the stack
> frames running compiled code with stack frames running interpreted
> code (is this similar to what you're trying to do?).
>
> -- Sanjoy
>



-- 
Rob Lyerly
Graduate Research Assistant, Systems Software Research Group
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160330/ecd11e33/attachment-0001.html>


More information about the llvm-dev mailing list