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

[Sergei Larin]

Ivan, 

  IMHO the current bundle infrastructure is in need of some additional
features - not only bundle handling utilities, but also support for liveness
computation, several (key) code transformation passes etc. (see my recent
post for conditional defs for instance). Does your back-end perform any
substantial transformations to the code _after_ the second pass (postRA)
scheduler and bundle formation/finalization? Does any of them might demand
bundle decomposition? If so, I really wonder how do you plan to address
that.

  We also have an MI based version of the current VLIW scheduler, that I am
planning to bring up to date with the tip, and upstream ASAP. But it is
preRA scheduler, and it does not preserve bundles (though it constructs them
and easily could keep them around). The issue is what I have said above,
many current passes do not understand bundles (well or at all) and accurate
liveness update has been an issue for me recently.

  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.

  I guess what I am saying is that you are not alone in this :) ...and we do
need to formulate our requirements clearly... and repeat them regularly :)
Hope this helps.

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 Ivan Llopard
> Sent: Tuesday, July 31, 2012 10:37 AM
> To: LLVM Developers Mailing List
> Subject: [LLVMdev] [RFC] Bundling support in the PostRA Scheduler
> 
> Hi,
> 
> I'm working on a custom top-down post RA scheduler which builds bundles
> at the same time for our VLIW processor. I've borrowed most of the
> implementation from the resource priority queue implemented for the
> existent VLIW scheduler but applied to the context of MI scheduling.
> Basically, instructions that are likely to be bundled must be scheduled
> first (i.e. get higher priority).
> This work should integrate very well with the current infrastructure
> and I'd like to contribute with a patch to add bundling capabilities to
> the current post RA scheduler if the LLVM community is interested :-)
> (May Hexagon need it as well?). It would also be a great opportunity
> for us to get feedback from the community about this.
> 
> We have a non-interlocked processor which relies on the post ra
> scheduler to emit cycle-accurate bundles (valid bundles without
> incurring in structural hazards). The construction of bundles outside
> the scope of post RA scheduling will require structural hazard
> information to work properly for processors without pipeline
> interlocks.
> For example, we can discover that an instruction can fit into the
> current packet (following a schema of linear code scanning, just like
> the current DFAPacketizer does) while in fact it cannot because of
> structural hazards. The two terms are strongly connected and necessary
> to build valid packets.
> The concerns are mainly based on our non-interlocked processor, where
> cycle-accurate bundle emission is necessary. Other approaches/ideas are
> very welcome.
> Do you have any plan for adding a more robust bundler into the current
> infrastructure ?
> 
> Ivan
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev