As mentioned at the MSSA roundtable, LICM spends a lot of time construction an AST, despite the caps already in place. This patch is a proposal on how to reduce the impact.
The idea here is pretty simple: We're only interested in must-alias mod sets of loop invariant pointers. As such, only populate the AST with loop-invariant loads and stores (anything else is definitely not promotable) and then discard any sets with alias with any of the remaining, definitely non-promotable accesses.
This has a large positive compile-time impact: https://llvm-compile-time-tracker.com/compare.php?from=d7186fe3710828fab03de69f78f01f001d70e1aa&to=264016756045aba11ae326bfab6a632bc5ef1855&stat=instructions We save ~2% geomean at `O3`, and lencod in particular saves 6%.
There is **no** impact on the number of promotions (`licm.NumPromoted`) in test-suite with this change.
However, while there is no practical impact on test-suite, we do see some differences in lit tests:
* As seen in the 2011-04-06-PromoteResultOfPromotion.ll test, previously it could happen that promotion of one set made the pointers in another loop invariant. We no longer catch such cases, as the non-invariant accesses (at that time) have already been discarded.
* There are regressions in loopversioningLICM1.ll/loopversioningLICM2.ll. Based on an initial analysis these are caused by a different order of checks. Due to AATags intersection, the later accesses no longer register as NoAlias. I'll have to check a bit closer if there's anything to be done there.