search for: livevariables

I though LiveVariables may be invalidated by LiveIntervals, but it's declared not: void LiveIntervals::getAnalysisUsage(AnalysisUsage &AU) const { AU.addPreserved<LiveVariables>(); AU.addRequired<LiveVariables>(); ... LiveInterval may coalesce virtual registers and remove identity moves instru...

...ree target. The problem is an over-constrained scheduling DAG. In particular, the DAG includes spurious output dependencies on physical, non-register-allocatable registers. MISched already includes code to avoid this problem. However that code relies on information clobbered by the earlier pass LiveVariables. I wonder whether this is a bug in the LiveVariables pass and would appreciate feedback. Let me expand with a small example, Suppose my target declares machine instruction type FOO that implicitly writes a condition-code register named 'F_OVERFLOW'. F_OVERFLOW is a physical register and...

I just enabled a new algorithm for computing live intervals that doesn't depend on LiveVariables. The goal is to get rid of the LiveVariables analysis completely, but unfortunately PHI elimination and the two-address pass still use LiveVariables for some optimizations. They don't require it, they work just fine without it at -O0. They use it to generate better code in some cases. The cur...

...;font-family:Arial;font-size:10.5pt" ><div dir="ltr" > </div> <div dir="ltr" >Hi all,</div> <div dir="ltr" > </div> <div dir="ltr" > </div> <div dir="ltr" >The documentation at the top of LiveVariables.cpp states the following:<br><br> "It ... assumes that physical registers are only live within a single basic block (allowing it to do a single local analysis to resolve physical register lifetimes in each basic block). If a physical register is not register allocatable, it is...

So what is the status about LiveVariables. Is there a plan to remove it? After searching in old lvm-dev-mails it is mentioned that LiveVariable still exists due to one pass needing it. And a comment in TargetPassConfig.cpp indicates that the pass in question is TwoAddressInstruction: // FIXME: Once TwoAddressInstruction pass no longer...

