search for: arminstprint

...nt)': PPCMCTargetDesc.cpp:(.text._ZN4llvm14PPCInstPrinterC1ERKNS_9MCAsmInfoEj[llvm::PPCInstPrinter::PPCInstPrinter(llvm::MCAsmInfo const&, unsigned int)]+0x2d): undefined reference to `vtable for llvm::PPCInstPrinter' ../../lib/libLLVMARMDesc.a(ARMMCTargetDesc.cpp.o): In function `llvm::ARMInstPrinter::ARMInstPrinter(llvm::MCAsmInfo const&)': ARMMCTargetDesc.cpp:(.text._ZN4llvm14ARMInstPrinterC1ERKNS_9MCAsmInfoE[llvm::ARMInstPrinter::ARMInstPrinter(llvm::MCAsmInfo const&)]+0x2a): undefined reference to `vtable for llvm::ARMInstPrinter' ../../lib/libLLVMMBlazeDesc.a(MBlazeMCTarg...

...tDesc.cpp:(.text._ZN4llvm14PPCInstPrinterC1ERKNS_9MCAsmInfoEj[llvm::PPCInstPrinter::PPCInstPrinter(llvm::MCAsmInfo > const&, unsigned int)]+0x2d): undefined reference to `vtable for > llvm::PPCInstPrinter' > ../../lib/libLLVMARMDesc.a(ARMMCTargetDesc.cpp.o): In function > `llvm::ARMInstPrinter::ARMInstPrinter(llvm::MCAsmInfo const&)': > ARMMCTargetDesc.cpp:(.text._ZN4llvm14ARMInstPrinterC1ERKNS_9MCAsmInfoE[llvm::ARMInstPrinter::ARMInstPrinter(llvm::MCAsmInfo > const&)]+0x2a): undefined reference to `vtable for > llvm::ARMInstPrinter' > ../../lib/libLLVMMBlaz...

...vide a good starting point so that the support wouldn't have to be done from scratch. I will try to find those pre-v3 patches. In meantime I wrote a patch which changes to old mnemonics for shift instructions. This fixes compiling on the freebsd. --- a/contrib/llvm/lib/Target/ARM/InstPrinter/ARMInstPrinter.cpp +++ b/contrib/llvm/lib/Target/ARM/InstPrinter/ARMInstPrinter.cpp @@ -44,17 +44,18 @@ void ARMInstPrinter::printInst(const MCInst *MI, raw_ostream &O) { const MCOperand &MO2 = MI->getOperand(2); const MCOperand &MO3 = MI->getOperand(3); - O << '\t'...

On Jun 22, 2011, at 9:00 AM, Renato Golin wrote: > On 22 June 2011 16:50, Jim Grosbach <grosbach at apple.com> wrote: >>> This sounds like a dead end as newer binutils are GPLv3. >> >> Yeah, that's definitely a very real concern and a big motivation to get the MC based asm parser whipped into usable shape. We're much more in control of our own destiny then.

...compiling on the freebsd. If this is really the only issue you're seeing, we may be lucky and your binutils already have support for lots of the changes necessary to handle llvm assembly. Let's cross our fingers that's the case. > > --- a/contrib/llvm/lib/Target/ARM/InstPrinter/ARMInstPrinter.cpp > +++ b/contrib/llvm/lib/Target/ARM/InstPrinter/ARMInstPrinter.cpp > @@ -44,17 +44,18 @@ void ARMInstPrinter::printInst(const MCInst *MI, raw_ostream &O) { > const MCOperand &MO2 = MI->getOperand(2); > const MCOperand &MO3 = MI->getOperand(3); > >...

...imG's new MC/.s ARMAsmPrinter::EmitInstruction() somehow bypassing > these completely? > The ones in ARMAsmPrinter.cpp are now effectively unused, and I'll be removing them soon. I just need to do a bit of tablegen hacking first to be able to do so. The MC versions are in AsmPrinter/ARMInstPrinter.cpp. > 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). Since this is by definition only for .s file emission, why is this clearly wrong? Perhaps it is, but it's not ob...

Hi Everyone, I am trying to decide on a MC'ized reorg of ARMAsmPrinter for MC/ELF, and had some 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

.... For ARM, the ARM backend has completely migrated yet. The first major step is to get the ARM backend emitting instructions by lowering them to MCInst's then pushing the MCInst through the AsmStreamer interface. This allows the encoder to handle them, or (if actually emitting a .s file) the ARMInstPrinter to print out the instruction. I started this process, but haven't finished it and it isn't a very high priority for me. To see what is being emitted textually, you can do something like this: $ llc foo.bc -o - -filetype=null -march=arm This will cause everything emitted to the MCStream...

Hello, I'm interested in the status of LLVM-MC. My particular interest is in generating executables for ARM embedded applications. I assume this application is not terribly high on the priority list, so I would like to know how I can contribute. Can someone point me to some information and/or docs on the project and its status. Also, if someone could give me an example of how

Is it possible to represent floating-point constants in TableGen definitions? Let's say I have the following pattern: def : Pat<(i1 (trunc RegI16:$a)), (SETPGTu16ri RegI16:$a, 0)>; Note the zero constant in the result. Is there a way to represent floating-point literals in the same way? Something like... def : Pat<(i1 (uint_to_fp RegF32:$a)), (SETPGTf32ri RegF32:$a,

...curse2be/build/./lib/Target/ARM/Release+Asserts/ARMBaseRegisterInfo.o differ: byte 51142, line 104 ./lib/Target/ARM/Release+Asserts/ARMISelDAGToDAG.o ../../recurse2be/build/./lib/Target/ARM/Release+Asserts/ARMISelDAGToDAG.o differ: byte 245280, line 1268 ./lib/Target/ARM/InstPrinter/Release+Asserts/ARMInstPrinter.o ../../recurse2be/build/./lib/Target/ARM/InstPrinter/Release+Asserts/ARMInstPrinter.o differ: byte 192432, line 305 ./lib/Target/ARM/AsmParser/Release+Asserts/ARMAsmParser.o ../../recurse2be/build/./lib/Target/ARM/AsmParser/Release+Asserts/ARMAsmParser.o differ: byte 665774, line 1708 ./lib/Targ...

...lls TheTarget->createMCDisassembler() and gets one disassembler for TheTarget it created. I talked to Jim a bit about sinking the logic of maintaining multiple disassemblers down into the core disassembler logic and using subtarget to select between them. Like the ARMAsmParser and I think the ARMInstPrinter work. But that seems very complicated for a single target that has two disassemblers. The implementation of llvm-objdump does have a MachODump.cpp for use with the -m option that I could do the a similar hack otool(1) like hack and special case 32-bit ARM cpus. And at least it contains the ugl...