similar to: [LLVMdev] MachineInstr: external symbols problem

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

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

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

Hi,   For a custom target, there is a pass to perform memory dependence analysis, where, i need to get memory pointer for "load instruction". I want to check the pointer alias behavior. I am getting this by considering the memoperands for the load instruction.   For "load instruction", Machine Instruction dumps as below:   vr12<def> = LD_Iri %vr2<kill>, 0;

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

+the list again On Sep 17, 2013, at 3:48 PM, reed kotler <rkotler at mips.com> wrote: > On 09/17/2013 03:46 PM, Owen Anderson wrote: >> On Sep 17, 2013, at 3:08 PM, reed kotler <rkotler at mips.com> wrote: >> >>> Is there any way, except for using bundles, to force two instructions to be sequentially executed? >> What level of codegen are you working at?

Reed, Couldn't you also use instruction scheduling classes and specify that the second instruction has a bypass from the first instruction? The scheduler should always schedule them together in that case. Micah > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On > Behalf Of reed kotler > Sent: Tuesday, September 17, 2013

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

I used the A9 schedule as an example: http://llvm.org/svn/llvm-project/llvm/trunk/lib/Target/ARM/ARMScheduleA9.td The documentation could use more clarity, but this is how I was able to do it to always get two specific instructions to be scheduled together. ________________________________________ From: reed kotler [rkotler at mips.com] Sent: Tuesday, September 17, 2013 8:54 PM To: Micah Villmow

On 09/17/2013 03:52 PM, Owen Anderson wrote: > +the list again > On Sep 17, 2013, at 3:48 PM, reed kotler <rkotler at mips.com> wrote: > >> On 09/17/2013 03:46 PM, Owen Anderson wrote: >>> On Sep 17, 2013, at 3:08 PM, reed kotler <rkotler at mips.com> wrote: >>> >>>> Is there any way, except for using bundles, to force two instructions to be

On 09/17/2013 04:51 PM, Micah Villmow wrote: > Reed, > Couldn't you also use instruction scheduling classes and specify that the second instruction has a bypass from the first instruction? The scheduler should always schedule them together in that case. > > Micah > I'm not sure exactly what you mean. Can you point me to an example of that? TIA. Reed >>

That doesn't actually give you a guarantee that they won't be split up. Phases other than the scheduler may insert instructions in the middle of block (constant island pass, for example). Pseudo-instructions are the canonical answer to that problem. --Owen On Sep 17, 2013, at 11:09 PM, Micah Villmow <micah.villmow at smachines.com> wrote: > I used the A9 schedule as an

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, On Wed, Apr 2, 2014 at 1:03 AM, Michael Spencer <bigcheesegs at gmail.com> wrote: > On Mon, Mar 31, 2014 at 10:54 AM, Simon Atanasyan <simon at atanasyan.com> wrote: >> As far as I understand now it is impossible to generate ELF object >> file with relocation sections using yaml2obj tool. I plan to support >> ELF relocations in the yaml2obj. Does anybody work

Hi Sergei, our use of target flags will be on immediate register operands if I am not mistaken (and if not we can always encode it as such)? I guess you are refering to the hexagon backend needing to distinguish between instances of an instruction that uses a constant value that can fit into the 4 byte of the instruction and one that encodes the immediate in an extra instruction slot (what we

Jakob and anyone else who might be interested... Base on this patch back in August, I sense some need to double check with you whether it is OK to start making a heavy use of MachineOperand TargetFlags? We do seem to have a compelling reason for it in Hexagon, and I wanted to make sure that it is OK with everyone. I plan to use it for attributing target specific info to MOs and in more general

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.

Hi, I want to know what is the type or size of a virtual register in a Machineinstr::MachineOperand (If this MachineOperand is a register). For example, what is the size of reg16385 in the following MachineInstr. I know now in the llvm bitcode, the type of a Instruction could be obtained from the Value::GetType(), but what is the counterpart in MachineInstr (not derived from class Value)?

In the representation of the code after instruction selection (but before register allocation), in a MachineBasicBlock: How/where is the result of a machine instruction linked to one of the machine operands of a subsequent machine instruction? Asked differently: How/where are the links of the DAG implemented (specially between MachineInstr and MachineOperand)? Frank