similar to: Status of "llvm.pcmarker" intrinsic?

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 list, For a tool I'm working on I'd like to know where instructions end up in compiled executables by looking them up in the symbol table. Therefore, I've been trying to use the llvm.pcmarker Intrinsic, but I've had no luck. When I pass .bc files with this intrinsic into llc, I'm given this error: LLVM ERROR: Cannot yet select: 0x2026938: ch PCMarker 0x1f0c678, 0x20268b0

Hi everyone, We seem to have allowed our documented target-independent intrinsics to acquire a somewhat-haphazard naming system, and I think we should standardize on one convention. All of the intrinsics have 'llvm.' as a prefix, and some also have some additional prefix 'llvm.dbg.', 'llvm.eh.', 'llvm.experimental.', etc., but after that we lose consistency. When

On Mon, Feb 8, 2010 at 1:13 PM, Nathan McCauley <nathan.mccauley at gmail.com> wrote: > Hi list, > > For a tool I'm working on I'd like to know where instructions end up in > compiled executables by looking them up in the symbol table.  Therefore, > I've been trying to use the  llvm.pcmarker Intrinsic, but I've had no luck. > When I pass .bc files with this

Hi, I'm also working on a tool in which I'd like to know the instruction PCs. So for now, the intrinsic is still not supported on x86? -Ang -- View this message in context: http://llvm.1065342.n5.nabble.com/State-of-llvm-pcmarker-Intrinsic-tp31677p46619.html Sent from the LLVM - Dev mailing list archive at Nabble.com.

On Sat, Jun 23, 2012 at 3:17 PM, ihcinihsdk <ali28 at wisc.edu> wrote: > Hi, > > I'm also working on a tool in which I'd like to know the instruction PCs. > So > for now, the intrinsic is still not supported on x86? > No, but it's very easy to implement. Andrew > -Ang > > -- > View this message in context: >

Hi Andrew, So do you know on which architectures is this intrinsic implemented? Thank you! -Ang -- View this message in context: http://llvm.1065342.n5.nabble.com/State-of-llvm-pcmarker-Intrinsic-tp31677p46621.html Sent from the LLVM - Dev mailing list archive at Nabble.com.

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,

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

I've been looking at inlining invokes / calls done through statepoints and I want to have a design discussion before I sink too much time into something I'll have to throw away. I'm not actively working on adding inlining support to patchpoints, but I suspect these issues are applicable towards teaching LLVM to inline through patchpoints as well. There are two distinct problems to

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

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

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

On Fri, 15 Apr 2005, Vladimir Prus wrote: >> Another thing that might be interesting is the new llvm.pcmarker intrinsic >> that Andrew recently added. I have no idea if it would be useful to you >> or not, but... it's documented here: >> http://llvm.cs.uiuc.edu/docs/LangRef.html#i_pcmarker > > In fact, I'm having problems exactly while lowering the pcmarker

On Friday 15 April 2005 18:49, Chris Lattner wrote: > On Fri, 15 Apr 2005, Vladimir Prus wrote: > > Hello, > > I just wrote the code like this: > > > > BuildMI(BB, NM::CALL, 1) > > .addExternalSymbol(("_lvksda_control_marker_" > > + > > lexical_cast<string>(bb)).c_str()); > >

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

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