similar to: [LLVMdev] Looking for a Reaching Definition Analysis

The immediate uses info provides reaching definitions already, at least while the code is in SSA form. So uh, what more are you looking for? 2009/3/17 Shone Sadler <shone.sadler at gmail.com>: > 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

Thanks for the response. I was more specifically looking through the source code for a place where Reaching Definitions was implemented to derive those uses and/or to generate the SSA. To provide some context, as a student I have a project to implement a path infeasibility algorithm to "Sharpen" the results of the Reaching Definitions results in LLVM. Being new to LLVM I wasn't

2009/3/17 Shone Sadler <shone.sadler at gmail.com>: > I was more specifically looking through the source > code for a place where Reaching Definitions was implemented to derive those > uses and/or to generate the SSA. mem2reg (llvm/lib/Transforms/Utils/PromoteMemoryToRegister.cpp) transforms to SSA form, but that's the conventional SSA construction algorithm, which doesn't

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

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

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, As I work toward improving LLVM register allocation, I've come across the need to do some refactoring. Specifically, I would like to separate register coalescing from live interval analysis. Right now LiveIntervals handles both. The reason I want to separate them is that other types of register allocators might like to do coalescing differently (e.g. graph coloring does it by

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

On May 19, 2011, at 7:47 AM, Jonas Paulsson wrote: > Hi, > > I am combining 16-bit registers to a 32 bit register in order to make a wide store, as per below: > > 732 %reg16506:hi16<def,dead> = COPY %reg16445<kill>; > 740 %reg16506:lo16<def> = COPY %reg16468<kill>; > 748 %r3<def,dead> = store %reg16506<kill>, %r3, > > As you can

Hi all, I'm tracking down a register allocation problem and I'm trying to understand this piece of code in InlineSpiller::spillAroundUses: // Find the slot index where this instruction reads and writes OldLI. // This is usually the def slot, except for tied early clobbers. SlotIndex Idx = LIS.getInstructionIndex(*MI).getRegSlot(); if (VNInfo *VNI =

Just adding a bit more info: Running wbinfo -t on the file server results in a successful trust secret check via RPC Running wbinfo -u on the file server returns all my AD users Running wbinfo -g on the file server returns all my AD groups Running wbinfo -p on the file server results in a successful ping to winbindd I have used the basic smb.conf on the wiki page for the file/member

Hi, I am combining 16-bit registers to a 32 bit register in order to make a wide store, as per below: 732 %reg16506:hi16<def,dead> = COPY %reg16445<kill>; 740 %reg16506:lo16<def> = COPY %reg16468<kill>; 748 %r3<def,dead> = store %reg16506<kill>, %r3, As you can see, LiveVariables has marked the high part dead, even though the super-register is used at

When compiling trunk using gcc 4.1.2 on linux/ppc64, I now see a warning that I don't remember seeing previously: llvm[2]: Compiling InlineSpiller.cpp for Release+Asserts build /src/llvm-trunk-dev/include/llvm/ADT/PointerIntPair.h: In member function ‘const PointerTy* llvm::PointerIntPair<PointerTy, IntBits, IntType, PtrTraits>::getAddrOfPointer() const [with PointerTy = void*, unsigned

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

Colin Farrow <C.Farrow@geology.gla.ac.uk> writes: > Peter, > > Cautiously sticking my neck above the water line here. I have been > wondering about the Mac version for a while now. I may be able to get > an MSc IT student to work on this as a project for about 3 months > June-Sept. Before putting up the proposal some idea of the scale of the > task would be useful. Do

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