search for: emitinstruction

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(); MachineInstr *CloneMI = MF->Clon...

I'm trying to clone a MachineInstr in the AsmPrinter::EmitInstruction, Here is the code: void EsenciaAsmPrinter::EmitInstruction(const MachineInstr *MI) { const MachineFunction *MF = MI->getParent()->getParent(); MachineInstr *CloneMI = MF->CloneMachineInstr(MI); ... ... } The problem is that MF is a const and CloneMachineInstr expects a non-const. Doe...

...using MachineCodeEmitter::emit* functions > - call MachOCodeEmitter::finishFunction > > [This runOnMachineFunction could definitely be generalized, i.e. > implemented in a base class ('EmitterMachineFunctionPass' or a better > name). This base class would then have (abstract) emitInstruction, > emitOperand, etc... methods. It should also integrate with the > *GenCodeEmitter emitted by tblgen so that you get automatic code > emission. When implementing a new target, one would simply need to > inherit the baseclass, and override the functions necessary to tweak > output.]...

...is > > that PPC has overriden the API to layer some custom "bundling" logic > > on top of basic hazard detection. This logic needs to be reversed for > > bottom-up, or you could start by simply disabling it instead of the > > entire hazard recognizer. > > 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...

...mitter, which would inherit MachineFunctionPass. This base-class should implement runOnMachineFunction using the pattern described above, as it seems relatively target-nonspecific. In order to emit actual instructions, the ObjectEmitter::runOnMachineFunction could call the (abstract) ObjectEmitter::emitInstruction method, which _must_ be target-specific. This emitInstruction method could either be abstract, in which case the developer of the target backend must implement it appropriately. Alternatively it could be virtual, with the default implementation utilizing tblgen generated emission code. In either...

...registers a fixup for the addrmode_imm12 operand when it needs one. Hi Jim,. follow up question for ya: The current movt/movw pair (as defined in ARMInstrInfo.td) does not use EncoderMethod string to declare a special case handler. At the current time, for the assembly printing, MCAsmStreamer::EmitInstruction(const MCInst &Inst) calls out to MCExpr::print(raw_ostream &OS) which then calls out to MCSymbolRefExpr::getVariantKindName() to print the magic :lower16: and :upper16: asm tags for .s emission Currently, movt/movw emission works correctly in .s, but not in .o emission This lead me to...

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

...l Finkel wrote: >> From the perspective of the hazard recognizer, from what I can tell, the > difference between the top-down and bottom-up modes are: > > In top-down mode, the scheduling proceeds in the forward direction. > AdvanceCycle() may be used, RecedeCycle() is not used. EmitInstruction() > implies a cycle-count increment. In bottom-up mode, scheduling proceeds > in the backwards direction (last instruction first). AdvanceCycle() is > not used, RecedeCycle() is always used to decrement the current cycle > offset (EmitInstruction() does *not* imply a cycle-count decreme...

...thought to this before? Is there already a > way to create bundles in the MC layer that we've overlooked? There should already be sufficient support for what you're trying to do. See MCOperand::CreateInst(). The concept is that you'll build a composite MCInst in your AsmPrinter::EmitInstruction() method, which uses Inst-type MCOperands to hold a list of sub-instructions. Then you call AsmStreamer::EmitInstruction() on the composite MCInst. --Owen

On Mon, 2011-11-28 at 15:45 -0800, Andrew Trick wrote: > > 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...

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, 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. how can i find out which instruction is executed at this point or in which function we are currently? i also attached a very small example, which tr...

...amp;, llvm::MCSubtargetInfo const&) const lib/Target/X86/MCTargetDesc/X86MCCodeEmitter.cpp:1512:67 #10 0x00000000015884b3 llvm::MCELFStreamer::EmitInstToData(llvm::MCInst const&, llvm::MCSubtargetInfo const&) lib/MC/MCELFStreamer.cpp:478:26 #11 0x00000000015aadc0 llvm::MCObjectStreamer::EmitInstruction(llvm::MCInst const&, llvm::MCSubtargetInfo const&) lib/MC/MCObjectStreamer.cpp:245:5 #12 0x00000000007a036b llvm::X86AsmPrinter::EmitAndCountInstruction(llvm::MCInst&) lib/Target/X86/X86MCInstLower.cpp:106:3 #13 0x00000000007a32dc llvm::X86AsmPrinter::EmitInstruction(llvm::MachineInstr...

