This will help with devirtualization (store forwarding with vtable pointers in
the presence of other stores into members in the constructor.) During inlining,
we don't have AA.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
- Build Status
Buildable 44197 Build 45371: arc lint + arc unit
Event Timeline
I believe if I request AA in Inliner.cpp and pass it down to FindAvailableLoadedValue through tryPromoteCall (D71308), it would work without this patch.
Is it okay to assume that a) the AA is BasicAA and b) BasicAA is stateless since the AA interface is more generic? Is there a way to condition this logic on those conditions?
llvm/lib/Analysis/Loads.cpp | ||
---|---|---|
457 | can you guard the change with if (!AA) { as we AA, it will be unnecessary. |
(just passing-by remark)
Perhaps it may be more productive to explain why this This is a simple form of alias analysis. *has* to exist?
Why can't, as suggested, BasicAA be used? What goes wrong if BasicAA is used?
To repeat/expand my question above,..
As I understand, it'd be possible to get the AA from the pass manager from the inline pass, but the AA interface is abstract and the inline pass can't assume what AA implementations they are (which is up to the pass manager setup) and they are stateless BasicAA (otherwise we'd need to invalidate/update stateful AA which is hard to do during (complex) inlining transformations and there's no guarantee that BasicAA will stay stateless in the future.) Is there a way to specifically request BasicAA and only it and that it must be stateless? The current proposed approach is to have this "simple form of alias analysis" to handle enough of the aliasing around a C++ constructor call for this missed inlining case.
I agree, it is quite bad to reinvent simple alias analysis here. If this is really a way to go, maybe move this code to own function?
As other commented, please extract the code into its own function also add the support when AA is available ( as other parts of the function does).
llvm/lib/Analysis/Loads.cpp | ||
---|---|---|
474 | else { ? |
llvm/lib/Analysis/Loads.cpp | ||
---|---|---|
474 | Do you mean it'd be good to combine the two if statements? if (!AA) { // ... if (AreNonOverlapSameBaseLoadAndStore(..)) continue; } else { // ... if (!isModSet(AA->getModRefInfo(SI, StrippedPtr, AccessSize))) continue; } |
llvm/lib/Analysis/Loads.cpp | ||
---|---|---|
474 | Yes (optional, if you like, do so) |
can you guard the change with
if (!AA) {
}
as we AA, it will be unnecessary.