similar to: [LLVMdev] LiveVariables/LiveInterval on huge functions

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

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 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 instructions: bool LiveIntervals::runOnMachineFunction(MachineFunction &fn) {

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 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,

On Feb 8, 2013, at 4:37 PM, Cameron Zwarich <zwarich at apple.com> wrote: > On Feb 8, 2013, at 4:20 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > >> On Feb 8, 2013, at 4:03 PM, Cameron Zwarich <zwarich at apple.com> wrote: >> >>> How much of the work is done here? I'd be happy to do the phi elimination part, since I basically did that

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

On Jan 4, 2014, at 4:38 AM, Haishan <hndxvon at 163.com> wrote: > At 2014-01-04 06:11:38,"Jakob Stoklund Olesen" <stoklund at 2pi.dk> wrote: > > On Jan 3, 2014, at 1:52 PM, Andrew Trick <atrick at apple.com> wrote: > >> He really just wants to rerun LiveIntervals analysis, but LiveVariables is no longer available. Would it work just to clear all

On Feb 8, 2013, at 4:03 PM, Cameron Zwarich <zwarich at apple.com> wrote: > How much of the work is done here? I'd be happy to do the phi elimination part, since I basically did that for StrongPhiElimination (RIP). Any help would be appreciated. I did a bit of the easy stuff in 2-addr, it has a LIS = getAnalysisIfAvailable<LiveIntervals>() member that it sometimes updates. It

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 Feb 8, 2013, at 4:20 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > On Feb 8, 2013, at 4:03 PM, Cameron Zwarich <zwarich at apple.com> wrote: > >> How much of the work is done here? I'd be happy to do the phi elimination part, since I basically did that for StrongPhiElimination (RIP). > > Any help would be appreciated. > > I did a bit of the

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 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

On Feb 8, 2013, at 4:45 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > On Feb 8, 2013, at 4:37 PM, Cameron Zwarich <zwarich at apple.com> wrote: > >> I'll try doing that. Did you ever add a way to update LiveIntervals quickly after splitting an edge or will that have to finally be added? I can skip the critical edge splitting for now. > > That

On Mon, 14 Apr 2008, Evan Cheng wrote: >> This sounds like unanticipated fallout from Evan's recent tweaks of the >> inliner. Evan, thoughts? > > Previously the inliner assign each basic block cost of 20. So this line is > simply estimating the number of caller basic blocks. My tweak simply removed > the number of basic blocks from the equation so the cost of a

Evan Cheng wrote: > On Apr 14, 2008, at 10:43 AM, Chris Lattner wrote: > > >> On Mon, 14 Apr 2008, [ISO-8859-1] Török Edwin wrote: >> >>>> Another question to ask, is why that function became so large in the >>>> first place [X86DAGToDAGISel::SelectCode(llvm::SDOperand)] >>>> We have inline limits, don't we? >>>>

On Apr 14, 2008, at 10:43 AM, Chris Lattner wrote: > On Mon, 14 Apr 2008, [ISO-8859-1] Török Edwin wrote: >>> Another question to ask, is why that function became so large in the >>> first place [X86DAGToDAGISel::SelectCode(llvm::SDOperand)] >>> We have inline limits, don't we? >> >> most of functions called by SelectCode get a -30000 cost reduction

<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

On Mon, 14 Apr 2008, [ISO-8859-1] Török Edwin wrote: >> Another question to ask, is why that function became so large in the >> first place [X86DAGToDAGISel::SelectCode(llvm::SDOperand)] >> We have inline limits, don't we? > > most of functions called by SelectCode get a -30000 cost reduction > because they are internal. > Even if Caller.size() is 40000, the