...e endianess of the LLVM chain is controlled by the DataLayout class, but it appear to me that llvm-mc does not make use of such class. I've seen a backend (CPU0, http://jonathan2251.github.io/lbd/genobj.html) that defines two different targets and performs the byte swapping as part of the 'EmitInstruction'. Is it the right way? Could somebody confirm my understanding and give me some tips about endianess in llvm-mc? Thanks, Dominique T. [http://www.spacebel.be/wp-content/uploads/2011/06/image-sign-sbp.jpg] Dominique Torette System Architect Rue des Chasseurs Ardennais -...

...ink I've found a bug in the x86 JIT. I get an assertion failure when using thread-local variables and the fast emitter. It only happens with the JIT, the fast emiiter and thread-locals. (The IR passes the verifier) Here's the failure: X86CodeEmitter.cpp:516: void<unnamed>::Emitter::emitInstruction(const llvm::MachineInstr&, const llvm::TargetInstrDesc*): Assertion `0 && "psuedo instructions should be removed before code emission"' failed. There is a problem with submitting a bug-report, however. Since llc has no trouble with thread-locals, I cannot actually gener...

Hi, I have a problem with creating a MFENCE on X86 with SSE In X86InstrSSE.td, a MFENCE is def MFENCE : I<0xAE, MRM6m, (outs), (ins), "mfence", [(int_x86_sse2_mfence)]>, TB, Requires< [HasSSE2]>; In X86CodeEmitter.cpp in emitInstruction case X86II::MRM6m: case X86II::MRM7m: { intptr_t PCAdj = (CurOp+4 != NumOps) ? (MI.getOperand(CurOp+4).isImm() ? X86InstrInfo::sizeOfImm (Desc) : 4) : 0; ... If I'm reading the code correctly, the NumOps is 0 and CurOp is 0 so we to get the 4th operand from the MFENCE opera...

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

...: AsmPrinter(TM, Streamer) { } > + explicit AMDGPUAsmPrinter(TargetMachine &TM, MCStreamer &Streamer); > > virtual bool runOnMachineFunction(MachineFunction &MF); > > @@ -38,6 +39,11 @@ > > /// Implemented in AMDGPUMCInstLower.cpp > virtual void EmitInstruction(const MachineInstr *MI); > + > +protected: > + bool DisasmEnabled; > + std::vector<std::string> DisasmLines, HexLines; > + size_t DisasmLineMaxLen; > }; > > } // End anonymous llvm > Index: lib/Target/R600/AMDGPUMCInstLower.cpp > ==========================...

...questions. Currently, it defines quite a few methods like printAddrMode4Operand (linked to ARMInstrInfo.td) that currently assume raw text support in the OutStreamer. Are these methods still supposed to be invoked in the MC'ized path for assembly output? Is JimG's new MC/.s ARMAsmPrinter::EmitInstruction() somehow bypassing these completely? and also on EmitStartOfAsmFile(), it emits a bunch of text assembly attributes - which is clearly wrong for MC (but is still being used in the asm emission). Can anyone suggest a better mechanism to switch on this than using OutStreamer.hasRawTextSupport()?...

Hi, This patch adds R600/SI disassembly text to compiled object files, when a code dump is requested, to assist debugging in Mesa clients. Here's an example of the output in a Mesa client with a corresponding patch and RADEON_DUMP_SHADERS set: Shader Disassembly: S_WQM_B64 EXEC, EXEC ; BEFE0A7E S_MOV_B32 M0, SGPR6 ; BEFC0306