search for: livephysreg

...efactored the code into a minimal (noinline) function that still triggers the problem. xfunc2() and xfunc3() are also noinline. The problem goes away if either isReg() or isDef() is marked noinline. void xfuncx(const MachineOperand &MO, const TargetRegisterInfo *TRI, BitVector &LivePhysRegs) { if (MO.isReg() && // <<<<------ problem reported here MO.isDef()) { xfunc2(MO, TRI, LivePhysRegs); } else { xfunc3(MO, LivePhysRegs); } } The asm is below. Maybe I've been staring too long but I don't see the problem Valgrind is talking...

...= TRI->getAllocatableSet(MF); (In my case all registers defined in RegisterInfo.td) This function loops through all registers classes and sets all registers in the bitset that are allocatable. It then inverts the registers that are set to get the NonAllocatable registers and assigns that to the LivePhysRegs for each basic block in a function. The function then loops through all instructions in a basic block and checks to see if it is a dead instruction. The check is whether it is a physical register or not with the check: TargetRegisterInfo::isPhysicalRegister(reg) ? LivePhysRegs[Reg] : !MRI->use...

...h as cmp, add, etc.) is always in the same basic block? Is it true that APSR is never assumed to live across basic block boundaries? Thank you! Ming Zhang >On Aug 2, 2017, at 9:07 AM, Matthias Braun via llvm-dev llvm-dev at lists.llvm.org llvm-dev at lists.llvm.org>> wrote: >Yes LivePhysRegs can do that for you. It has addLiveIns() and addLiveOuts() functions to get the live-in or live-out set for a basic block (make the set is empty when you call these functions). >Yes APSR is marked as a reserved register by the ARM target, this means we do not track liveness for it. >- Matt...

...t >> still triggers the problem. xfunc2() and xfunc3() are also noinline. >> The problem goes away if either isReg() or isDef() is marked noinline. >> >> void xfuncx(const MachineOperand &MO, >> const TargetRegisterInfo *TRI, >> BitVector &LivePhysRegs) { >> if (MO.isReg() && // <<<<------ problem reported here >> MO.isDef()) { >> xfunc2(MO, TRI, LivePhysRegs); >> } else { >> xfunc3(MO, LivePhysRegs); >> } >> } >> >> The asm is below. Maybe I've...

...getAllocatableSet(MF); (In my case all registers defined in RegisterInfo.td) > > This function loops through all registers classes and sets all registers in the bitset that are allocatable. It then inverts the registers that are set to get the NonAllocatable registers and assigns that to the LivePhysRegs for each basic block in a function. The function then loops through all instructions in a basic block and checks to see if it is a dead instruction. The check is whether it is a physical register or not with the check: > > TargetRegisterInfo::isPhysicalRegister(reg) ? LivePhysRegs[Reg] : !...

Dale, Yeah that is correct, so that isn't the problem, not sure why I was thinking it is. The !MRI->use_no_dbg_empty(Reg) seems to be correct and the problem is LivePhysRegs[Reg] always returning false. I've looked into this more and there is a part where I'm working with physical registers. If there is a function call, there is a copy from virtual register space to the functions that are expected to be passed into the register. So it looks something like this...

...:28 PM To: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Default behavior of DeadMachineInstructionElim deletes all instructions Dale, Yeah that is correct, so that isn't the problem, not sure why I was thinking it is. The !MRI->use_no_dbg_empty(Reg) seems to be correct and the problem is LivePhysRegs[Reg] always returning false. I've looked into this more and there is a part where I'm working with physical registers. If there is a function call, there is a copy from virtual register space to the functions that are expected to be passed into the register. So it looks something like this...

...lable. Isn't it? Or are you interested in whether a physical register is unused in the entire function? On Sat, Jan 21, 2017 at 10:21 AM, Hong Hu <huhong789 at gmail.com> wrote: > Hi Nemanja and Matthias, > > Thanks for the reply. > > I checked both Register Scavenger and LivePhysReg. It seems that both work > on the BasicBlock level, right? > > Is it possible to perform such analysis in a whole function? For example, > considering the calling convention (where the rsi, rdi will be in use from > the beginning) and the return convention (where rax will be in use i...

...ould like to go with, but so > far in my very limited testing it seems to be ok and at least things don't > crash. What do you guys think? > > > The %RIP problem is a straightforward bug resulting from the X86 target > lying to LLVM about RIP being a register. The fix is that LivePhysRegs > should not track reserved regs. But before fixing that, we have to be > careful about which registers stackmap clients are expected to preserve "no > matter what", and the rest of the LLVM reserved regs (e.g. base pointer) > should just be unconditionally added to the live...

Hi all, I've run into a couple bugs recently that affected stackmap liveness analysis in various ways: http://llvm.org/bugs/show_bug.cgi?id=19224 - function arguments stay live unnecessarily http://llvm.org/bugs/show_bug.cgi?id=21265 - eflags can end up as a live out http://llvm.org/bugs/show_bug.cgi?id=21266 - %rip can end up as a live out The first two have nothing to do with stackmaps

There is also the LivePhysReg facility that I would recomment if you just want to query for a free register and do not need the full feature set of the RegisterScavenger. - Matthias > On Jan 19, 2017, at 5:50 AM, Nemanja Ivanovic via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I believe what you're af...

...dropped after regalloc. > Therefore the short answer is no, this information is not available before producing assembly. > > However, we have the live-ins and you can request the kill flag to be set. From both this information, you can recompute the liveness. > I’d suggest you use the LivePhysReg helper class and use its result to annotate your assembly (emitComment or something along those lines). > > Cheers, > -Quentin >> On Feb 16, 2017, at 12:46 PM, Anitha B Gollamudi via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >&gt...

Where is the liveness analysis pass? I have been looking for days but cannot find anything. I just want to know transfer variables in and out of basic blocks, that are calculated using simple data flow equations. Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180920/529bce15/attachment.html>

Hi, Is there a way to print the register liveness information into the assembly file or as some intermediate listing? To be more precise, I am looking at figuring out the following information in an assembly file/listing. Say, for simplicity, our register set is only { rsp, rbp, eax } subq $16, %rsp // rsp is killed here, eax and rbp are live movl $0, -4(%rbp) // rbp is killed here,

Hi, I'm a bit unsure of the semantics of undef physical registers. The explanations I've seen in the code and in the langref seems to pertain more to constant values and virtual registers. What I really want to achieve is a push-pop of a register to have a temporary to work with, without having to check if this register is defined or not. However, whenever the reg is not defined before

...rograms that uses library function ( for a library function register allocation is not done by LLVM so this optimization will simply skip them) Study and Other: ============= I have learned following things in LLVM, how it stores reg clobbering information? how it is used by Reg allocators through LivePhysRegs, LiveRegMatrix and other related passes? How to schedule a pass using TargetPassConfig and TargetMachine? What are called callee saved registers? What is an Immutable Pass? Apart from that I have also learned how to use phabricator to send review request. I have also read some related literatures....

...; Assuming you talk about the machine representation: > - The register allocators use the LiveIntervals analysis (there is also > LiveVariables but that is deprecated, please don't use it). > - When register allocation is done we keep the block live-in lists around > and you can use LivePhysReg or LiveRegUnits to recompute the liveness > information in the middle of a basic block when necessary. > - The RDF framework in lib/Target/Hexagon performs a dataflow analysis > post-regalloc to determine values in physical registers. > > - Matthias > > > On Sep 20, 2018,...

Hi All, Given a machine instruction, is it possible to tell which register(s) is still not in use? For example, given one instruction A, if the one follows it (say B) defines register rax, then I can tell rax should spare at instruction A. The purpose is to use the spare register to replace registers used by A, for instrumentation purpose. Regards, Hu Hong -------------- next part

Hi, It has been discovered recently that it is needed for the SystemZ backend to add super-regs to the callee saved regs list like: def CSR_SystemZ : CalleeSavedRegs<(add (sequence "R%dD", 6, 15), - (sequence "F%dD", 8, 15))>; + [R6Q, R8Q, R10Q, R12Q, R14Q], +

...t;> register allocation is not done by LLVM so this optimization will simply >> skip them) >> >> Study and Other: >> ============= >> I have learned following things in LLVM, how it stores reg clobbering >> information? how it is used by Reg allocators through LivePhysRegs, >> LiveRegMatrix and other related passes? How to schedule a pass using >> TargetPassConfig and TargetMachine? What are called callee saved registers? >> What is an Immutable Pass? Apart from that I have also learned how to use >> phabricator to send review request. I have...