search for: registeralloc

...#39;m study Fast register allocation in codegen. I get confused with isKill flag in MachineOperand. I thin "isKill" flag the last Use Reference. But, Fast Register doesn't require LiveVariable Analysis which will mark isKill Flag for global virtual Register. So during Fast RegisterAllocation, Faster Register Allocation procedure can't determine if this use-reference is the last use through current path ; , How does Fast RegisterAllocation resolve such problem ? -- View this message in context: http://llvm.1065342.n5.nabble.com/How-Fast-RegisterAllocation-determine-if-t...

...figure out any additional interfaces that are needed. If this looks good, I'll commit it and later on I'll commit any additions I make to this basic interface. -Dave -------------- next part -------------- Index: llvm/include/llvm/CodeGen/RegisterAllocator.h =================================================================== --- llvm/include/llvm/CodeGen/RegisterAllocator.h (revision 0) +++ llvm/include/llvm/CodeGen/RegisterAllocator.h (revision 0) @@ -0,0 +1,41 @@ +//===-- RegisterAllocator.h - Register Coalescing Interface ------*- C++ -*-===//...

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

Dan: CellSPU could clearly benefit from the post-RA scheduler. In fact, we were thinking about writing a machine pass of our own. One thing that does "disturb" me is that both HazardRecognizer and post-RA sched assume there's only one kind of NOP. For Cell, there are two, depending upon the pipeline being filled. Pipe 0 takes "ENOP" whereas Pipe 1 take

