[PATCH] D32015: Make globalaa-retained.ll test catching more cases.

[Kristof Beyls via Phabricator via llvm-commits]

kristof.beyls added inline comments.


================
Comment at: llvm/test/Transforms/PhaseOrdering/globalaa-retained.ll:9-14
+; Invalidation might happen later in the pipeline than the
+; optimization eliminating unnecessary loads/stores. Add empty
+; functions before/after the function we're checking so that one of
+; them will be processed by the whole set of FunctionPasses before @f.
+; That will ensure the invalidation will happen before actual
+; optimizations on @f start.
----------------
I think this comment is a bit hard to understand. Below I tried tweaking the comment a bit, so it's a bit easier to understand, just adding more words to point to key ideas needed to understand the comment. I've marked my additions between asterisks.
Is the comment still valid? If so, I think it'll be easier to understand.


```
; *This test checks that a number of loads and stores are eliminated, that can only be eliminated based on GlobalsAA information. As such, it tests that GlobalsAA information is retained until the passes that perform this optimization, and it protects against accidentally dropping the GlobalsAA information earlier in the pipeline, which has happened a few times.*
; *GlobalsAA* invalidation might happen later in the pipeline than the
; optimization eliminating unnecessary loads/stores. 
; *Since GlobalsAA is a module-level analysis, any FunctionPass invalidating the GlobalsAA information will affect FunctionPass pipelines that execute later. For example, assume a FunctionPass1 | FunctionPass2 pipeline and 2 functions to be processed: f1 and f2. Assume furthermore that FunctionPass1 uses GlobalsAA info to do an optimization, and FunctionPass2 invalidates GlobalsAA. Assume the function passes run in the following order: FunctionPass1(f1), FunctionPass2(f1), FunctionPass1(f2), FunctionPass2(f2). Then FunctionPass1 will not be able to optimize f2, since GlobalsAA will have been invalidated in FuntionPass2(f1). To try and also test this scenario, there is an empty function before and after *
;  the function we're checking so that one of
; them will be processed by the whole set of FunctionPasses before @f.
; That will ensure *that if the invalidation happens, it happens* before the actual
; optimizations on @f start.
```

Other than that, I'm just wondering if there are any guarantees that the pipeline couldn't process the functions in the order `@f`, `@bar`, `@bar2`?



https://reviews.llvm.org/D32015