search for: machineregisterinfo

...t? Thanks, Tom ________________________________________ From: llvm-commits-bounces at cs.uiuc.edu [llvm-commits-bounces at cs.uiuc.edu] on behalf of Tom Stellard [thomas.stellard at amd.com] Sent: Friday, February 03, 2012 1:55 PM To: llvm-commits at cs.uiuc.edu Subject: Re: [llvm-commits] [PATCH] MachineRegisterInfo: Don't emit the same livein copy more than once On Fri, Jan 27, 2012 at 02:56:03PM -0500, Tom Stellard wrote: > --- > > Is MachineRegisterInfo::EmitLiveInCopies() only meant to be called once > per compile? If I call it more than once, it emits duplicate copies > which causes t...

...______ > > From: llvm-commits-bounces at cs.uiuc.edu [llvm-commits-bounces at cs.uiuc.edu] > > on behalf of Tom Stellard [thomas.stellard at amd.com] > > Sent: Friday, February 03, 2012 1:55 PM > > To: llvm-commits at cs.uiuc.edu > > Subject: Re: [llvm-commits] [PATCH] MachineRegisterInfo: Don't emit the > > same livein copy more than once > > > > On Fri, Jan 27, 2012 at 02:56:03PM -0500, Tom Stellard wrote: > > > --- > > > > > > Is MachineRegisterInfo::EmitLiveInCopies() only meant to be called once > > > per compile? If I...

..._______________________________ > From: llvm-commits-bounces at cs.uiuc.edu [llvm-commits-bounces at cs.uiuc.edu] > on behalf of Tom Stellard [thomas.stellard at amd.com] > Sent: Friday, February 03, 2012 1:55 PM > To: llvm-commits at cs.uiuc.edu > Subject: Re: [llvm-commits] [PATCH] MachineRegisterInfo: Don't emit the > same livein copy more than once > > On Fri, Jan 27, 2012 at 02:56:03PM -0500, Tom Stellard wrote: > > --- > > > > Is MachineRegisterInfo::EmitLiveInCopies() only meant to be called once > > per compile? If I call it more than once, it emits du...

...m-commits-bounces at cs.uiuc.edu [ > llvm-commits-bounces at cs.uiuc.edu] > > > on behalf of Tom Stellard [thomas.stellard at amd.com] > > > Sent: Friday, February 03, 2012 1:55 PM > > > To: llvm-commits at cs.uiuc.edu > > > Subject: Re: [llvm-commits] [PATCH] MachineRegisterInfo: Don't emit the > > > same livein copy more than once > > > > > > On Fri, Jan 27, 2012 at 02:56:03PM -0500, Tom Stellard wrote: > > > > --- > > > > > > > > Is MachineRegisterInfo::EmitLiveInCopies() only meant to be called > once...

Hi All, I have tried to build llvm tip as following: cmake -DCMAKE_CXX_FLAGS:STRING="-DLLVM_ENABLE_DUMP" -DCMAKE_BUILD_TYPE=RelWithDebInfo ../llvm After running 'make', I have got error messages like below. llvm/lib/CodeGen/MachineRegisterInfo.cpp:462:67: error: no ‘void llvm::MachineRegisterInfo::dumpUses(unsigned int) const’ member function declared in class ‘llvm::MachineRegisterInfo’ llvm/lib/CodeGen/MachineScheduler.cpp:2331:57: error: no ‘void llvm::SchedBoundary::dumpScheduledState()’ member function declared in class ‘llvm::...

...got around adding a flag. (this really should be fixed). > > In the meantime `cmake -DCMAKE_CXX_FLAGS="-DLLVM_ENABLE_DUMP"` should do the trick. Thank you. That was the flag we needed. Unfortunately, when I tried this just now, I found that the declaration of llvm::MachineRegisterInfo::dumpUses() in include/llvm/CodeGen/MachineRegisterInfo.h is missing the check against LLVM_ENABLE_DUMP. It has only #ifndef NDEBUG which causes the build to fail because the definition in lib/CodeGen/MachineRegisterInfo.cpp is guarded by this. #if !defined(NDEBUG) || defined(LLVM_ENABLE_DUM...