I cannot figure out a particular PassManager error for what seem to be legal dependencies. Here is the situation. We have 5 passes, RegisterAllocator, FunctionLiveVarInfo, CoalesceCopies, DominanceForest, and UnionSSAVars, with dependencies as follows: class RegisterAllocator : public FunctionPass { . . . virtual void getAnalysisUsage(AnalysisUsage &AU) const { AU.addRequired<FunctionLiveVarInfo>(); AU.addRequired<Coalesc...

On Jan 19, 2009, at 11:01 AM, Patrick Boettcher wrote: > > >>> And more generally: Is the hazardRecognizer the right and only way >>> to >>> solve our NOOP-minimizing problem? >> >> Perhaps you want to do this after register allocation is done. Dan is >> developing the post-allocation scheduler. You can try it out. > > Interesting. Can it

On Monday 19 January 2009 19:47, Dan Gohman wrote: > > Can they be used in conjunction with > > MemoryDependenceAnalysis? e.g. can we write a MachineInstructions- > > based > > memory dependence analysis that uses MachineMemoryOperands? > > Right, the existing MemoryDependenceAnalysis works in terms of > LLVM-IR-level Instructions, but yes, it would be possible

On Jan 19, 2009, at 9:17 AM, Patrick Boettcher wrote: > Hi list, > > in our LLVM-based-project we are writing a backend for our > processor. The > architecture is a quite straight-forward RISC, but it does not have > hardware interlocks, i.e. data hazards involving memory access must be > resolved by the compiler, either by scheduling unrelated > instructions or >

On Jan 19, 2009, at 3:38 PM, David Greene wrote: > On Monday 19 January 2009 16:42, Dan Gohman wrote: > >>>> Perhaps you want to do this after register allocation is done. >>>> Dan is >>>> developing the post-allocation scheduler. You can try it out. >>> >>> Interesting. Can it already be found SVN? I will search the mail >>>

On Monday 19 January 2009 16:42, Dan Gohman wrote: > >> Perhaps you want to do this after register allocation is done. Dan is > >> developing the post-allocation scheduler. You can try it out. > > > > Interesting. Can it already be found SVN? I will search the mail > > archive > > later, if not. > > Yes, it is in SVN. It's new, and so far

Hi Evan, thanks for your response. On Mon, 19 Jan 2009, Evan Cheng wrote: >> For example, code which looks like that: >> >> load 0x1234, reg1 >> noop >> noop >> add reg1, 1 >> load 0x1236, reg2 >> >> can be safely transformed to: >> >> load 0x1234, reg1 >> load 0x1236, reg2 >> noop >> add reg1, 1 >> >

Hi list, in our LLVM-based-project we are writing a backend for our processor. The architecture is a quite straight-forward RISC, but it does not have hardware interlocks, i.e. data hazards involving memory access must be resolved by the compiler, either by scheduling unrelated instructions or by inserting NOOPs into the load delay slots: ---- For example, code which looks like that: load

On Jan 19, 2009, at 5:06 PM, David Greene wrote: > On Monday 19 January 2009 18:21, Dan Gohman wrote: > >>> Dan, how does the scheduler handle memory dependence? I'm working >>> on >>> something that requires memory dependence information for >>> MachineInstructions. >> >> At the moment, it knows simple things, like constant pool loads

On Monday 19 January 2009 18:21, Dan Gohman wrote: > > Dan, how does the scheduler handle memory dependence? I'm working on > > something that requires memory dependence information for > > MachineInstructions. > > At the moment, it knows simple things, like constant pool loads > don't have dependencies, and references to distinct stack slots are >

...resources to implement it right now. If someone else can take up > this as a sub-project, that would be great! I agree that several other > passes could make use of it. I've got something in the works that provides an interface for the coalescer to query an interference object. So the RegisterAllocator class no longer exists and coalescers don't directly depend on register allocators. As a bonus, the interference interface doesn't make any assumptions about the underlying representation but has the interfaces necessary to make equivalent queries to what a coalescer might ask an inter...

...he register allocator. Perhaps a utility class that tracks interference information that can be accessed by both the allocator and the coalescer? Also, why is coalesceThisCopy() needed? Shouldn't the coalescer be responsible for making the decision? Evan Index: llvm/include/llvm/CodeGen/RegisterAllocator.h =================================================================== --- llvm/include/llvm/CodeGen/RegisterAllocator.h (revision 0) +++ llvm/include/llvm/CodeGen/RegisterAllocator.h (revision 0) @@ -0,0 +1,41 @@ +//===-- RegisterAllocator.h - Register Coalescing Interface ------*- C++ -*-===...

Hello llvmers: I'm study Fast register allocation in codegen. I get confused with isKill flag in MachineOperand. I thin "isKill Because Fast Register doesn't require LiveVariable Analysis , So during Fast RegisterAllocation, the Allocation procedure can't determine if this use reference is the last use ( isKill flag is missed for global Virtual register without pre-pass of LiveVariable analysis ); So, How does Fast RegisterAllocation resolve such problem ? -- View this message in context: http://llvm.1...

On Mon, 2007-07-16 at 16:19 -0700, Evan Cheng wrote: > Property changes on: llvm/include/llvm/CodeGen/RegisterAllocator.h > ___________________________________________________________________ > Name: svn:eol-style > + LF > > What's this? Its a property change. In Subversion every file and directory can have properties associated with them. For example the svn:ignore property on a directo...

...ly restricted scope. The register allocator needs to provide an interface for the coalescer to ask questions like, "is this copy here to split live ranges?" and, "will coalescing this copy potentially cause a spill?" AI think all this will require is new RegisterCoalescer and RegisterAllocator interface classes that can be multiply-inherited (with MachineFunctionPass) by the various implementations. It's not totally clear to me whether coalescers should even inherit from MachineFunctionPass as they are really invoked by the register allocator, not PassManager. But then agai...

...se can >> take up >> this as a sub-project, that would be great! I agree that several >> other >> passes could make use of it. > > I've got something in the works that provides an interface for the > coalescer > to query an interference object. So the RegisterAllocator class no > longer > exists and coalescers don't directly depend on register > allocators. As a > bonus, the interference interface doesn't make any assumptions about > the underlying representation but has the interfaces necessary to make > equivalent queries to w...