Implements overrides for the 'areLoadsFromSameBasePtr' function and 'shouldScheduleLoadsNear' function. Implementing these allows the pre-ra-scheduler to identify loads that are relatively close together and glue them together for scheduling purposes. The patch adds 2 back-end options allowing tuning of the number of vector/scalar loads to try to cluster together.
Diff Detail
- Repository
- rL LLVM
Event Timeline
Noticed spelling mistake and ended up simplifying the loop in getChainOperand as part of the cleanup.
Interesting; I didn't realize that our SDAG-based scheduling actually did anything at this point (i.e. we're just using source-order scheduling) - The MI scheduler is where the real action happens, and that has a different clustering API. You should look at TII->shouldClusterMemOps and the other things used by BaseMemOpClusterMutation in MachineScheduler.cpp. I think we should only implement these older interfaces if there's some fundamental advantage to doing so. Otherwise, I'd focus on what the MI scheduler uses.
lib/Target/PowerPC/PPCInstrInfo.cpp | ||
---|---|---|
1941 | Space after 'if' (and so on for other 'if', 'while', etc. below). | |
2026 | We should synchronize this with PPCTTIImpl::getCacheLineSize(). |
Thanks for the feedback. I was looking at cleaning up the loads/stores from memcpy expansions and this worked pretty good for 64 bytes and under. Looking at a 128 byte expansion in BoringSSL was showing a number of limitations with this approach though. I'll look into the things you mention in MachineScheduler to see if I can get the behavior I'm looking for there.
Is this patch superseded by https://reviews.llvm.org/D29779? If so, please abandon this patch so it moves out of the reviewers' list.
After some investigation, I don't think LoadCluster/StoreCluster DAG mutations will provide the clustering I was looking to implement. Even with that I don't think we want to proceed with this patch either so I will abandon it as Nemanja suggests.
Space after 'if' (and so on for other 'if', 'while', etc. below).