Hi, I wanted to see the non-debug uses of register 0 (Noreg) and so, I wrote the following piece of code. ***** MRI = &MF.getRegInfo(); if (!MRI->use_nodbg_empty(0)) { for (MachineRegisterInfo::use_nodbg_iterator ri = MRI->use_nodbg_begin(0), re = MRI->use_nodbg_end(); ri != re; ++ri) { MachineInstr *UseMI = &*ri; UseMI->dump (); } } ***** But I see that UseMI is DBG_VALUE %noreg, 0, !"foobar"; line no:511 inlined @[ foo...

...B#4 BB#1 BB#6 688B %P15<def> = COPY %vreg27<kill>; IntRegs:%vreg27 dbg:../src/getbits.c:60:1 704B RET pred:%noreg, %RT<imp-use>, %P15<imp-use,kill>; dbg:../src/getbits.c:60:1 # End machine code for function CGA_kernel_read. llc: /work/llvm/trunk/llvm/include/llvm/CodeGen/MachineRegisterInfo.h:76: static llvm::MachineOperand* llvm::MachineRegisterInfo::getNextOperandForReg(const llvm::MachineOperand*): Assertion `MO && MO->isReg() && "This is not a register operand!"' failed. Program received signal SIGABRT, Aborted. 0xb7fdd424 in __kernel_vsyscall ()...

...raun via llvm-dev wrote: >> In the meantime `cmake -DCMAKE_CXX_FLAGS="-DLLVM_ENABLE_DUMP"` should >> do the trick. > > Thank you. That was the flag we needed. > > Unfortunately, when I tried this just now, I found that the > declaration of llvm::MachineRegisterInfo::dumpUses() in > include/llvm/CodeGen/MachineRegisterInfo.h is missing the check against > LLVM_ENABLE_DUMP. It has only > > #ifndef NDEBUG > > which causes the build to fail because the definition in > lib/CodeGen/MachineRegisterInfo.cpp is guarded by this. > > #i...

...t it's certainly >> necessary information in some cases. Is this expected behavior, or an >> oversight? reg iterators will return everything that is in the function. If the implicit operands haven't been added to the machieninstrs yet, then they won't be returned. > MachineRegisterInfo tracks virtual register only. It works for vregs and pregs today. > I also wish it would track physical register defs and uses as well. It > can be used to simplify a lot of code (in livevariable, etc.). Chris, > do you think that's feasible? Really really feasible :) -Chris -- h...

...:53 PM, Matthias Braun via llvm-dev wrote: >>> In the meantime `cmake -DCMAKE_CXX_FLAGS="-DLLVM_ENABLE_DUMP"` should do the trick. >> Thank you. That was the flag we needed. >> Unfortunately, when I tried this just now, I found that the declaration of llvm::MachineRegisterInfo::dumpUses() in include/llvm/CodeGen/MachineRegisterInfo.h is missing the check against LLVM_ENABLE_DUMP. It has only >> #ifndef NDEBUG >> which causes the build to fail because the definition in lib/CodeGen/MachineRegisterInfo.cpp is guarded by this. >> #if !defined(NDEBUG) || de...

...tion? > > > Yes, the use_iterator list is not constructed in the same order as the > machine function. > > Maybe from the order that DAG is constructed? > > > No, this is not the case either. > The list is constructed via calls to MachineInstr::setReg (which calls > MachineRegisterInfo::addRegOperandToUseList if you are interested by the > details), which could basically occur anywhere in the backend. > That said, the main users of this interface is the VirtRegMap pass, which > walks through the function and set the register along the way. Therefore, > most of the use...

Hi folks, I would like to find out the machine instructions that use some given registers in the reverse order, and I came across these iterators (use_iterator/reg_iterator). However, there are two things I noticed: 1) These iterators seem to traverse the machine function a bit differently from what I get from the machine function dump. In other words, the use_iterator list is not constructed in

