similar to: [LLVMdev] MCInstPrinter::printRegName

See the source here: https://github.com/earl/llvm-mirror/blob/master/lib/Target/X86/InstPrinter/X86IntelInstPrinter.cpp. It looks like getRegisterName might do what you want, but I don't know where it's coming from. (Whether it's a function or a member of a super class. Hopefully, if it's a member, it's public.) PS Sorry for the duplicate, Stephen. I forgot to CC the list. On

On Oct 28, 2013, at 2:02 PM, Tyler Hardin <tghardin1 at catamount.wcu.edu> wrote: > See the source here: https://github.com/earl/llvm-mirror/blob/master/lib/Target/X86/InstPrinter/X86IntelInstPrinter.cpp. It looks like getRegisterName might do what you want, but I don't know where it's coming from. (Whether it's a function or a member of a super class. Hopefully, if it's

Can't you just include the generated files? What different way would you like them exposed? On Mon, Oct 28, 2013 at 11:23 AM, Stephen Checkoway <s at pahtak.org> wrote: > > On Oct 28, 2013, at 2:02 PM, Tyler Hardin <tghardin1 at catamount.wcu.edu> > wrote: > > > See the source here: >

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

I'm trying to write a script for checking whether the compiler recursed properly. rkotler at mipsswbrd002:~/slave/recurse3be/build$ find . -name "*.o" -exec cmp '{}' ../../recurse2be/build/'{}' \; |& tee foo.txt Is anyone else doing this? There 2 compilers, recurse 2 and recurse3 that in principle should be identical. Obviously if there is date and time

Dear llvm, Recently (approximately a week ago) Clang and LLVM started to failed at building. Assuming it was my incompetence, I cleared everything and started witha fresh checkout (not that I changed it though). I am on Ubuntu 10.04 LTS 64-Bit. And I configure and compile with CMake. The error message I get at approximatley 66% is as follows: Linking CXX executable ../../bin/llvm-mc

Dawie Joubert <djjoubert at csir.co.za> writes: > Recently (approximately a week ago) Clang and LLVM started to failed at > building. Assuming it was my incompetence, I cleared everything and > started witha fresh checkout (not that I changed it though). I am on > Ubuntu 10.04 LTS 64-Bit. And I configure and compile with CMake. > > The error message I get at approximatley

I am considering using MipsInstPrinter::printAliasInstr, which is auto-generated in MipsGenAsmWriter.inc, to print assembly idioms defined as instruction aliases. For example, an instruction which used to be printed as "nor $1, $2, $zero" can be printed as "not $1, $2" This is nice because it makes the code printed by code-gen or disassembler more readable. However, the

I'm writing a compiler using LLVM, and suddenly today I started to get this error, when emitting to a .s file. Assertion failed: (I != M+Size && I->FromReg == RegNum && "Invalid RegNum"), function getLLVMRegNum, file MCRegisterInfo.cpp, line 78. I'm emitting using x86_64-apple-darwin. Any thoughts about what could be causing this? LLVM validation does not

Hi I come across the following exception when I use the llvm-dwarfdump -debug-info target_binary: llvm-dwarfdump: /home/linux/llvm-7/llvm/lib/MC/MCRegisterInfo.cpp:87: int llvm::MCRegisterInfo::getLLVMRegNum(unsigned int, bool) const: Assertion `I != M+Size && I->FromReg == RegNum && "Invalid RegNum"' failed. Stack dump: 0. Program arguments:

Hi, I'm in the process of adding a X86 ASM Printer for outputting the asm in a style that Yasm can take without any post processing. Yasm's format is very close to that of intel. I was wondering if my approach is correct: I've made a custom MCAsmStreamer to remove some of the COFF symbol directives that yasm doesn't understand. I've made a X86YasmInstPrinter, and added it

On Feb 12, 2011, at 2:07 AM, Nathan Jeffords wrote: > Hello All, > > I have created a set of patches that get dwarf debugging support working for the COFF object file. I also believe I have fixed what appears to be a bug in how line info sections are referred to from the DW_TAG_compile_unit DIE. I have run some basic tests, analyzed dumps of both the objects files and the final

Hello All, I have created a set of patches that get dwarf debugging support working for the COFF object file. I also believe I have fixed what appears to be a bug in how line info sections are referred to from the DW_TAG_compile_unit DIE. I have run some basic tests, analyzed dumps of both the objects files and the final executables, and run a test program against mingw-gdb and everything looks

On Fri, Nov 25, 2011 at 1:47 PM, Charles Davis <cdavis at mymail.mines.edu> wrote: > > On Nov 25, 2011, at 2:22 PM, bigcheesegs at gmail.com wrote: > >> In the case I posted I had removed that line, however, you still get the __3F_ in the generated assembly with it. > Huh. It only seems to happen with a Windows triple or a Linux triple. Doesn't happen with a Mac triple,

Hi Dave I am not going to access any hardware. I am using clang to analysis the ARM binaries. The binary is 483.xalancbmk in CPU SPEC2006. When I use the optimization O0, no crash will occur. The crash occurs when I set optimization level as O1,O2,O3 and Os. If I have to recompile and rerun the tests. What version of llvm is suggested. It would be better if anyone could provide the patch on this

Really sorry I missed this. Just found it looking for something else in my inbox. I think we should support this but * We should still err on other identifiers ".cfi_startport bar" is invalid. * If I read the gas documentation correctly, the effect of "simple" is to skip the initial cfi instructions. We should test if that is the case and implement it too. Accepting and

On Feb 24, 2011, at 11:36 AM, Devang Patel wrote: > > On Feb 12, 2011, at 2:07 AM, Nathan Jeffords wrote: > >> Hello All, >> >> I have created a set of patches that get dwarf debugging support working for the COFF object file. I also believe I have fixed what appears to be a bug in how line info sections are referred to from the DW_TAG_compile_unit DIE. I have run

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 Dave Sorry, I meant the hardware you're using to compile LLVM - you mentioned it took you a long time to rebuild it so it would be hard for you to write/experiment on tests. ============================= Compiling LLVM doesn't take me too much time(less than 2 hours). The hardware is good enough and I am using interl E5 CPU. What I mean is that it took me a long time to analysis the

On Feb 24, 2011, at 11:52 AM, Devang Patel wrote: > > On Feb 24, 2011, at 11:36 AM, Devang Patel wrote: > >> >> On Feb 12, 2011, at 2:07 AM, Nathan Jeffords wrote: >> >>> Hello All, >>> >>> I have created a set of patches that get dwarf debugging support working for the COFF object file. I also believe I have fixed what appears to be a