similar to: Stack maps on AArch64

[+ Lang] > On Jun 13, 2016, at 9:58 AM, Philip Reames via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Andy, Juergen, > > I don't know enough about AArch64 to assess here. Is the proposed change below something we should take in tree? I'm happy to do the mechanics of posting a patch (if Rob doesn't), but I don't know enough to assess. Would such a

I figured out the issue -- the AArch64 backend only emits the stack map section if isOSBinFormateMachO() returns true -- see [1], lines 123 - 134. Moving the call to serializeToStackMapSection() outside of the conditional fixes the problem. [1] http://llvm.org/doxygen/AArch64AsmPrinter_8cpp_source.html On Thu, May 26, 2016 at 2:46 PM, Rob Lyerly <rlyerly at vt.edu> wrote: > Hi

Mostly likely, nobody got around to writing ELF tests. The change to enable stack maps on ELF would be fine if it includes a test case. -Andy > On Jun 13, 2016, at 5:38 PM, Lang Hames via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi All, > > I don't recall anything MachO specific in the AArch64 stack maps code. Digging through the svn history it looks like the

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,

Hello, I'm currently looking into integrating the patchpoint and stackmap intrinsics into my pet project. In their current implementation (3.4 and trunk) the code to emit the additional section is only executed on Darwin. This is however quickly fixed: Add a ".llvm_stackmaps"-Section for ELF in MCObjectFileInfo and execute StackMaps::serializeToStackMapSection in X86AsmPrinter in

Hi Sanjoy, I'm having trouble finding caller-saved registers using the RegMask operand you've mentioned. As an example, I've got a C function that looks like this: double recurse(int depth, double val) { if(depth < max_depth) return recurse(depth + 1, val * 1.2) + val; else return outer_func(val); } As a quick refresher, all "xmm" registers are considered

Hi Rob, Robert Lyerly wrote: > At a high level, I'm interested in finding the locations of all values > that are live at a given call site.**You can think of it like a > debugger, e.g. gdb -- I'd like to be able to unwind the stack, frame by > frame, and locate all the live values for each function invocation > (i.e., where they are in a function's stack

Hi Sanjoy, On Mon, Jun 27, 2016 at 4:05 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > Hi Rob, > > Robert Lyerly wrote: > > At a high level, I'm interested in finding the locations of all values > > that are live at a given call site.**You can think of it like a > > debugger, e.g. gdb -- I'd like to be able to unwind the stack, frame by >

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

Hi everyone, I'm writing a pass that inserts the llvm.experimental.stackmap intrinsic into the IR, and I'd like to record the locations of *all* live values whenever I insert the intrinsic (all this entails is adding values as arguments to the intrinsic). Is there any pre-existing analysis pass which can give me the live values at a given instruction in a basic block? Or do I need to

Ah, I see -- the registers left out of the mask are considered clobbered. Got it! At a high level, I'm interested in finding the locations of all values that are live at a given call site. You can think of it like a debugger, e.g. gdb -- I'd like to be able to unwind the stack, frame by frame, and locate all the live values for each function invocation (i.e., where they are in a

Hi Rob, On Thu, Mar 24, 2016 at 12:35 PM, Rob Lyerly via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Hi everyone, > I'm writing a pass that inserts the llvm.experimental.stackmap > intrinsic into the IR, and I'd like to record the locations of *all* > live values whenever I insert the intrinsic (all this entails is What is your definition of a live value? Some more

There seems to be semantic overlap with stackmap, patchpoint, and statepoint as well. I suspect we should remove pcmarker and forward serialize it in bitcode as a nop. Philip On 12/16/2015 02:14 PM, Justin Bogner via llvm-dev wrote: > Rob Lyerly via llvm-dev <llvm-dev at lists.llvm.org> writes: >> I've seen previous messages about "llvm.pcmarker" not being

Hi all, I've seen previous messages about "llvm.pcmarker" not being supported on x86 (e.g. http://lists.llvm.org/pipermail/llvm-dev/2010-February/029239.html and http://lists.llvm.org/pipermail/llvm-dev/2012-June/051104.html). However, these messages are several years old -- is the intrinsic still not implemented? -- Rob Lyerly Graduate Research Assistant, Systems Software

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

Hi everyone, I'm looking for a way to get all the caller-saved registers (both the register and the stack slot at which it was saved) for a given function call site in the backend. What's the best way to grab this information? Is it possible to get this information if I have the MachineInstr of the function call? I'm currently targeting the AArch64 & X86 backends. Thanks! --

Hi Rob, Rob Lyerly via llvm-dev wrote: > I'm looking for a way to get all the caller-saved registers (both the > register and the stack slot at which it was saved) for a given function > call site in the backend. What's the best way to grab this > information? Is it possible to get this information if I have the > MachineInstr of the function call? I'm currently

Hi everyone, I'm trying to get debug information for a C/pthreads application, but it seems like clang/LLVM are producing limited & erroneous debugging information. I've attached a simple test example to reproduce the problem -- I'm using clang/LLVM 3.7.1 built from source on Ubuntu 14.04. I compile the attached file with: $ clang -O1 -g test.c -lpthread If I run: $ readelf

TLDR. For anyone who is using the RewriteStatepointsForGC utility pass, there is a recent change you should know about which may require you to make some small changes to your stackmap parsing. I have landed a small series of patches which change how we're handling vector of pointers when reporting live pointers for the GC at safepoints. Previously, the RS4GC pass was attempting to

Hi all, I've run into a couple bugs recently that affected stackmap liveness analysis in various ways: http://llvm.org/bugs/show_bug.cgi?id=19224 - function arguments stay live unnecessarily http://llvm.org/bugs/show_bug.cgi?id=21265 - eflags can end up as a live out http://llvm.org/bugs/show_bug.cgi?id=21266 - %rip can end up as a live out The first two have nothing to do with stackmaps