[PATCH] D81584: [BreakCritEdges] Support preserving loop-simplify form with indirectbr. (WIP)
Florian Hahn via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Wed Jun 10 17:15:35 PDT 2020
fhahn added a comment.
In D81584#2086163 <https://reviews.llvm.org/D81584#2086163>, @efriedma wrote:
> > Agreed. I think that would go well with D81582 <https://reviews.llvm.org/D81582>, i.e. have a PreserveLoopSimplify option, that guarantees loop-simplify form is preserved or nullptr is returned if it's not possible
>
> We can kill off the call to SplitBlockPredecessors, and add an option to bail out if preserving loop-simplify form would require transforming other edges, sure. (I'd rather not condition it on whether the other edges are IndirectBr edges; I'd like to avoid obscure IndirectBr edge cases where possible.)
Ok. In the short term, I'd like the fix the crash in GVN asap. Preserving simplify-form as in this patch will require a bit of extra work in a couple of places. I think in the short-term, it might be best to add a `PreserveLoopSimplify` option and have GVN not preserve loop-simplify form, until this patch is ready. What do you think?
>> Also, do you agree that preserving loop-simplify form by moving instructions to a different BB is more trouble than it is worth?
>
> This doesn't seem worse than calling SplitBlockPredecessors(), in terms of transforming the CFG in unpredictable ways.
Agreed, unfortunately the existing users don't deal too gratefully with moving instructions, but I don't think anything in the SplitCriticalEdges interface guarantees that. If you are not concerned about the general approach and the small hoops that existing users have to jump through (see GVN & LSR changes), I am happy to continue with this approach, but it will probably require a few additional changes.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D81584/new/
https://reviews.llvm.org/D81584
More information about the llvm-commits
mailing list