This is an archive of the discontinued LLVM Phabricator instance.

[RISCV] Massage debug loc to improve scheduling of addressing for scatter/gather
AbandonedPublic

Authored by reames on Sep 19 2022, 2:49 PM.

Details

Reviewers
craig.topper
asb
Summary

This patch is admittedly a bit of a hack, but it's a useful hack.

SelectionDAG likes to build scaled scatter/gather nodes. RISCV doesn't support scaling, so we have a combine which unfolds this. However, the newly unfolded scaling inherits the memory ops debug location, not the debug location of the original GEP (which no longer exists). As a result, DAG schedule tends to mix the scaling with any e.g. interleaved scatter/gathers. This is bad because the addressing is often in a different data width than the scatter/gather and thus requires a bunch of extra vsetvli toggles.

We probably should prevent SelectionDAGBuilder from forming these at all, and I intend to play with that a bit to see if it's straight forward. However, this is an improvement on the current codegen at minimal cost, so I think we should take the workaround for the moment.

Diff Detail

Event Timeline

reames created this revision.Sep 19 2022, 2:49 PM
reames requested review of this revision.Sep 19 2022, 2:49 PM
Herald added a project: Restricted Project. · View Herald TranscriptSep 19 2022, 2:49 PM

Alternate patch here: https://reviews.llvm.org/D134382

This doesn't entirely eliminate the need for this change, but it removes the majority of the impact. After that patch, we only have to worry about the extend case.

reames abandoned this revision.Sep 27 2022, 9:44 AM

D134382 handled the motivating address scaling problem. I went back and took a look at the subset of this patch for the extension, and the test diffs were a real mix. The improvements seen were fairly minor, but we seemed to sometimes trigger register spilling (particularly at high lmul) by extending live ranges. Given the SEW of the extend isn't tied to the addressing SEW or the data SEW, I don't think there's a solid argument to prefer one over the other here.