similar to: Cloning a MachineInstr

I'm working on a custom VLIW (we call it Escala). At the moment I'm trying to implement EscalaAsmPrinter::EmitInstruction(const MachineInstr *MI). I'm trying to clone an instruction and this produces and error. Below are the code as well as error: void EscalaAsmPrinter::EmitInstruction(const MachineInstr *MI) { const MachineFunction *MF = MI->getParent()->getParent();

Hi, Is there a way to passing llc options to clang, for example -march -mcpu, etc. ? Some threads suggested using -mllvm flag, I tried ./clang -mllvm -march=X86-64 -mcpu=core2 -o hello hello.c, but got "Unknown command line argument" Thanks, Ziqiang -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi, I'm working on a project that use llvm openrisc beckend (currently not part of the upstream). Right now I'm looking at a bug where llc generates memory instructions that has out-of-range displacement, for example l.sb 37668(r1), r2 in which 37668 is a 17 bit signed integer, but the instruction only allows 16 bit signed displacement. As a result, after running through the

Hello everyone, In the file *lib/CodeGen/AsmPrinter/AsmPrinter.cpp*, I would like to obtain an MCInst corresponding to its MachineInstr. Can anyone tell me a way to do that? If that is not possible, then, I would like to know if a given MachineInstr is an *lea *instruction and I would like to know if the symbol involved with this lea instruction is a jump-table. For instance, given a

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

Hi, Is there a way to see what the default argument llc takes from clang/clang++ ? I'm debugging my backend with a very simple c++ program. Running through *clang++ -target myTarget -S simple.cpp -o simple.s * (bug does no show up) gives me different results from *clang++ -target myTarget -S -emit-llvm -o simple.cpp -o simple.ll* *llc simple.ll -o simple.s *(bug shows up) Just trying to

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, all Is there a way of getting the basic block offset from its parent function ? What I'm trying to do is to get an execution count of each basic blocks, so I need to know the starting address of each basic blocks. Obviously we can't get the absolute address before linking the program, but the offset relative to parent function should be available so I can take it and get the function

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

Dear all, I’m not sure if it is O.K. to ask this question here. But where can I find the code for the function ‘C_Cdqrls’ which is called by the R function ‘lsfit‘. Thank you all. Sorry for being naïve if so. -------------------- Ziqiang Zhao 2013-04-23 [[alternative HTML version deleted]]

> What are you trying to achieve in the end? > > — > Mehdi > > I need to insert extra NOP instructions into the bundle or at least generate a few extra ones during the assembly generation. -- Rail Shafigulin Software Engineer Esencia Technologies -------------- next part -------------- An HTML attachment was scrubbed... URL:

> Aaron, I mailed in the same mail twice (by mistake), you answered both > copies. Differently! > > In any case, I've re-read what exists. I'm dumping what I understand > here, so that we can discuss in detail. I'm using MachO as the example > object format, as the ELF code is totally broken and outdated. Lets > use the following as the basis for our discussion?

On Tue, 2011-11-22 at 13:27 -0600, Hal Finkel wrote: > On Tue, 2011-10-25 at 21:00 -0700, Andrew Trick wrote: > > On Oct 25, 2011, at 6:01 PM, Hal Finkel wrote: > > > Is there documentation somewhere for the bottom-up scheduling? I'm > > > trying to figure out what changes are necessary in order to support it > > > in the PPC backend. > > > >

Hello all, We're developing an integrated assembler for a VLIW target, and some of the optimizing our assembler needs to do must be done on a per-packet basis. This requires us to be able to traverse instruction within a packet, and one particular optimization requires traversal of previous packets as well. We're considering adding support for MCInst bundles in the MC layer to

Hi all, I¡¯m trying to build R (32-bit) under Windows 7 (64-bit). To do so, I just use ¡±make all recommended¡± as mentioned in the documents and it does work for R 2.15.2. However, for R 3.0.2, I get the following error message, gcc -shared -s -static-libgcc -o tools.dll tmp.def text.o init.o Rmd5.o md5.o signals.o install.o getfmts.o http.o

> I've never looked at the MachO code as I do not have such a platform nor do > I know the file format. > > Could we concentrate on the ELF backend, please. I don't mind using the ELF backend as our test case, it just seems that the ELFWriter/ELFCodeEmitter don't even use the BufferBegin/BufferEnd/CurBufferPtr system exposed by the base MachineCodeEmitter. There is a big

hi, when using the execution engine (no matter, if JIT or Interpreter) i get the following assertion as soon as i use boost::shared_ptr: /build/buildd/llvm-2.5/lib/Target/X86/X86CodeEmitter.cpp:522: void<unnamed>::Emitter::emitInstruction(const llvm::MachineInstr&, const llvm::TargetInstrDesc*): Assertion `0 && "JIT does not support inline asm!\n"' failed.

+llvmdev -llvmcommits On Fri, Nov 12, 2010 at 8:03 AM, Jim Grosbach <grosbach at apple.com> wrote: > Sorta. getBinaryCodeForInst() is auto-generated by tablegen, so shouldn't be modified directly. The target can register hooks for instruction operands for any special encoding needs, including registering fixups, using the EncoderMethod string. For an example, have a look at the

On Nov 29, 2011, at 10:47 AM, Hal Finkel wrote: > Andy, > > I should have been more clear, the ARM implementation has: > void ARMHazardRecognizer::RecedeCycle() { > llvm_unreachable("reverse ARM hazard checking unsupported"); > } > > How does that work? > > Thanks again, > Hal Hal, My first answer was off the top of my head, so missed the subtle

On Nov 28, 2011, at 3:35 PM, Hal Finkel wrote: >> >> Is EmitInstruction used in bottom-up scheduling at all? The version in >> the ARM recognizer seems essential, but in all of the regression tests >> (and some other .ll files I have lying around), it is never called. It >> seems that only Reset() and getHazardType() are called. Could you please >> explain the