similar to: [LLVMdev] MergeInClobberRanges

Funny I just ran into a situation where the imprecise information inhibits a coalescing. If you have made changes related to this, I'd love to have it. Thanks, Evan On Apr 7, 2008, at 10:52 AM, Evan Cheng wrote: > > On Apr 2, 2008, at 5:09 PM, David Greene wrote: > >> Why does LiveInterval::MergeInClobberRanges set the definition index >> as unknown? Why would the

On Apr 2, 2008, at 5:09 PM, David Greene wrote: > Why does LiveInterval::MergeInClobberRanges set the definition index > as unknown? Why would the definition index not be the definition > index > for the range merged in from the other interval? I suppose if two > ranges > overlap it's not clear what to set the def index to. Perhaps it > should result > in two

On Feb 20, 2008, at 7:36 PM, David A. Greene wrote: > On Wednesday 20 February 2008 07:00:28 pm Evan Cheng wrote: > >>> In other words, after coalescing, should it be the case that >>> subregister >>> intervals contain at least all of the range information that was >>> contained >>> in any eliminated intervals when those eliminated intervals were

On Wednesday 20 February 2008 07:00:28 pm Evan Cheng wrote: > > In other words, after coalescing, should it be the case that > > subregister > > intervals contain at least all of the range information that was > > contained > > in any eliminated intervals when those eliminated intervals were > > coalesced > > to the subregister's superregister? >

On Feb 20, 2008, at 12:25 PM, David Greene wrote: > On Wednesday 20 February 2008 14:14, David Greene wrote: > >> I discovered this through an assert I put into some of my own >> code. I want >> to know if that assert is bogus or if there's a bug here. > > A little more information: the assert checks that after coalescing > two nodes, > all subregister

On Thursday 17 January 2008 13:03, Evan Cheng wrote: > > So why does the live range extend throughout the entire basic block? > > > > %reg1055 doesn't appear anywhere else in the program so it shouldn't > > be > > live-in to the block. > > It could be a bug. Can you get me a test case? I'll see if I can whittle it down. It's a pretty huge

I had been assuming that give a LiveRange a, a.valno->def, if valid, would be the same as a.start. But this is apparently not always the case. For example: Predecessors according to CFG: 0x839d130 (#3) 0x8462780 (#35) 308 %reg1051 = MOV64rr %reg1227<kill> 312 %reg1052 = MOV64rr %reg1228<kill> 316 %reg1053 = MOV64rr %reg1229<kill> 320 %reg1054 = MOV64rr

On Jan 16, 2008, at 11:49 AM, David Greene wrote: > I had been assuming that give a LiveRange a, a.valno->def, if > valid, would be the same as a.start. But this is apparently not > always the case. For example: > > Predecessors according to CFG: 0x839d130 (#3) 0x8462780 (#35) > 308 %reg1051 = MOV64rr %reg1227<kill> > 312 %reg1052 = MOV64rr %reg1228<kill>

Hi, Anton and Fernando have answered most of your questions. I don't have anything to add there. I do want to comment on the "conservative" nature of LiveIntervalAnalysis. I think the comment is misleading and is probably just a relic of early implementation. The biggest problem with the current implementation is the overly aggressive copy coalescer. Right now the

On Wednesday 23 January 2008 02:01, Evan Cheng wrote: > > Can you explain the basic mechanics of the live interval splitting > > code? > It's splitting live intervals that span multiple basic blocks. That > is, when an interval is spilled, it introduce a single reload per > basic block and retarget all the uses to use the result of the single > reload. It does not

Hi David, Thanks for this patch! Some comments: 1. typedef std::set<const LiveInterval *> IntervalSet; Please use SmallPtrSet instead. 2. + virtual void mergeIntervals(const LiveInterval &a, + const LiveInterval &b, + const MachineInstr &copy) {}; I find the name misleading. It's not actually

Evan, Can you explain the basic mechanics of the live interval splitting code? Is it all in LiveIntervalAnalysis.cpp under addIntervalsForSpills and child routines? What is it trying to do? Also, in the ancient subregister coalescing code, there used to be an update of the SSARegMap to point subregisters to the superregister they were coalesced to (IIRC). That has since gone away. I used to

Hi, I'm working on the implementation of Extended Linear Scan register allocator as described by Sarkar & Bodik. One of the interesting features of their algorithm is the possibility to allocate different physical registers to different live-ranges of the same LiveInterval. Of course, it may require some glue code to be inserted in cases, where different physical regs were assigned to

Here's a proposed patch for reworking register coalescing to allow pluggable coalescers. I think I've got the interfaces where I want them and am reasonably sure I've squashed most of the bugs. I'm still doing some testing and want to get through a whole regimen before committing. As a reminder, this patch has several goals: - Allow user-specified register coalescers, similar

Hi David, Sorry I should have replied earlier. I really don't like this dual interface approach. To me, this muddles things without offering any real useful new functionalities. IMHO, if a register coalescer is tied to a particular allocator. Then either it should simply belong to that allocator or that we have to allow the allocator to act as a pass manager itself, i.e. it can

LiveVariables gives you something like liveness analysis: where each variable is alive, that is, across each basic blocks, where it is defined, and where it is killed. LiveIntervals gives you a linear representation of the variables as a set of intervals. Yes, it handle holes in the live ranges. There is a very nice description of these analysis and related data structures here:

On Wednesday 11 July 2007 15:07, Christopher Lamb wrote: > Could it be possible for there to be a harness type interface that > would allow coalescers that support both modes to be hooked into the > pass registration, and those that depend on the allocator not be > registered as passes? I have a patch for this kind of thing attached. Please take a look and let me know if it looks

On Thursday 21 February 2008 01:23, Evan Cheng wrote: > > Also, LiveIntervalAnalysis doesn't do any subregister checks as > > far as I can tell. It's certainly not the case that subregister > > intervals contain all of the information their supperregister's > > interval contains. > > SimpleRegisterCoalescing::JoinIntervals(). When coalescing a physical

On Feb 27, 2009, at 7:20 AM, Roman Levenstein wrote: > Hi, > > I'm working on the implementation of Extended Linear Scan register > allocator as described by Sarkar & Bodik. > One of the interesting features of their algorithm is the possibility > to allocate different physical registers to different live-ranges of > the same LiveInterval. Of course, it may require

Hi Evan, Thanks a lot for your reply! 2009/2/27 Evan Cheng <evan.cheng at apple.com>: > > On Feb 27, 2009, at 7:20 AM, Roman Levenstein wrote: > >> Hi, >> >> I'm working on the implementation of Extended Linear Scan register >> allocator as described by Sarkar & Bodik. >> One of the interesting features of their algorithm is the possibility