[PATCH] D93734: [LoopDeletion] Insert an early exit from dead path in loop

[Jonas Paulsson via Phabricator via llvm-commits]

jonpa updated this revision to Diff 314473.
jonpa added a comment.

With the motto of pushing things forward even if only by aiding the other related patches, I have continued to improve my patch to use as some kind of baseline for "early exit" insertions. Perhaps it can be used during development of the partial loop-unswitching to find cases to handle, or perhaps it could be used for some cases if it would reduce the burden on the other algorithm. It would be very nice if partial unswitching could handle all this instead, of course :-)

Instead of just handling the header->latch edge, now any edge from the "Header region" to the "Latch region" can be handled. The requirements are that in the header region, all conditions must be loop invariant, and there can only be one reachable exit block in the latch region from the branch target block back to header. If there is no exit block on the dead path but the loop has a unique exit block, that exit block is used for the early exit, given the mustprogress attribute.

Interestingly enough, there are now cases where this patch manages to "delete" (or "eliminate") a loop which has multiple exits. The loop structure is removed while the BBs remain, which should hopefullyl be removed later by CFG-opt. I think this is rare on benchmarks though... (see below)

I found out quickly that perhaps the hardest part of this was to update datastructures after changing the CFG in a loop... I have barely been able to build the benchmarks as it is, so I am in need of some good advice on how to update things after a loop change, for this patch to be usable. Currently I have changed things temporarily so that LI, DT, etc are recomputed after loop deletion (BTW, I found that only recomputing those analyses on master after LoopDeletion was not NFC, which surprised me... Is that a bug or expected with the aim to save compile time?)

Statistics on SPEC-17 on SystemZ:

  master (patched to not preserve analyses after LoopDeletion for a fair comparison):
  
        7276                    loop-delete - Number of loops deleted



  Only Header/Latch (like first simple version aimed to do):
        1414                    loop-delete - Number of early exits inserted
        7498                    loop-delete - Number of loops deleted
           8                    loop-delete - Number of loops eliminated (no remaining blocks)
         462                    loop-delete - Number of skipped loops (SCEV 0)



  Top/Bot regions (current patch):
        2353                    loop-delete - Number of early exits inserted
        7397                    loop-delete - Number of loops deleted
           6                    loop-delete - Number of loops eliminated (no remaining blocks)
         462                    loop-delete - Number of skipped loops (SCEV 0)

A rise from ~1400 to ~2350 is a fairly nice improvement in number of early exits inserted compared to initial patch. There seem to be some difference also in number of loops deleted as reported by deleteLoopIfDead(), which I have not investigated. It seems that somehow must relate to a parent loop now not having a subloop..?

@reames: I am not quite sure how the SE->isZero() case directly relates to the detection of dead paths per my patch... I have here tried a statistic for that case, which showed that some loops could be handled by your patch, while there are still many more that can not... (see above).

@jdoerfert:

> FWIW, I my goal is to make it something driven by a generic analysis, not another pattern we match.

I agree with that, I have now made the patch more general.


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

https://reviews.llvm.org/D93734

Files:
  llvm/include/llvm/Transforms/Utils/LoopUtils.h
  llvm/lib/Transforms/Scalar/LoopDeletion.cpp
  llvm/lib/Transforms/Utils/LoopUtils.cpp
  llvm/test/Transforms/LoopDeletion/early-exits.ll

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D93734.314473.patch
Type: text/x-patch
Size: 27197 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20210105/e868094f/attachment.bin>