...egisters total, with a lot of loading and writing to stack. If I use any of the regalloc parameters (local, ...) I get an error in the LiveVariable.cpp file, in the part that I think cheaks for dead code because a Variable didn't have a defined Instance to a Machine instruction. " llc: LiveVariables.cpp:86: void llvm::LiveVariables::HandleVirtRegUse(llvm::LiveVariables::VarInfo&, llvm::MachineBasicBlock*, llvm::MachineInstr*): Assertion `VRInfo.DefInst && "Register use before def!"' failed. /home/llvm/Debug/bin/llc((anonymous namespace)::PrintStackTrace()+0x1a)[0x...

...ot of problems with NEON subregister defs, which might be fixed by your new direct LiveIntervals implementation. Cameron On Feb 8, 2013, at 3:41 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > I just enabled a new algorithm for computing live intervals that doesn't depend on LiveVariables. > > The goal is to get rid of the LiveVariables analysis completely, but unfortunately PHI elimination and the two-address pass still use LiveVariables for some optimizations. They don't require it, they work just fine without it at -O0. They use it to generate better code in some cases...

...by: > #0: J <BB#17> > > > As you can see, VarInfo vreg81 is killed by the unconditional jump instruction of BB#20 when it should be killed by the newly created conditional branch in BB#14 (BEQ). Is this a bug in updateTerminator() or is the back-end responsible for updating LiveVariables? This could be a new issue. Neither ARM nor x86 have conditional branches that take live register operands, so I don't think anyone has considered if the back-end should update LiveVariables. It simply hasn't come up before. I think the target should call LV->replaceKillInstruction()...

On Wed, 2005-09-07 at 18:24 +0800, Tzu-Chien Chiu wrote: > I though LiveVariables may be invalidated by LiveIntervals, but it's > declared not: > > void LiveIntervals::getAnalysisUsage(AnalysisUsage &AU) const > { > AU.addPreserved<LiveVariables>(); > AU.addRequired<LiveVariables>(); > ... > > LiveInterval may coalesce virtu...

Is LiveVariables updated correctly when TII->RemoveBranch and TII->InsertBranch are called in the following piece of code? - MachineBasicBlock::updateTerminator() line 307 of MachineBasicBlock.cpp: if (FBB) { // The block has a non-fallthrough conditional branch. If one of its // successors is...

Hi, In PR2193 LiveVariables runs out of memory on a 512M limit, after processing 11557 basicblocks. VirtRegInfo has ~180000 entries with ~700 bytes each. If I give it more memory (1.5G) it runs out of memory in LiveInterval. I don't see any easy solution to reduce memory usage, but should we optimize such a huge function...

In LiveVariables.cpp, when traversing the instructions, all defs of registers are initially marked as kills. See the code around the comment "Defaults to dead". Then later on, when a pass changes instructions, the LiveVariables code updates the kills lists, but it only does so for uses, not defs. See the...

On Apr 13, 2008, at 1:28 PM, Török Edwin wrote: > Hi, > > In PR2193 LiveVariables runs out of memory on a 512M limit, after > processing 11557 basicblocks. > VirtRegInfo has ~180000 entries with ~700 bytes each. > If I give it more memory (1.5G) it runs out of memory in LiveInterval. Some of the information kept by LiveVariables are somewhat redundant and can be remo...

...in instruction ....' message. What I get now is: Program received signal SIGSEGV, Segmentation fault. 0x400c24d4 in llvm::MachineInstr::getParent (this=0x0) at MachineInstr.h:408 408 MachineInstr.h: No such file or directory. in MachineInstr.h (gdb) up #1 0x40f05f28 in llvm::LiveVariables::HandleVirtRegUse ( this=0x8060270, VRInfo=@0x8061930, MBB=0x8060970, MI=0x80615d0) at ../../lib/CodeGen/LiveVariables.cpp:100 100 assert(MBB != VRInfo.DefInst->getParent() && (gdb) p VRInfo.DefInst $1 = (llvm::MachineInstr *) 0x0 (gdb) up #2 0x40f0678f in llvm::LiveVariab...

...7> > > > > > > As you can see, VarInfo vreg81 is killed by the unconditional jump > instruction of BB#20 when it should be killed by the newly created > conditional branch in BB#14 (BEQ). Is this a bug in updateTerminator() or is > the back-end responsible for updating LiveVariables? > > This could be a new issue. Neither ARM nor x86 have conditional branches > that take live register operands, so I don't think anyone has considered if > the back-end should update LiveVariables. It simply hasn't come up before. > > I think the target should call LV-&g...

Hi, I wonder when the preRASched pass is planned to be available? I wonder how one would best try to implement a pass in between RegCoalescer and RA. After RegCoalescer, the LiveVariables information seems broken (there are no Kills anywhere), and LiveVariables can't be rerun after SSA form is left. So, how could one rebuild LiveIntevals? For register allocation purposes - what would be the best way to rebuild LiveIntervals after a rescheduling that demands a rerun of SlotIndexe...

...al edge splitting for now. > > That doesn't exist yet, we'll need that too. > > My thinking was to keep a list of all global live ranges in LiveIntervals so we at least don't have to go through all the local virtual registers when splitting a critical edge. (That's how LiveVariables is updated now, and it's slow). I checked in LiveIntervals support to PHIElimination in r174831. I encountered all of the usual edge cases in 'make check', so hopefully it has no latent bugs. I'll add a splitEdge() method to LiveIntervalAnalysis (got a better name?) that does thin...

...5:30PM -0700, John Cortes wrote: > If I use any of the regalloc parameters (local, ...) I get an error in > the LiveVariable.cpp file, in the part that I think cheaks for dead > code because a Variable didn't have a defined Instance to a Machine > instruction. > > " llc: LiveVariables.cpp:86: void > llvm::LiveVariables::HandleVirtRegUse(llvm::LiveVariables::VarInfo&, > llvm::MachineBasicBlock*, llvm::MachineInstr*): Assertion > `VRInfo.DefInst && "Register use before def!"' failed. This is a bug in your instruction selector and the assertion i...

Török Edwin wrote: > Evan Cheng wrote: > >> On Apr 13, 2008, at 1:28 PM, Török Edwin wrote: >> >> >> >>> Hi, >>> >>> In PR2193 LiveVariables runs out of memory on a 512M limit, after >>> processing 11557 basicblocks. >>> VirtRegInfo has ~180000 entries with ~700 bytes each. >>> If I give it more memory (1.5G) it runs out of memory in LiveInterval. >>> >>> >> Some of the info...

Evan Cheng wrote: > On Apr 13, 2008, at 1:28 PM, Török Edwin wrote: > > >> Hi, >> >> In PR2193 LiveVariables runs out of memory on a 512M limit, after >> processing 11557 basicblocks. >> VirtRegInfo has ~180000 entries with ~700 bytes each. >> If I give it more memory (1.5G) it runs out of memory in LiveInterval. >> > > Some of the information kept by LiveVariables are s...