similar to: [LLVMdev] LiveIntervals invalidates LiveVariables?

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 virtual registers and

On 08/09/05, Alkis Evlogimenos <evlogimenos at gmail.com> wrote: > to those coalesced registers, it is logical that noone will ever query > the liveness of those registers (unless there is a bug somewhere in the Indeed the coalesced registers may logically not be queried since they do not appear in any operand list of the machine code, but the VarInfo::DefInst in VirtRegInfo of the

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 its layout successor, rewrite it to a fallthrough // conditional branch.

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 at once? If the function is over some reasonable limit (5k

On Tue, 20 Sep 2005, Tzu-Chien Chiu wrote: > One of my pass requires LiveIntervals to build the interference graph, Ok. > because LiveVariables do not provide an interface to iterate through > all viritual registers. Ok, you could add a method to LiveVariables that returns VirtRegInfo.size(). The virtual registers are defined by the range: [MRegisterInfo::FirstVirtualRegister,

One of my pass requires LiveIntervals to build the interference graph, because LiveVariables do not provide an interface to iterate through all viritual registers. But LiveIntervalAnalysis.h is not in "include/llvm/CodeGen", so I have to either include it by: #include "../../llvm/lib/CodeGen/LiveIntervalAnalysis.h" or point my project include path to

On May 2, 2011, at 3:51 PM, Akira Hatanaka wrote: > - vreg81's VarInfo: > Alive in blocks: 5, 6, 7, 8, 10, 12, 13, 19, > Killed 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

On 20/09/05, Chris Lattner <sabre at nondot.org> wrote: > > because LiveVariables do not provide an interface to iterate through > > all viritual registers. > > Ok, you could add a method to LiveVariables that returns > VirtRegInfo.size(). The virtual registers are defined by the range: > [MRegisterInfo::FirstVirtualRegister, >

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 removed. I

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

Ok, i'm having a problem with understanding the allocating of registers. I've written in the "addPassesToEmitAssembly()" the passes to create the assembly code, as in the PowerPC example. I'ved tried filling up as much of the code in <Target>RegisterInfo.cpp (Register/Frame code) to handle writing and reading from stack. The allocation method I used was

On Mon, May 16, 2005 at 05:15: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 >

On Tue, 20 Sep 2005, Tzu-Chien Chiu wrote: > On 20/09/05, Chris Lattner <sabre at nondot.org> wrote: >>> because LiveVariables do not provide an interface to iterate through >>> all viritual registers. >> >> Ok, you could add a method to LiveVariables that returns >> VirtRegInfo.size(). The virtual registers are defined by the range: >>

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

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

I am observing poor instruction scheduling in my out-of-tree 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

Does updateTerminator() need to be rewritten in order to implement the changes you suggested (call LV->replaceKillInstruction)? Or can it be taken care of just by adding code to the files in Target/Mips? Also, is the generated code still correct if -disable-phi-elim-edge-splitting is added to the command line options? On Mon, May 2, 2011 at 5:00 PM, Jakob Stoklund Olesen <stoklund at

Is there any way to discover whether a particular operand of a MachineInst participates in addressing? That is, if the MachineInst references memory, can I tell, given an operand, whether that operand is part of the address calculation for the instruction? Also, is there any reasonable way to get the set of machine instructions to which the output(s) of some machine instruction flows? The

<div class="socmaildefaultfont" dir="ltr" style="font-family:Arial;font-size:10.5pt" ><div class="socmaildefaultfont" dir="ltr" style="font-family:Arial;font-size:10.5pt" ><div dir="ltr" > </div> <div dir="ltr" >Hi all,</div> <div dir="ltr" > </div> <div

For adding the nop: TII->insertNoop(*BB, BB->end()); 2007/8/9, Chris Lattner <sabre at nondot.org>: > > On Thu, 9 Aug 2007, [ISO-8859-1] Emílio Wuerges wrote: > > I too believe it should not be complicated. > > But I was not being able to do it. > > Finally, after some thinking (and tinkering), this worked like a charm: > > > > MachineInstr* mi =