search for: mcregisterinfo

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: /home/linux/llvm-7/llvm/build/bin/llvm-dwarfdump -debug-info C++/483.xalancb...

...Nov 3, 2018 at 6:51 AM Muhui Jiang via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> 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: >> /home/linux/llvm-7/llvm/build/b...

I am going to remove these functions from MCRegisterInfo: getSubRegisters() getSuperRegisters() getOverlaps() getAliasSet() They have been replaced with iterator classes, also defined in MCRegisterInfo.h: MCSubRegIterator MCSuperRegIterator MCRegAliasIterator The tree has lots of examples of how to use all three. /jakob

...; llvm-dev at lists.llvm.org> wrote: >>> >>>> 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: >>...

...ic, thank you very much for the pointer to your work; it’s saving me a lot of time! Unfortunately, I am running into one issue that my knowledge isn’t complete enough to solve on my own yet. The description of D6771 reads, "It requires a few preliminary patches like landing D6243 and adding a MCRegisterInfo in the DWARFContext". The latter, adding an MCRegisterInfo, seems to be a bit beyond me. Specifically, while I can get a target architecture from a given ObjectFile using getArch(), I’m not sure how to turn this into an MCRegisterInfo (or really anything, such as Target, that could lead to on...

...' register. The register aliasing graph is not a tree. The graph of sub/super-register relationships is also not a tree, it is a DAG. Take a look at the ARM register bank. It demonstrates most of this stuff. We try to track anything related to register aliasing in terms of register units. See MCRegisterInfo.h and TargetRegisterInfo.h. I believe regunits are equivalent to maximal cliques of the register aliasing graph if you're mathematically inclined. I think it is easier to think about them as minimal sub-registers, even if that is not always completely accurate. /jakob

...Tom #define GET_REGINFO_ENUM #include "AArch64GenRegisterInfo.inc" #define GET_INSTRINFO_ENUM #include "AArch64GenInstrInfo.inc" #define GET_SUBTARGETINFO_ENUM #include "AArch64GenSubtargetInfo.inc" #include "llvm/MC/MCSchedule.h" #include "llvm/MC/MCRegisterInfo.h" #include "llvm/MC/MCInstrDesc.h" #include "llvm/MC/MCInstrInfo.h" #include "llvm/MC/SubtargetFeature.h" #include "llvm/MC/MCSubtargetInfo.h" #define GET_INSTRINFO_MC_DESC #include "AArch64GenInstrInfo.inc" #define GET_SUBTARGETINFO_MC_DESC...

I'm working on the post-regalloc dataflow engine I mentioned yesterday. Currently I only need to track register operands. A MachineOperand has both a getReg() and a getSubReg() interface. For a physical register operand, is getReg() guaranteed to be the "most super" register with getSubReg() providing the specific subregister information for the operand? If so then for my current

...I guess libXXXDesc could be refactored not to depend on libXXXAsmPrinter but I haven't checked what exactly uses it. I thought it was something like that. The AsmPrinter wouldn't need to depend on the XXXMCTargetDesc library, though. It just needs an MCInstrInfo pointer. It already has an MCRegisterInfo pointer. The regIsInRegisterClass() function also looks like it is identical to MCRegisterClass::contains(). It it even used anywhere? /jakob

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 report any errors. Timothy -- “One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of the...

...ters (and worse: references!) to unique_ptrs (apologies to people whose backbends I've broken), but I hit a big blocker when I get to Target in "llvm/Support/TargetRegistry.h". Target vends MC objects by calling registered ctor functions. E.g.: MCAsmBackend *createMCAsmBackend(const MCRegisterInfo &MRI, StringRef TheTriple, StringRef CPU, const MCTargetOptions &Options) const { if (!MCAsmBackendCtorFn) return nullptr; return MCAsmBackendCtorFn(*this, MRI, Triple(TheTriple), CPU, Options); } The callee owns the...

Hi, This is my first post to this list, so I apologize in advance if I mess up on any list etiquette. Jumping right in, I’m making use of the DebugInfo/DWARF APIs to get debugging information out of binaries (what else!). One of the bits of data I need is the location information stored in the location list section as well as inline in DW_AT_location attributes and similar. So far I’ve succeeded

Dear Tim, Thank you for your thorough reply. So, based on your reply I get every operand and check them to be (isDef && !isimplicit). Now my problem is that it gives me the physical register number.i.e, for example, instead of r0, it return %physreg66. Could you please help me on how to convert these physical register number to the ARM related register? I mean the 15 GPRs in ARM. Thank

...x-fast/build/llvm/include/llvm/Support/CommandLine.h:1233 #2 0x9d1aa4 in llvm::X86ELFMCAsmInfo::X86ELFMCAsmInfo(llvm::Triple const&) /mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/lib/Target/X86/MCTargetDesc/X86MCAsmInfo.cpp:100 #3 0x9cf3e1 in createX86MCAsmInfo(llvm::MCRegisterInfo const&, llvm::Triple const&) /mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/lib/Target/X86/MCTargetDesc/X86MCTargetDesc.cpp:179:15 #4 0x421020 in createMCAsmInfo /mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/include/llvm/Support/TargetRegistry.h:29...

...t;AArch64GenRegisterInfo.inc" > > #define GET_INSTRINFO_ENUM > #include "AArch64GenInstrInfo.inc" > > #define GET_SUBTARGETINFO_ENUM > #include "AArch64GenSubtargetInfo.inc" > > #include "llvm/MC/MCSchedule.h" > #include "llvm/MC/MCRegisterInfo.h" > #include "llvm/MC/MCInstrDesc.h" > #include "llvm/MC/MCInstrInfo.h" > #include "llvm/MC/SubtargetFeature.h" > #include "llvm/MC/MCSubtargetInfo.h" > > #define GET_INSTRINFO_MC_DESC > #include "AArch64GenInstrInfo.inc"...

...t but can you give me an example of a case where there is no "most super" register? I'm having a hard time thinking up how one would design such an ISA. Need to increase my edjimucation. > We try to track anything related to register aliasing in terms of > register units. See MCRegisterInfo.h and TargetRegisterInfo.h. I > believe regunits are equivalent to maximal cliques of the register > aliasing graph if you're mathematically inclined. Ok, I'll check that out. MCRegisterInfo.h is new to me. > I think it is easier to think about them as minimal sub-registers, &gt...

...t; Interesting. I couldn't find how to do it. It would be great if somebody helps me on this. I was thinking of APIs like MachineOperand::readsReg(). I guess if you’re only asking whether an instruction zeros the upper part of the register, that information *should* be available from MCInstr/MCRegisterInfo, but I’m not very familiar with the API. Matthias? -Andy > 1) Partial register updates versus full register updates. > > On x86-64, a 32-bit GPR write fully updates the super-register. Example: > add %edi %eax ## eax += edi > > Here, register %eax aliases the lower h...

On 9/28/2016 2:59 PM, Quentin Colombet wrote: > The cases where that it could make sense to use unaddressable register units are: > > 2. If we want to track precise liveness for physical registers > > #2 is not a problem IMO since most of our work with liveness happens on unallocated code. This is what I'm working on (RDF). I generate a data-flow graph for physical registers,

Ok, just to clarify, RegUnits, as far I understand, are Physical registers or alias to Physical registers. They exist because some instructions use physical registers directly rather than virtual register. It's right? And why this RegUnits should be present in the Interference Graph? I thought were only the Live Intervals would be the nodes of the graph. Sorry about the trouble to

...const Target *TheTarget = TargetRegistry::lookupTarget(TripleName, Error); if (!TheTarget) { std::cerr << "llvm_insts_to_binary(): " << Error; return 1; } Then, I move on to creating some of the needed ASM / REG info and an MCContext, etc.: std::unique_ptr<MCRegisterInfo> MRI(TheTarget->createMCRegInfo(TripleName)); assert(MRI && "Unable to create target register info!"); std::unique_ptr<MCAsmInfo> MAI(TheTarget->createMCAsmInfo(*MRI, TripleName)); assert(MAI && "Unable to create target asm info!"); std::st...