similar to: [LLVMdev] State of 'llvm.pcmarker' Intrinsic

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

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

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()); > >

Hi Everyone, I am building a script for a client and my imagecreatefromjpeg() is throwing a fatal exception, and dying. It seems as my server with CentOS 4, PHP 4.3.9 doesn't have >= GD-1.8 support or better. I did a phpinfo() and I can not find any reference to GD..............Any help on this would be well appricated -- Best Regards, Jon McCauley

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()); > > and got some unexpected string in the assembler output. The problem is > that when external

Hey everyone! Got a little problem...with CentOS / BQ / PHP 4.3.9 with the mail() function I'm able to send mail using postfix directly from the command line, however when I try using the mail function of php no mail is being sent. This simple script works on all my older Cobalt Boxs. <? if($action=="send") { $to = 'me at domain.dot'; $subject = 'the

Hello list, On linux, ld has the following option: --whole-archive For each archive mentioned on the command line after the --whole-archive option, include every object file in the archive in the link, rather than searching the archive for the required object files. This is normally used to turn an archive file into a shared library,

Hi, I'd like to disable all inlining in llvm-gcc/llvm-g++. From the FAQ on llvm.org, I see: "Passing "-Wa,-disable-opt -Wl,-disable-opt" will disable *all* cleanup and optimizations done at the llvm level, leaving you with the truly horrible code that you desire." But from a cursory glance at llvm-backend.cpp I don't immediately see that everything has been disabled

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 2/27/15 6:30 PM, Ziqiang Patrick Huang wrote: > Hi, all > > Is there a way of getting the basic block offset from its parent > function ? At the LLVM IR level, no. At the code generator layer (MachineFunctionPass layer or the MC layer), probably yes. > > What I'm trying to do is to get an execution count of each basic > blocks, so I need to know the starting

Hi John Thanks for your suggestions, they all sound reasonable to me. The way I'm thinking right now is to write a MachineFuncionPass that iterate through each MachinBasicBlock, for each MBB, adds up the instructions counts of previous MBBs, that number multiply by 4 should be the offset of that MBB from its MachineFunction. In order to correctly count the instructions, this pass should be

Hello, I just wrote the code like this: BuildMI(BB, NM::CALL, 1) .addExternalSymbol(("_lvksda_control_marker_" + lexical_cast<string>(bb)).c_str()); and got some unexpected string in the assembler output. The problem is that when external symbol is added to MachineInstruction, MachineOperand is created with the char*

On Sat, Feb 28, 2015 at 7:39 AM, Ziqiang Patrick Huang < ziqiang.huang1001 at gmail.com> wrote: > Hi John > > Thanks for your suggestions, they all sound reasonable to me. The way I'm > thinking right now is to write a MachineFuncionPass that iterate through > each MachinBasicBlock, for each MBB, adds up the instructions counts of > previous MBBs, that number multiply

Hi, I have written a code layout feedback directed optimization pass, which currently works for basic block reordering and function reordering. It very effectively improves the speedup (we could improve Python by 30%). The profiling method is window based context sensitive which is based on reference affinity (

On Friday 15 April 2005 19:29, Chris Lattner wrote: > 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