AAPotentialConstantValues now works for PHI and Load by simply examinig
AAPotentialValues for the instruction itself.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/test/Transforms/Attributor/value-simplify.ll | ||
---|---|---|
191 | This optimization was a fluke. Now that the constant vaules of %phi-not-same are exposed, %select-not-same-undef is no longer simplified to a single value. This needs further simplification using constant values in getAssumedSimplified(), similar to how AAPotentialConstantValues looks at the constant values of each operand. |
LG.
Can you maybe add a potential value test that checks we can fold icmp eq %l, 15 if we know %l = load ... is either 14 or 16. Just to get "more direct" coverage.
llvm/lib/Transforms/IPO/AttributorAttributes.cpp | ||
---|---|---|
1407 | You can add that no values implies it's assumed dead (for now). | |
9485 | Nit: For consistency with the rest of the file we should probably omit the "=" in the comments. | |
9523–9525 | Nit: Add the braces if the alternative has them. | |
llvm/test/Transforms/Attributor/value-simplify.ll | ||
191 | I wouldn't call it fluke but it's unclear what the right result here is. I recently made AAPotentialValues keep selects and phis if it couldn't optimize them into a single value, which is what most users want. However, I can see that for constants a list of values might be more valuable (pun intended). |
I tried adding a test with a conditional branch and two stores that reach the same load. But the log shows that AAPotentialConstantValues is never created, and hence the icmp is never simplified. It's not clear to me about when is it that AAPotentialConstantValues is actually consulted by the Attributor. Perhaps getSingleValue() or getAssumedSimplified() needs to do that?
I have been looking at this a bit, and I am not sure why AAPotentialConstantValues needs to exist as a separate attribute. Most of its optimizations can be folded into AAPotentialValuesImpl::simplifyInstruction(). For example, an icmp can be optimized if any one operand or both are known to be undef, or when both operands are known to have constant potential values. This can be checked inside simplifyInstruction() by simply moving most of the internals there from AAPotentialConstantValues. If a client needs to know if all potential values are constants, that can be easily arranged without needing a separate attribute.
You can add that no values implies it's assumed dead (for now).