llvm dev - Aug 2012 - [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

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

On 08/13/2012 06:16 PM, Sergei Larin wrote:
>> Another solution (which we use in TCE) is to use register renaming.
>
>    You do it in LLVM? Do you plan to upstream it?
Not in LLVM but with a custom scheduler framework.

Our target is quite unique (see the blog post for an example)
therefore it's not completely clear (yet) how to map it to the LLVM
codegen/machineinstructions the best way while still exploiting the
unique optimizations of TTA. I've been following the activity on VLIW
support of LLVM in the hopes we can someday move more towards LLVM code
base.

I didn't know about the "post-RA sched. antidep breakers" in LLVM
codegen
of which idea sound similar to what we do.
> Also, I do not know your target/goal, but do you look at global scheduling
> at all?
Only somewhat at this point (branch delay slot filling from the
target BB). Region scheduling and speculation is something that is
interesting but it hasn't been the "biggest itch" yet in our
projects
therefore not implemented yet. I see efficient predication support as
highest priority (e.g. hyperblocks) for VLIWs.

BR,
-- 
--Pekka