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

[Andrew Trick]

On Jul 31, 2012, at 8:37 AM, Ivan Llopard <ivanllopard at gmail.com> wrote:

> 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

Hi Ivan,

Your description sounds fine to me. I assume you are totally decoupled from what LLVM currently calls the "postRA" scheduling pass. Hopefully you don't need anything in PostRASchedulerList.cpp.

Running your bundler as a preEmit pass is the cleanest approach. But if need be, we can support preRA bundling at the time the MachineScheduler currently runs (if enabled). TargetPassConfig allows you to substitute your own pass in place of MachineScheduler. Passes that run after MachineScheduler are intended to support instruction bundles. This feature is not extensively tested, so anyone taking this approach would need to work with backend maintainers to get things fixed.

-Andy