...ter remat. What strikes me here is that it never mentions the instruction 5056B %vreg1954:lo16<def> = mv_nimm6_ar16 0 where we do have a read of vreg1954:hi16 since there is no read-undef on the def operand. Is this how it's intended to be? (The use points are found by for (MachineRegisterInfo::use_bundle_nodbg_iterator RI = MRI.use_bundle_nodbg_begin(Reg), E = MRI.use_bundle_nodbg_end(); RI != E; ) { anyRemat |= reMaterializeFor(LI, MI); } and MachineRegisterInfo::defusechain_instr_iterator::advance seems to skip all def operands for use_bundle_nodb...

Hi Susan, Thanks for the clarification, and the test case. I think I know what the problem is now. Saving and restoring RBP is the job of the PEI (PrologEpilogInsertion) pass, which runs after register allocation. To determine which callee-saved physregs actually need to be saved it checks MachineRegisterInfo::isPhysRegOrOverlapUsed(unsigned reg). Your register allocator needs to notify MachineRegisterInfo about the physical registers that have been assigned by calling MachineRegisterInfo::setPhysRegUsed(unsigned reg). You only need to call setPhysRegUsed for the physregs that you actually use. You do...

Hi, I am experimenting with creating instructions that write into virtual registers that use the ARM GPRPair register class in Pre-RA phase. During register allocation, I hit an assertion because the code is not in SSA form: lib/CodeGen/MachineRegisterInfo.cpp:271: llvm::MachineInstr* llvm::MachineRegisterInfo::getVRegDef(unsigned int) const: Assertion `(I.atEnd() || llvm::next(I) == def_end()) && "getVRegDef assumes a single definition or no definition"' failed. The code in lib\CodeGen\MachineRegisterInfo.cpp has informatio...

...h JUMP <BB#4>, pred:%p387 inserted in step 3). That is when things go wrong and I get the following assertion (with GDB) backtrace. (Please note that my RemoveBranch code is nothing special, it looks exactly the same as the code in the Mips backend. ) llc: /work/llvm/trunk/llvm/lib/CodeGen/MachineRegisterInfo.cpp:162: void llvm::MachineRegisterInfo::removeRegOperandFromUseList(llvm::MachineOperand*): Assertion `NextOp->getReg() == MO->getReg() && "Corrupt reg use/def chain!"' failed. Program received signal SIGABRT, Aborted. 0xb7fdd424 in __kernel_vsyscall () (gdb) bt #0 0x...

...a llvm-dev wrote: > >>> In the meantime `cmake -DCMAKE_CXX_FLAGS="-DLLVM_ENABLE_DUMP"` should > do the trick. > >> Thank you. That was the flag we needed. > >> Unfortunately, when I tried this just now, I found that the > declaration of llvm::MachineRegisterInfo::dumpUses() in > include/llvm/CodeGen/MachineRegisterInfo.h is missing the check against > LLVM_ENABLE_DUMP. It has only > >> #ifndef NDEBUG > >> which causes the build to fail because the definition in lib/CodeGen/MachineRegisterInfo.cpp > is guarded by this. > >&...

...mple. Simple register-to-register copies are completely missed. So far I've only discovered this to be the case for physical registers, though that doesn't mean virtual register information isn't also out of date. Who constructs this information? I don't see any interfaces in MachineRegisterInfo to keep the information up to date as instructions are added or deleted. Do I need to depend on some Pass? What does coalescing do with this information? Does it update it as intervals are merged and instructions are changed? I thought MachineRegisterInfo::replaceRegWith might handle this but...

...in some cases. Is this expected behavior, >>> or an >>> oversight? > > reg iterators will return everything that is in the function. If the > implicit operands haven't been added to the machieninstrs yet, then > they > won't be returned. > >> MachineRegisterInfo tracks virtual register only. > > It works for vregs and pregs today. Ok! Fooled me with this comment: /// MachineRegisterInfo - Keep track of information for each virtual register, /// including its register class. Evan > > >> I also wish it would track physical register de...