[MustExecute/LICM] Special case first instruction in throwing header

We currently have a hard to solve analysis problem around the order of instructions within a potentially throwing block. We can'

[MustExecute/LICM] Special case first instruction in throwing header

We currently have a hard to solve analysis problem around the order of instructions within a potentially throwing block. We can't cheaply determine whether a given instruction is before the first potential throw in the block. While we're working on that in the background, special case the first instruction within the header.

why this particular special case? Well, headers are guaranteed to execute if the loop does, and it turns out we tend to produce this form in practice.

In a follow on patch, I tend to extend LICM with an alternate approach which works for any instruction in the header before the first throw, but this is the best I can come up with other users of the analysis (such as store promotion.)

Note: I can't show the difference in the analysis result since we're ORing in the expensive instruction walk used by SCEV. Using the full walk is not suitable for a general solution.
llvm-svn: 331079

show more ...

Make helpers static. NFC.

llvm-svn: 329170

Fix an accidental circular dependence

llvm-svn: 328816

[MustExecute] Shwo the effect of using full loop info variant

Most basic possible test for the logic used by LICM.

Also contains a speculative build fix for compiles which complain about a definiti

[MustExecute] Shwo the effect of using full loop info variant

Most basic possible test for the logic used by LICM.

Also contains a speculative build fix for compiles which complain about a definition of a stuct K; followed by a declaration as class K;

llvm-svn: 328058

show more ...

[MustExecute] Move isGuaranteedToExecute and related rourtines to Analysis

Next step is to actually merge the implementations and get both implementations tested through the new printer.

llvm-svn:

[MustExecute] Move isGuaranteedToExecute and related rourtines to Analysis

Next step is to actually merge the implementations and get both implementations tested through the new printer.

llvm-svn: 328055

show more ...

[MustExecute] Use the annotation style printer

As suggested in the original review (https://reviews.llvm.org/D44524), use an annotation style printer instead.

Note: The switch from -analyze to -dis

[MustExecute] Use the annotation style printer

As suggested in the original review (https://reviews.llvm.org/D44524), use an annotation style printer instead.

Note: The switch from -analyze to -disable-output in tests was driven by the fact that seems to be the idiomatic style used in annoation passes. I tried to keep both working, but the old style pass API for printers really doesn't make this easy. It invokes (runOnFunction, print(Module)) repeatedly. I decided the extra state wasn't worth it given the old pass manager is going away soonish anyway.
llvm-svn: 328015

show more ...

Add an analysis printer for must execute reasoning

Many of our loop passes make use of so called "must execute" or "guaranteed to execute" facts to prove the legality of code motion. The basic notio

Add an analysis printer for must execute reasoning

Many of our loop passes make use of so called "must execute" or "guaranteed to execute" facts to prove the legality of code motion. The basic notion is that we know (by assumption) an instruction didn't fault at it's original location, so if the location we move it to is strictly post dominated by the original, then we can't have introduced a new fault.

At the moment, the testing for this logic is somewhat adhoc and done mostly through LICM. Since I'm working on that code, I want to improve the testing. This patch is the first step in that direction. It doesn't actually test the variant used by the loop passes - I need to move that to the Analysis library first - but instead exercises an alternate implementation used by SCEV. (I plan on merging both implementations.)

Note: I'll be replacing the printing logic within this with an annotation based version in the near future. Anna suggested this in review, and it seems like a strictly better format.

Differential Revision: https://reviews.llvm.org/D44524

llvm-svn: 328004

show more ...