similar to: Finding live values

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

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,

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 >

Hi, Sanjoy, On 2015-11-16 23:27, Sanjoy Das wrote: > Hi Vlad, > > vlad via llvm-dev wrote: >>> Vlad, >>> >>> My initial impression is that you've stumbled across a bug. I suspect >>> that we - the only active users of the deopt info in the statepoint I >>> know of - have been inverting the meaning of Direct and Indirect >>>

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 everyone, I'm using LLVM's stack map intrinsic to store value location information. I've got a pass that automatically inserts the "llvm.experimental.stackmap" intrinsic into the IR. On x86-64, an ".llvm_stackmaps" section is successfully emitted (I can see the section & its contents in the generated assembly). However I can't get the AArch64 backend

[+ 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

Currently, the alloca instruction always allocates in the generic address space (0). This proposal is to extend the semantics of alloca instruction to allow allocation in any specified address space. Proposed Syntax <result> = alloca [inalloca] <type> [, <ty> <NumElements>] [, align <alignment>] [, addrspace <num>] ; yields type addrspace(num)*:result

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

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

Philip: I think there are two separate issues: 1) Handling GC pointers stored in stack locations -- tracking their liveness, reporting them to the GC. etc. 2) Treating pointers to stack locations as GC-pointers. I think the two options that you presented here are for solving (1). I'm trying to solve issue (2) using alloca in addrspace(1). Basically, we want to create a pointer to a stack

> Vlad, > > My initial impression is that you've stumbled across a bug. I suspect > that we - the only active users of the deopt info in the statepoint I > know of - have been inverting the meaning of Direct and Indirect > throughout our code. (i.e. we're consistent, but swapped on the > documented meaning) I've asked Sanjoy to confirm that, and if he >

The long term plan is a) evolving, and b) dependent on the specific use case. :) It would definitely be nice if we could support both early and late safepoint insertion. I see no reason that LLVM as a project should pick one or the other since the infrastructure required is largely overlapping. (Obviously, I'm going to be mostly working on the parts that I need, but others are always

Currently llvm crashes on following code, run through llc: declare void @llvm.experimental.stackmap(i64, i32, ...) define void @foo() { tail call void (i64, i32, ...)* @llvm.experimental.stackmap(i64 0, i32 0, i64 9223372036854775807) ret void } The issue is that 9223372036854775807 (decimal for 0x7fffffffffffffff) is the "empty key" for an int64_t, and 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! --

Hello, list I am not quite sure if what I'm experiencing is a bug or intentional behavior. In the code below the result of a function call is a deopt arg to llvm.experimental.gc.statepoint (http://llvm.org/docs/Statepoints.html#llvm-experimental-gc-statepoint-intrinsic). Therefore a Stack Map containing location of this variable is created upon code generation. Here's the complete

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