This patch provides an implementation of AAPotentialValues.
Details
Diff Detail
Event Timeline
I think we should limit the "entry point" for this AA. It seems we can only improve AAValueSimplify when the instruction we look at is a conditional, right? So if it is, we ask AAPotentialValues, otherwise we do not. Other users of AAPotentialValues will emerge but for this use we can restrict it to the case we can actually fold the multiple values in to a single constant. Other users might be OK with multiple values, e.g., to determine a common property.
llvm/lib/Transforms/IPO/AttributorAttributes.cpp | ||
---|---|---|
7336 | Add a TODO that we should look at nsw and nuw to help, e.g., to exclude certain results that cannot happen without creating undef. Similarly, division by undef should not make the result invalid but simply skip this operand pair. | |
7351 | Why do we have the copy sometimes and sometimes not? Are the operators missing in the APInt class? If so, we should fix that in a pre-patch first. | |
7399 | Here and below we should avoid looking at RHS if LHSAA is invalid. | |
7405 | Please add a type here, and (or at least) make it a const reference. Also other places. | |
7413 | We should give up once both are true. |
llvm/include/llvm/Transforms/IPO/Attributor.h | ||
---|---|---|
3490 ↗ | (On Diff #284340) | I thought PVS.IsValidState in operators violate access specifier but that was my mistake, sorry. |
llvm/lib/Transforms/IPO/AttributorAttributes.cpp | ||
---|---|---|
7336 | I understand you mean that we can assume the operation result is not a poison value or undef and that we can ignore such operand pair. Is that right? |
llvm/lib/Transforms/IPO/AttributorAttributes.cpp | ||
---|---|---|
7336 | Yes and no. So there are two things.
Have such a bool reference argument makes sense, maybe call it "SkipOperation" or something and pass it through to the caller so we can just go ahead and ignore this combination of LHS/RHS. |
llvm/lib/Transforms/IPO/AttributorAttributes.cpp | ||
---|---|---|
7351 |
Yes, there are only compound assignment operators for some opcodes. I'll make a new patch for this. |
llvm/lib/Transforms/IPO/AttributorAttributes.cpp | ||
---|---|---|
7351 | Why do we want the assignment operators? Why not just LHS + RHS? |
I think this patch is good. We should try to limit the queries to useful ones. We can do that after though. Maybe we check the instruction opcode in getAssumedConstantInt to make sure we only run this for Instructions that can fold multiple values into a single one, so far probably only compare instructions. We could also add a separate method that determines if this AAValueSimplify-like AA is good for a certain position or not. Either way, that should result in way less iterations without loosing any optimizations. Feel free to give it a try :)
LGTM.
llvm/lib/Transforms/IPO/AttributorAttributes.cpp | ||
---|---|---|
7419 | You can indicate a pessimistic fixpoint here. It's an i1 which can be true and false :) |
llvm/lib/Transforms/IPO/AttributorAttributes.cpp | ||
---|---|---|
7419 | If I indicate a pessimistic fixpoint, the state becomes invalid. If not, the state becomes {0,1}. I think this difference makes the deduction weaker. For example, the expected value simplification is not achieved in the case @potential_test3 in potential.ll. define i32 @foo(i1 %c) { %ret = zext i1 %c to i32 ret i32 %ret } |
llvm/lib/Transforms/IPO/AttributorAttributes.cpp | ||
---|---|---|
7419 | I thought about this again and I noticed that this kind of analysis can (should) be done by AAValueConstantRange. |
Can you split this off into an NFC patch. Will make this one much simpler.