Alexey Zhikhartsev via llvm-dev
2021-Apr-27 18:15 UTC
[llvm-dev] BasicAA depending on PhiValues analysis
Hi all, I encountered a problem where an optimization that uses BasicAA is very fragile due to BasicAA's "weak" reliance on the PhiValues analysis. The whole story is this: our team is in the process of upgrading to the newest version of LLVM, and I discovered that on the newest LLVM, Global Value Numbering doesn't apply an important optimization anymore. A little bit of background: GVN depends on Basic Alias Analysis, and BasicAA depends on PhiValues. However, the dependence between GVN and AA is "strong": getAnalysis<AAResultsWrapperPass>().getAAResults() Whereas between BasicAA and PhiValues it is "weak" (note "IfAvailable"): auto *PVWP = getAnalysisIfAvailable<PhiValuesWrapperPass>(); So, in the old LLVM, BasicAA that runs before GVN, happens to find cached PhiValues analysis, gives good results to GVN, and GVN applies the optimization. But on the new LLVM, BasicAA doesn't have PhiValues, gives poor results to GVN, and GVN gives up. It looks to me that whether BasicAA gets its hands on PhiValues is almost entirely up to chance, which makes the clients of BasicAA very fragile, meaning that it's hard to be sure if an optimization you need will get applied. I see the discussion in https://reviews.llvm.org/D44564 but I'm pretty much out of my depth there and I'm not sure if a solution to the problem above has been mentioned. Maybe the new pass manager has this problem solved? Anyhow, I would appreciate any input, thank you in advance. Best, Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210427/4150be64/attachment.html>
John Brawn via llvm-dev
2021-Apr-30 16:18 UTC
[llvm-dev] BasicAA depending on PhiValues analysis
>From what I remember, and from looking at the code, the way things are supposed to work is:* GVN uses MemoryDependenceAnalysis * MemoryDependenceAnalysis has PhiValuesWrapperPass as a required dependency * The alias analysis used by MemoryDependenceAnalysis therefore makes use of PhiValuesWrapperPass I don't remember if the alias analysis used by MemoryDependenceAnalysis also getting and using the result of PhiValuesWrapperPass was an intended consequence of this or not. Possibly it would make sense for GVN to directly require PhiValuesWrapperPass, which may fix the problem. John ________________________________ From: Alexey Zhikhartsev <alexey.zhikhar at gmail.com> Sent: 27 April 2021 19:15 To: via Llvm-dev <llvm-dev at lists.llvm.org> Cc: John Brawn <John.Brawn at arm.com>; dberlin at dberlin.org <dberlin at dberlin.org> Subject: BasicAA depending on PhiValues analysis Hi all, I encountered a problem where an optimization that uses BasicAA is very fragile due to BasicAA's "weak" reliance on the PhiValues analysis. The whole story is this: our team is in the process of upgrading to the newest version of LLVM, and I discovered that on the newest LLVM, Global Value Numbering doesn't apply an important optimization anymore. A little bit of background: GVN depends on Basic Alias Analysis, and BasicAA depends on PhiValues. However, the dependence between GVN and AA is "strong": getAnalysis<AAResultsWrapperPass>().getAAResults() Whereas between BasicAA and PhiValues it is "weak" (note "IfAvailable"): auto *PVWP = getAnalysisIfAvailable<PhiValuesWrapperPass>(); So, in the old LLVM, BasicAA that runs before GVN, happens to find cached PhiValues analysis, gives good results to GVN, and GVN applies the optimization. But on the new LLVM, BasicAA doesn't have PhiValues, gives poor results to GVN, and GVN gives up. It looks to me that whether BasicAA gets its hands on PhiValues is almost entirely up to chance, which makes the clients of BasicAA very fragile, meaning that it's hard to be sure if an optimization you need will get applied. I see the discussion in https://reviews.llvm.org/D44564 but I'm pretty much out of my depth there and I'm not sure if a solution to the problem above has been mentioned. Maybe the new pass manager has this problem solved? Anyhow, I would appreciate any input, thank you in advance. Best, Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210430/a3eed674/attachment.html>