similar to: [LLVMdev] Question about coalescing

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.

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

Hello Jakob, I think I've found something interesting that may help you get a better idea of what's going on. While looking at the debug info I noticed that the coalescer was removing lots of copies that could help the allocator make more cross class copies. As a test, I disabled the join-liveintervals option in the coalescer which gave me the surprise of making the regalloc succeed. To

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

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 Friday 09 January 2009 03:36, Roman Levenstein wrote: > 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

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

I want to full understand register coalescing and how to coalesce copies. From what I have seen from "SimpleRegisterCoalescing," "RegAllocLinearSpan," and "RegAllocPBQP" there are three indicators for the copy instruction x = copy y. Assume that the value number of x does not equal the value number of y. For "x = copy y", let the boolean values a,b, and c,

I have only just begun looking through the docs for LLVM. I have read through some of the PP presentations to get an idea of the modularity of LLVM. May someone be so kind to point me to some documentation on how to communicate with the LLVM modules (specifically the optimizer) from some third party piece of software (my compiler)? I am hoping there is a file format, or some serialization, that

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

I am starting to see a few issues with OCFS and 9.2.0.3 RAC on redHat Linux AS 2.1. Wondering if there is anyone out there experiencing similar issues... a few pointers to the issues.. 1. OCFS read/write performance is way lower than a read/write to a raw device.. i can give you some comparison numbers.. 2. Writes to shared disk with ocfs would get locked up by one server.. it doesnt have to

I am starting to see a few issues with OCFS and 9.2.0.3 RAC on redHat Linux AS 2.1. Wondering if there is anyone out there experiencing similar issues... a few pointers to the issues.. 1. OCFS read/write performance is way lower than a read/write to a raw device.. i can give you some comparison numbers.. 2. Writes to shared disk with ocfs would get locked up by one server.. it doesnt have to

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

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

hola, tengo dos vectores de 1134 y 385 elementos que se corresponden con números de accesión de genes. Necesito saber que números son comunes o intersección de vectores. He utilizado intersect(x,y) y me da todo el rato un único valor: V1 V1.1 V1.2 V1.3 V1.4 V1.5 V1.6 V1.7 V1.8 V1.9 V1.10 V1.11 V1.12 1 AJ558305 AJ558305 AJ558305 AJ558305 AJ558305

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,

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