search for: simpleregistercoalescer

Hi, I'm implementing some variations of graph-coloring register allocators for LLVM. Many of them perform their phases (e.g. coalescing, graph simplification, spilling, color selection) in an iterative way. Since LLVM provides an implementation of the coalescing in the SimpleRegisterCoalescing class already, I would like to reuse it (even though I could of course create my own coalescing

...imary interface to invoke the coalescer. The iterative coalescer I wrote implements that function. The iterative coalescer is also a FunctionPass which does nothing. It's simply there to fulfill the requirement that the register allocator depends on a coalescer. This way I could use the SimpleRegisterCoalescer or the new iterative coalescer in a pluggable manner. The generalized graph coloring allocator holds a reference to the coalescer. SimpleRegisterCoalescing does nothing in its implementation of coalesceFunction. This is all very far from ideal. What we really need is a PassManager that know...

While working on a back-end for a target, I've come across something I believe to be a bug in SimpleRegisterCoalescing.cpp. I'm unsure how / whether to report it because I don't think it will necessarily crash or generate incorrect code for any of the supported targets. I believe that there may be a problem in SimpleRegisterCoalescing::runOnMachineFunction where the allocatable

On Sep 12, 2011, at 10:56 AM, Steve Montgomery wrote: > While working on a back-end for a target, I've come across something I believe to be a bug in SimpleRegisterCoalescing.cpp. I'm unsure how / whether to report it because I don't think it will necessarily crash or generate incorrect code for any of the supported targets. > > I believe that there may be a problem in

Thanks for your help. I've tried building from the trunk and it works, as you'd suggested. On 13 Sep 2011, at 01:00, Jakob Stoklund Olesen wrote: > > On Sep 12, 2011, at 10:56 AM, Steve Montgomery wrote: > >> While working on a back-end for a target, I've come across something I believe to be a bug in SimpleRegisterCoalescing.cpp. I'm unsure how / whether to

Dear guys, I want to coalesce some copies, and I would like to know if there is any method that I can call, like JoinCopy from the old (LLVM 1.9) LiveIntervals class. I found it in SimpleRegisterCoalescing (LLVM 2.1), but I do not want to call this analysis, as I have my own. basically, I can determine that two virtuals do not overlap, and I know that it is safe to join them. In

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

Dear Dave, Evan, thank you for answering. What I did was to remove the implementation of most of the methods of SimpleRegisterCoalescing and put them in a single class (RegisterCoalescer_Impl) that is not an analysis. Any class that wants these methods, can extend this class privately, or can use a reference to an RegisterCoalescer_Impl object. I wish it would be possible to go even

On Jul 11, 2007, at 11:39 AM, David Greene wrote: > On Wednesday 11 July 2007 12:41, Tanya M. Lattner wrote: > >> I think the coalescer should be flexible enough to be run >> independent of >> the register allocator. For example, you may want to expose the >> copies >> induced by transforming out of SSA to the scheduler. If the >> scheduler is

On Dec 15, 2007, at 4:45 PM, Fernando Magno Quintao Pereira wrote: > > Dear guys, > > I want to coalesce some copies, and I would like to know if > there is > any method that I can call, like JoinCopy from the old (LLVM 1.9) > LiveIntervals class. I found it in SimpleRegisterCoalescing (LLVM > 2.1), > but I do not want to call this analysis, as I have my own.

On Monday 17 December 2007 14:06, Fernando Magno Quintao Pereira wrote: > Dear Dave, Evan, thank you for answering. > > What I did was to remove the implementation of most of the methods of > SimpleRegisterCoalescing and put them in a single class > (RegisterCoalescer_Impl) that is not an analysis. Any class that wants > these methods, can extend this class privately, or can

I just ran into a problem here. I'm in SimpleRegisterCoalescing at the point where EXTRACT_SUBREG coalescing updates live ranges of aliased registers (around line 473 of SimpleRegisterCoalescing.cpp). There's a call to MergeValueInAsValue at line 50. MergeValueInAsValue has this code: void LiveInterval::MergeValueInAsValue(const LiveInterval &RHS,

Hello all Currently I want to use the accurate liveness information when writing a *target independent* FunctionPass based on LLVM. The one I can find is LiveValues, a FunctionPass. But it doesn't use classic dataflow equation and can only provide approximate and conservative result. The another one is LiveVariables which use classic data flow equation, but it comes from Clang's analysis

Jin-Gu Thanks for your suggestion. Using liveness information for virtual register is a good idea, but what I am working on is a source-to-source compiler, so I prefer to use FunctionPass instead of MachineFunctionPass. Interestingly I found a FunctionPass example for classic liveness data flow equation. http://cs.pub.ro/~cpl/wiki/images/1/15/Hello.txt

I've hit a bug in a refactored version of coalescing and I'm trying to understand what is going on. In particular, I'm curious about this line in SimpleRegisterCoalescing.cpp: 00710 LHSValsDefinedFromRHS[VNI] = RHS.getLiveRangeContaining(VNI->def-1)->valno; Why VNI->def-1? The bug I'm seeing is that RHS returns a NULL LiveRange because it doesn't contain

Hi all! I gave a shot at compiling core llvm with a Solaris 9 machine. The compiler is FSF gcc 3.4.6. I am building trunk in the release version. So far I did not run tests (no dejagnu installed). Here are my findings: 0) Configuring. I had to suppress the solaris tools by: env AR=/opt/gnu/bin/ar NM=/opt/gnu/bin/nm RANLIB=/opt/gnu/bin/ranlib STRIP=/opt/gnu/bin/strip ../llvm/configure

<style id="sinamailpaperfilter">.sinamailpaper-0{cursor:text;}.sinamailpaper-0 td,.sinamailpaper-0 textarea,.sinamailpaper-0 input,.sinamailpaper-0 br,.sinamailpaper-0 div,.sinamailpaper-0 span{font-size:14px;font-family:"宋体",Verdana,Arial,Helvetica,sans-serif;line-height:1.5;}.sinamailpaper-0 p{/**margin:0.2em auto;*/margin:0px;}.sinamailpaper-0

Hello, I am a newbie to LLVM as well as compilers and I am hoping for some direction in finding an instance of where a Reaching Definition Analysis is being implemented within LLVM. I have referenced the sources files, initially hoping to find an explicit ReachingDefinitionAnalysis.cpp file ;-) but with no such luck. Other than that I have found the files SimpleRegisterCoalescing.cpp and the

On Tuesday 25 September 2007 10:49, David Greene wrote: > I've hit a bug in a refactored version of coalescing and I'm trying to > understand what is going on. In particular, I'm curious about this > line in SimpleRegisterCoalescing.cpp: > > 00710 LHSValsDefinedFromRHS[VNI] = > RHS.getLiveRangeContaining(VNI->def-1)->valno; > > Why VNI->def-1?

AFAIK std::upper_bound() would not return end(), right? Evan On Jan 29, 2008, at 3:08 PM, David Greene wrote: > I just ran into a problem here. I'm in SimpleRegisterCoalescing at > the point > where EXTRACT_SUBREG coalescing updates live ranges of aliased > registers (around line 473 of SimpleRegisterCoalescing.cpp). > > There's a call to MergeValueInAsValue at line