[LLVMdev] [RFC] Bundling support in the PostRA Scheduler

Sergei Larin slarin at codeaurora.org
Mon Aug 13 08:16:43 PDT 2012


Hi Pekka,

> Has anyone studied how much work it would be to implement an integrated
> allocator/scheduler in LLVM now?

  Not to my knowledge.

> Another solution (which we use in TCE) is to use register renaming.

  You do it in LLVM? Do you plan to upstream it?

Also, I do not know your target/goal, but do you look at global scheduling
at all?

Thanks.


Sergei

--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum.


> -----Original Message-----
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
> On Behalf Of Pekka Jääskeläinen
> Sent: Friday, August 10, 2012 2:28 AM
> To: llvmdev at cs.uiuc.edu; ivanllopard at gmail.com
> Subject: Re: [LLVMdev] [RFC] Bundling support in the PostRA Scheduler
> 
> Hi,
> 
> On 08/09/2012 10:03 PM, Sergei Larin wrote:
> >    I also tried to mess with PostRA scheduler to achieve similar
> > goals, only to find out that all the additional dependencies after RA
> > make it virtually impossible to produce high quality schedule, and
> > obviously it is too late at that point to address reg pressure via
> > scheduling techniques, so I have put that project on the back burner
> for a while.
> 
> Has anyone studied how much work it would be to implement an integrated
> allocator/scheduler in LLVM now? It should be an efficient solution to
> the VLIW RA/scheduling phase ordering problem, but of course it's more
> complex to implement and modularize. (I'm unsure if it's possible to
> exploit the current register allocator code easily with it).
> 
> Another solution (which we use in TCE) is to use register renaming.
> That is, rename schedule-restricting antideps introduced by the pre-RA
> "on the fly" during scheduling. It's sort of a middle ground solution
> that allows modularizing the proper RA to a separate pass cleanly.
> However, its proper implementation goes step-by-step towards the
> integrated allocator (smarter the renamer becomes, more it looks like a
> proper RA).
> 
> BR,
> --
> Pekka
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev





More information about the llvm-dev mailing list