search for: mcinstprinter

I have a question regarding implementation of subclasses of MCInstPrinter. I am implementing Machine IR layer to MC layer lowering for Mips. What's the best way to print the value of "Register" in the following code in MCAsmStreamer::EmitRegisterName? Do I have to convert the LLVM register number back to its corresponding dwarf register number in function...

I'm iterating over MCInsts and I'd like to examine particular instructions. For example, I'd like to look at all x86 CALL64m instructions. I may be missing something, but it seems like my only option is to use MCInstPrinter::getOpcodeName and compare strings. (Of course, I could iterate through the opcodes and build up a table of the ones I'm interested in to avoid string comparisons.) Register mappings to names seem to be even worse. It appears you have to go through MCInstPrinter::printRegName(raw_ostream&,...

...t;Stephen Checkoway" <s at pahtak.org> wrote: > I'm iterating over MCInsts and I'd like to examine particular > instructions. For example, I'd like to look at all x86 CALL64m > instructions. I may be missing something, but it seems like my only option > is to use MCInstPrinter::getOpcodeName and compare strings. (Of course, I > could iterate through the opcodes and build up a table of the ones I'm > interested in to avoid string comparisons.) > > Register mappings to names seem to be even worse. It appears you have to > go through MCInstPrinter::printR...

...3 12:03 PM, "Stephen Checkoway" <s at pahtak.org> wrote: > I'm iterating over MCInsts and I'd like to examine particular instructions. For example, I'd like to look at all x86 CALL64m instructions. I may be missing something, but it seems like my only option is to use MCInstPrinter::getOpcodeName and compare strings. (Of course, I could iterate through the opcodes and build up a table of the ones I'm interested in to avoid string comparisons.) > > Register mappings to names seem to be even worse. It appears you have to go through MCInstPrinter::printRegName(raw_ost...

...ephen Checkoway" <s at pahtak.org> wrote: > > I'm iterating over MCInsts and I'd like to examine particular > instructions. For example, I'd like to look at all x86 CALL64m > instructions. I may be missing something, but it seems like my only option > is to use MCInstPrinter::getOpcodeName and compare strings. (Of course, I > could iterate through the opcodes and build up a table of the ones I'm > interested in to avoid string comparisons.) > > > > Register mappings to names seem to be even worse. It appears you have to > go through MCInstPrint...

...backends too. I have implemented a prototype of this extension in https://reviews.llvm.org/D74338. AssemblerPredicates are used in four parts of TableGen, three of which only affect TableGen'erated code, and one is RISC-V specific so these changes are not very intrusive. For AsmWriterEmitter/MCInstPrinter to work with these changes, I've made what I think may be a minimally distruptive change, but I'm happy to hear any alternative ideas on how to express this to the AsmWriter alias condition code. I look forward to any ideas and feedback. Thanks, Simon

...thout subtarget specific information. I can encode that as instruction predicates (, Requires<[IsMClass]>, assuming I've added a new predicate 'IsMClass'), but getting the generated decoder to be subtarget-dependent was quite an invasive change. I also had to do the same with the MCInstPrinter - it can't know whether to print mask names for the M-series or the AR-series without a SubtargetInfo. I'd like to know if yourself or perhaps Owen/Eric has any input on the track I'm going down. From my (possibly tunnel-visioned) perspective it's the only logical solution, and I...

...information. > > I can encode that as instruction predicates (, Requires<[IsMClass]>, assuming > I've added a new predicate 'IsMClass'), but getting the generated decoder to be > subtarget-dependent was quite an invasive change. I also had to do the same with > the MCInstPrinter - it can't know whether to print mask names for the M-series > or the AR-series without a SubtargetInfo. > > I'd like to know if yourself or perhaps Owen/Eric has any input on the track I'm > going down. From my (possibly tunnel-visioned) perspective it's the only logic...

...00000002668edc llvm::X86ATTInstPrinter::printInst(llvm::MCInst const*, llvm::raw_ostream&, llvm::StringRef, llvm::MCSubtargetInfo const&) /home/shenyouren/workspace/llvm/lib/Target/X86/InstPrinter/X86ATTInstPrinter.cpp:89:0 #14 0x00000000031d5811 llvm::MCTargetStreamer::prettyPrintAsm(llvm::MCInstPrinter&, llvm::raw_ostream&, llvm::MCInst const&, llvm::MCSubtargetInfo const&) /home/shenyouren/workspace/llvm/lib/MC/MCStreamer.cpp:856:0 #15 0x00000000031690e2 (anonymous namespace)::MCAsmStreamer::EmitInstruction(llvm::MCInst const&, llvm::MCSubtargetInfo const&, bool) /home/sh...

On Mar 30, 2012, at 3:12 PM, Benjamin Kramer <benny.kra at googlemail.com> wrote: > > On 30.03.2012, at 23:30, Jakob Stoklund Olesen wrote: > >> Is this function required? >> >> MCInstrInfo::getName(OpCode) returns the same string, and we have two copies of the string table now. >> >> Can MCInstrPrinter refer to MCInstrInfo, and why not? > >

...m-3.2.src/tools/llvm-mc.org/llvm-mc.cpp +++ llvm-3.2.src/tools/llvm-mc/llvm-mc.cpp @@ -17,7 +17,6 @@ #include "llvm/MC/MCAsmBackend.h" #include "llvm/MC/MCAsmInfo.h" #include "llvm/MC/MCContext.h" -#include "llvm/MC/MCCodeEmitter.h" #include "llvm/MC/MCInstPrinter.h" #include "llvm/MC/MCInstrInfo.h" #include "llvm/MC/MCObjectFileInfo.h" @@ -26,7 +25,6 @@ #include "llvm/MC/MCStreamer.h" #include "llvm/MC/MCSubtargetInfo.h" #include "llvm/MC/MCTargetAsmParser.h" -#include "llvm/MC/SubtargetFeatur...

Hi In my MC6809 backend, in llvm/lib/Target/MC6809/InstPrinter/MC6809InstPrinter.cpp, I have the routine void MC6809InstPrinter::printPCRelImmOperand(const MCInst *MI, unsigned OpNo, raw_ostream &O) { const MCOperand &Op = MI->getOperand(OpNo); ZZ if (Op.isImm()) { int64_t Imm = Op.getImm() + 2; <<<======================== O << "$"; if (Imm

Hi Kurt, The assembly parser doesn't (yet) handle these, you're right. Currently, the MRS instruction is split into two variants in the ARMInstrThumb2.td file, t2MRS and t2MRSsys, one for the user mode version reading cpsr and one for the system mode version reading spsr. MSR, by contrast, has a custom parse method for the mask operand since it's a bit more complex than an either/or.

I was attempting to compile some code with a recent (r138716) version of llvm/clang, targeting a cortex-m4 processor. And I get an error like this: CC: sched_garbage.c In file included from sched_garbage.c:43: In file included from ./os_internal.h:48: In file included from /p/nuttx/trunk/nuttx/include/sched.h:47: In file included from /p/nuttx/trunk/nuttx/include/nuttx/sched.h:54: In file

OK. Let's try a specific example: At least for ELF files, GNU objdump prints operand values in hex. AFAIK, hex is not just the default, but the only choice. On the other hand, llvm-objdump prints operand values in decimal and ignores the --print-imm-hex option for ELF. How about a patch to print operands in hex for ELF? Good place to start? On Mon, Dec 1, 2014 at 5:49 PM, Kevin Enderby

...--- a/include/llvm/Target/TargetRegistry.h +++ b/include/llvm/Target/TargetRegistry.h @@ -24,6 +24,7 @@ #include <cassert> namespace llvm { + class AsmParser; class AsmPrinter; class Module; class MCAssembler; @@ -34,9 +35,9 @@ namespace llvm { class MCDisassembler; class MCInstPrinter; class MCStreamer; + class SourceMgr; class TargetAsmBackend; class TargetAsmLexer; - class TargetAsmParser; class TargetMachine; class raw_ostream; @@ -65,7 +66,11 @@ namespace llvm { const std::string &TT); typedef Tar...

...Installing: /usr/local/llvm-2.8/include/llvm/MC/MCELFSymbolFlags.h -- Installing: /usr/local/llvm-2.8/include/llvm/MC/MCExpr.h -- Installing: /usr/local/llvm-2.8/include/llvm/MC/MCFixup.h -- Installing: /usr/local/llvm-2.8/include/llvm/MC/MCInst.h -- Installing: /usr/local/llvm-2.8/include/llvm/MC/MCInstPrinter.h -- Installing: /usr/local/llvm-2.8/include/llvm/MC/MCLabel.h -- Installing: /usr/local/llvm-2.8/include/llvm/MC/MCMachOSymbolFlags.h -- Installing: /usr/local/llvm-2.8/include/llvm/MC/MCObjectStreamer.h -- Installing: /usr/local/llvm-2.8/include/llvm/MC/MCObjectWriter.h -- Installing: /usr/local/...

On Thu, Sep 30, 2010 at 3:08 PM, Samuel Williams <space.ship.traveller at gmail.com> wrote: > Hi, > > I might just be doing something stupid, but when I do > > $ cmake -DCMAKE_INSTALL_PREFIX=/usr/local/llvm-2.8 -DCMAKE_BUILD_TYPE=Release .. > $ sudo make install > > I don't get the expected headers in >        /usr/local/llvm-2.8/include/llvm > > It is

Hi, I might just be doing something stupid, but when I do $ cmake -DCMAKE_INSTALL_PREFIX=/usr/local/llvm-2.8 -DCMAKE_BUILD_TYPE=Release .. $ sudo make install I don't get the expected headers in /usr/local/llvm-2.8/include/llvm It is simply an empty directory. What am I doing wrong? This is on Mac OS X, CMake 2.8+ Kind regards, Samuel

...xt.cpp for Release+Asserts build llvm[3]: Compiling DWARFUnit.cpp for Release+Asserts build llvm[3]: Compiling PDBExtras.cpp for Release+Asserts build llvm[2]: Compiling MCInst.cpp for Release+Asserts build llvm[2]: Compiling LocalStackSlotAllocation.cpp for Release+Asserts build llvm[2]: Compiling MCInstPrinter.cpp for Release+Asserts build llvm[3]: Compiling SyntaxHighlighting.cpp for Release+Asserts build llvm[3]: Compiling PDBInterfaceAnchors.cpp for Release+Asserts build llvm[3]: Compiling PDBSymDumper.cpp for Release+Asserts build llvm[2]: Compiling MCInstrAnalysis.cpp for Release+Asserts build llvm[...