[PATCH] D60294: [DAGCombiner] [CodeGenPrepare] WIP/RFC Splitting large offsets from base addresses

[Alex Bradbury via Phabricator via llvm-commits]

asb added a comment.

In D60294#1456609 <https://reviews.llvm.org/D60294#1456609>, @efriedma wrote:

> Given that we're splitting the GEPs before SelectionDAG, the only way to preserve the optimization is to avoid re-merging them... and I can't think of any reasonable approach for that other than something along the lines of this patch.  Well, I guess we could just completely disable folding without regard for whether the addressing mode is legal, but that probably interacts badly with type legalization.
>
> The alternative, as you note, is to do something after isel.  Arguably that would be more effective.  At that point you have a better idea of what constants are actually necessary, and you could integrate it with other similar optimizations like optimizing related integer constants.  This is sort of along the lines of RISCVMergeBaseOffset.


My feeling is that if there are no major objections to disabling the fold in this case (e.g. an undocumented requirement that add with constants are always canonicalised as they currently are), then it seems worth adding logic like this to disable the re-merging on the basis that 1) it's not a huge amount of code that serves to preserve work that's already done in CodeGenPrepare anyway, 2) it's easier for other backends to make use of it. I agree there may later be scope for pass that runs after ISel that might be wider in scope. But for this transformation, it seems a shame to have a situation where CodeGenPrepare does the necessary analysis+transformation, the DAGCombiner undoes that work, then a very similar analysis+transformation is done again on the SelectionDAG.


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D60294/new/

https://reviews.llvm.org/D60294