This is an archive of the discontinued LLVM Phabricator instance.

[Attributor] potential constant values for PHI and Load
ClosedPublic

Authored by sameerds on Dec 19 2022, 10:16 PM.

Details

Summary

AAPotentialConstantValues now works for PHI and Load by simply examinig
AAPotentialValues for the instruction itself.

Diff Detail

Event Timeline

sameerds created this revision.Dec 19 2022, 10:16 PM
Herald added a project: Restricted Project. · View Herald Transcript
sameerds requested review of this revision.Dec 19 2022, 10:16 PM
Herald added a reviewer: sstefan1. · View Herald Transcript
Herald added a project: Restricted Project. · View Herald Transcript
sameerds added inline comments.Dec 19 2022, 10:23 PM
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.

jdoerfert accepted this revision.Dec 19 2022, 10:47 PM

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).

This revision is now accepted and ready to land.Dec 19 2022, 10:47 PM

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.

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?

This revision was automatically updated to reflect the committed changes.
sameerds marked 4 inline comments as done.

Submitted without the suggested new test.

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.

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.