similar to: [LLVMdev] Reusing stacks slots for function arguments

Ok, I've been tracking down a remat bug for over a week. I think I finally understand what is going on. This happens in specfp2006 leslie3d compiled with our frontend and optimizer. Unfortunately, getting a testcase is going to be impossible due to restrictions on SPEC redistribution and the complexity of the sequence of events leading to the bug. The bug is extremely subtle and nasty.

Hi, Sorry for the delay. I was trying to wrap my head around some live interval analysis code and have forgotten about emails. :-) On Aug 6, 2007, at 9:20 AM, David Greene wrote: > Can someone explain the theory behind the spillers in VirtRegMap.cpp? > > It seems as though the spillers do triple duty: > > - Insert load/store operations and/or fold instructions as >

On Monday 13 July 2009 15:58, David Greene wrote: > Again, after answering the FI stack slot question, the IR-level instruction > information is the only thing we can't do through asmprinter. I'm open to > other ways of capturing the information that don't require comments in > MachineInstrs. But the information has to be stored somewhere. Ugh. I just found another

Hi, While investigating a performance issue with an internal codebase I came across what looks to be poor register allocation. I have constructed a small(ish) reproducible which demonstrates the issue (see test.ll attached). I have spent some time going through the register allocator to understand what is happening. I have also experimented with some small changes to try and improve the

Hello LLVMers! I recently added a generic machine rewriter/spiller that global register allocator writers may find useful. The API provided is the free function: void eliminateVirtRegs(MachineFunction&, const VirtRegMap&) declared in lib/CodeGen/VirtRegMap.h and implemented in lib/CodeGen/VirtRegMap.cpp. This function rewrites the machine code of MachineFunction to eliminate

I will be removing RegAllocLinearScan and VirtRegRewriter from trunk shortly after we cut the 3.0 release branch. LLVM 3.0 will still ship with the linear scan register allocator, but the default will be the new greedy allocator. Linear scan can be enabled by passing '-regalloc=linearscan -join-physregs' to llc. RegAllocLinearScan and VirtRegRewriter need to go away soon because they

On Tuesday 07 August 2007 05:00, Anton Vayvod wrote: > > Yes, that's true. But I wonder if we shouldn't be smarter about which > > register we pick to color it. In Bill W's implementation, it was > > essentially random. What was your solution to this? > > I allocated spill intervals at the beginning of each iteration so all the > rest intervals (except of

Can someone explain the theory behind the spillers in VirtRegMap.cpp? It seems as though the spillers do triple duty: - Insert load/store operations and/or fold instructions as necessary to carry out spills - Rewrite the spilled virtual registers to use machine registers (mapping given by the caller in the VRM). - Rewrite machine code to change virtual registers to physical registers

On 8/7/07, David Greene <dag at cray.com> wrote: > > On Monday 06 August 2007 12:15, Anton Vayvod wrote: > > > Spill intervals must be precolored because they can't be spilled once > more. > > They are the shortest intervals precisely over each def/use of the > original > > interval. That is why they also have their weights set to #INF. > > Yes,

On Jul 11, 2011, at 1:48 PM, Nick Lewycky wrote: > I discovered recently that RegAllocFast spills all the registers before every function call. This is the root cause of one of our recursive functions that takes about 150 bytes of stack when built with gcc (same at -O0 and -O2, or 120 bytes at llc -O2) taking 960 bytes of stack when built by llc -O0. That's pretty bad for situations where

On Jan 23, 2008, at 2:40 PM, David Greene <dag at cray.com> wrote: > On Wednesday 23 January 2008 02:01, Evan Cheng wrote: >> On Jan 22, 2008, at 12:23 PM, David Greene wrote: >>> Evan, >>> >>> Can you explain the basic mechanics of the live interval splitting >>> code? >>> Is it all in LiveIntervalAnalysis.cpp under

On Aug 15, 2010, at 5:12 PM, Silvio Ricardo Cordeiro wrote: > Is there a way for me to collect statistics about the number of loads/stores added by the "linearscan" register allocator (just like can be done with the "local" allocator)? I still haven't grokked very well the interaction between RALinScan and Spiller... Should I add those two statistics to the

Hi Ahmed, If you access your values with sub-registers indices, IIRC the inline spiller will spill the super register. If you access your values directly (via sub-regclass), then the spiller uses this class. Basically what I am saying is the spiller spills the value that contains the accesses. E.g., = v; will spill v = v.sub1; will spill v too, but v is a super register in that case. Cheers,

I just got a Diffusion notification about a change of mine being reverted by Fangrui, but I'm not sure that's actually what happened and am confused and concerned. My commit was "[DebugInfo] Allow spill slots in call site parameter descriptions", and it appears in the history under two hashes: 1ee84e and 67c416. The first commit contains the actual change. The second touches

On Monday 06 August 2007 12:15, Anton Vayvod wrote: > Spill intervals must be precolored because they can't be spilled once more. > They are the shortest intervals precisely over each def/use of the original > interval. That is why they also have their weights set to #INF. Yes, that's true. But I wonder if we shouldn't be smarter about which register we pick to color it.

On Mon, Jul 11, 2011 at 2:44 PM, Eric Christopher <echristo at apple.com> wrote: > > On Jul 11, 2011, at 1:48 PM, Nick Lewycky wrote: > >> I discovered recently that RegAllocFast spills all the registers before every function call. This is the root cause of one of our recursive functions that takes about 150 bytes of stack when built with gcc (same at -O0 and -O2, or 120 bytes

On Sun, Aug 15, 2010 at 10:04 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk>wrote: > > On Aug 15, 2010, at 5:12 PM, Silvio Ricardo Cordeiro wrote: > > > Is there a way for me to collect statistics about the number of > loads/stores added by the "linearscan" register allocator (just like can be > done with the "local" allocator)? I still haven't

I discovered recently that RegAllocFast spills all the registers before every function call. This is the root cause of one of our recursive functions that takes about 150 bytes of stack when built with gcc (same at -O0 and -O2, or 120 bytes at llc -O2) taking 960 bytes of stack when built by llc -O0. That's pretty bad for situations where you have small stacks, which is not uncommon for

Fernando Magno Quintao Pereira wrote: >> I'm not sure about one thing: you assign stack slot to each new register you >> replace the spilled one with. And then you need to allocate physical >> registers to them. Is it possible to assign physical register to the virtual >> one which has a stack slot already? >> > > Yes. The stack slot is the place where the

Hi Fernando, --- Fernando Magno Quintao Pereira <fernando at cs.ucla.edu> wrote: > > Hi, Roman, > > maybe I can try to answer this. I think that all boils down to > having register to reload spilled values. Ok. That I can follow. > Once a register is spilled, its live range is split into smaller > pieces. These pieces most be contained into registers, and