[llvm-dev] Status of "llvm.pcmarker" intrinsic?
Rob Lyerly via llvm-dev
llvm-dev at lists.llvm.org
Thu Dec 17 08:55:00 PST 2015
That's kind of a shame because it did exactly what I needed -- I'll have to
find another route!
I wanted to use "llvm.pcmarker" to find the address of a given IR
instruction when generated using different back-ends. In particular, I
wanted to be able to map the return address of a specific function call on
x86-64 with the return address for the *same* function call on Aarch64. My
plan was to develop a pass that dumped the pcmarker intrinsic after every
function call site, so that I could correlate the return addresses between
function call sites on both architectures.
I'm still a newbie in terms of LLVM internals, so I'm wondering what would
be the easiest approach to accomplish this. I've seen elsewhere people
recommending adding custom intrinsics that get converted into
pseudo-instructions in the back-end. Those pseudo instructions would then
generate a label when CodeGen'd...does this seem sane? Or is there an
easier approach to solving this?
On Wed, Dec 16, 2015 at 6:49 PM, Philip Reames <listmail at philipreames.com>
> 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.
> 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 supported on
>>> x86 (e.g.
>>> and http://lists.llvm.org/pipermail/llvm-dev/2012-June/051104.html).
>>> However, these messages are several years old -- is the intrinsic still
>> As far as I can tell llvm.pcmarker was only ever implemented for Alpha,
>> and that backend was removed in 2011. All of the code and documentation
>> relating to pcmarker has been dead for years, and should probably just
>> be removed.
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
Graduate Research Assistant, Systems Software Research Group
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev