This is an archive of the discontinued LLVM Phabricator instance.

[Attributor] Reach optimistic fixpoint in AAValueSimplify when the value is constant or undef
ClosedPublic

Authored by uenoku on Dec 24 2019, 4:03 AM.

Details

Summary

As discussed in D71799, we have found that it is more useful to reach an optimistic fixpoint in AAValueSimpify when the value is constant or undef.

Diff Detail

Event Timeline

uenoku created this revision.Dec 24 2019, 4:03 AM
Herald added a reviewer: sstefan1. · View Herald Transcript
Herald added a project: Restricted Project. · View Herald Transcript
baziotis added a subscriber: baziotis.EditedDec 24 2019, 4:47 AM

I'm not super familiar with AAValueSimplify, but here's a perspective: The conceptual idea is that AAValueSimplify returns optimistic fixpoint if it actually changed the value.
We may not want to break that. Instead, keep the "contract" to whoever is using it to: Use that assuming that if you got a known value, then it means it changed from the original.
The implication being: Check for yourself if it is something that won't change (i.e. it is constant). One one hand that puts more logistics to the user. On the other hand, the code may become more
understandable as the check for constant (or undef) happens with regular LLVM values that anyone who is not familiar with the Attributor can understand what is happening (i.e. from looking the code, the reader knows that if the value is constant, it won't even go through AAValueSimplify).
Edit: Well, AFAIK obviously the user of AAValueSimplify will be another part of the Attributor, so the reader is supposed to be familiar with it. But still, I think the fact that we'll go through AAValueSimplify only if we have some kind of complicated value is makes the code more understandable.

This revision is now accepted and ready to land.Dec 24 2019, 2:01 PM

I'm not super familiar with AAValueSimplify, but here's a perspective: The conceptual idea is that AAValueSimplify returns optimistic fixpoint if it actually changed the value.
We may not want to break that. Instead, keep the "contract" to whoever is using it to: Use that assuming that if you got a known value, then it means it changed from the original.
The implication being: Check for yourself if it is something that won't change (i.e. it is constant). One one hand that puts more logistics to the user. On the other hand, the code may become more
understandable as the check for constant (or undef) happens with regular LLVM values that anyone who is not familiar with the Attributor can understand what is happening (i.e. from looking the code, the reader knows that if the value is constant, it won't even go through AAValueSimplify).
Edit: Well, AFAIK obviously the user of AAValueSimplify will be another part of the Attributor, so the reader is supposed to be familiar with it. But still, I think the fact that we'll go through AAValueSimplify only if we have some kind of complicated value is makes the code more understandable.

Sorry, I didn't see your comment at first.

AAValueSimplify computes the best simplified value, it is considered "assumed" as long as we cannot prove it is correct, once that happens it is "known". In case of a constant (or undef which should actually be a constant), there is not much to do as it is the most simplified version (in almost all cases), thus we know it is a correct value.

@uenoku Thinking about it again, we could also not set the "invalid" bit when we call indicatePessimisticFixpoint and instead just set SimplifiedAssociatedValue to the associated one and make it an optimistic fixpoint.

llvm/lib/Transforms/IPO/Attributor.cpp
4183

Nit: I think Undef is a constant making the second part of the conditional obsolete.

Sorry, I didn't see your comment at first.

No problem.

AAValueSimplify computes the best simplified value, it is considered "assumed" as long as we cannot prove it is correct, once that happens it is "known". In case of a constant (or undef which should actually be a constant), there is not much to do as it is the most simplified version (in almost all cases), thus we know it is a correct value.

Aha yes. Note that this was my initial interpretation as well, hence why I did not understand why was happening what was happening before this change (e.g. at the end of https://reviews.llvm.org/D71799#1795477).
But then, @uenoku's explanation regarding that "simplified" implies "changed" made me think of a different perspective. All in all, since we agree on a common statement of what AAValueSimplified does, everything's ok. :)

uenoku updated this revision to Diff 235247.Dec 24 2019, 8:33 PM

Address comment.

uenoku added a comment.EditedDec 24 2019, 8:44 PM

Sorry, I didn't see your comment at first.

No problem.

AAValueSimplify computes the best simplified value, it is considered "assumed" as long as we cannot prove it is correct, once that happens it is "known". In case of a constant (or undef which should actually be a constant), there is not much to do as it is the most simplified version (in almost all cases), thus we know it is a correct value.

Aha yes. Note that this was my initial interpretation as well, hence why I did not understand why was happening what was happening before this change (e.g. at the end of https://reviews.llvm.org/D71799#1795477).
But then, @uenoku's explanation regarding that "simplified" implies "changed" made me think of a different perspective. All in all, since we agree on a common statement of what AAValueSimplified does, everything's ok. :)

In the beginning, I didn't think it was useful to regard constant as a known simplified value because you can trivially check the associated value. But anyway I agree that regarding constant as "simplified" will be more natural and concise.

uenoku updated this revision to Diff 235250.Dec 24 2019, 9:12 PM

Small fix.

This revision was automatically updated to reflect the committed changes.