search for: registerallocation

...#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-the-us...

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

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 >

On Tuesday 17 July 2007 14:21, David Greene wrote: > > I don't care for a MachineFunctionPass that can be directly called. I > > think it's a very good idea to keep the coalescers independent from > > the allocators. If that's desired, we should enhance passmanager so > > each allocator can run some sub-passes as part of the allocation > > pass. > >

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

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

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

On Monday 09 July 2007 17:07, David Greene wrote: > On Monday 09 July 2007 16:49, Reid Spencer wrote: > > The only thing that comes to mind is that creating and running the > > coalescer are separate operations so you might want to do the creation > > of it in alias analysis style. Then, the allocator can a) determine if a > > coalescer was created, b) obtain the

On Jul 17, 2007, at 8:49 PM, David A. Greene wrote: > On Tuesday 17 July 2007 14:21, David Greene wrote: > >>> I don't care for a MachineFunctionPass that can be directly >>> called. I >>> think it's a very good idea to keep the coalescers independent from >>> the allocators. If that's desired, we should enhance passmanager so >>>