If folding two PHI operands of a binary op into predecessors could simplify IR, make the transformation in InstCombine pass.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Unit Tests
Time | Test | |
---|---|---|
70 ms | x64 debian > LLVM.Bindings/Go::go.test |
Event Timeline
This revision handles the simple case (as shown in llvm/test/Transforms/InstCombine/fold-phi-of-binary-op.ll).
Send it out to collect feedback, and I will need to iterate and enhance it with more test cases (e.g., or instructions in return block in https://godbolt.org/z/79ehxzW9f), or other test cases in llvm/test/Transforms/SROA/alloca-struct.ll
p.s. I might need to delete alloca-struct.ll itself later.
this seems reasonable, I like this approach
needs more test coverage though
llvm/lib/Transforms/InstCombine/InstructionCombining.cpp | ||
---|---|---|
1292 | I think we should directly call SimplifyInstruction(), no need to constrict this to or | |
1310 | need a test for this | |
1321 | need a test for this | |
1335 | need a test for this | |
1339 | early return is nicer | |
1339 | I think even if we only simplify one of the two values it's worth it, don't need to constrict to this to requiring both values to be simplified. can be a TODO though | |
1366 | can we use the value above from the call to couldSimplifyInBasicBlock()? | |
4478 | unintentional change? perhaps some editor config needs to be changed? | |
llvm/test/Transforms/InstCombine/fold-phi-of-binary-op.ll | ||
1 | regarding the file name, it's more of a "binary-op-of-phi" than "phi-of-binary-op" | |
9 | it'd be nice to simplify the IR a bit, e.g. simplify the name, remove dso_local, local_unnamed_addr, nocapture, etc | |
llvm/test/Transforms/InstCombine/zext-or-icmp.ll | ||
49 | this test no longer tests https://reviews.llvm.org/D30781, we need to modify this test somehow select i1 %param, i32 33, 0 instead of %m.011 = phi ...? |
llvm/lib/Transforms/InstCombine/InstructionCombining.cpp | ||
---|---|---|
1339 | sorry, we should only do this if the phi block dominates the block where we don't simplify the value to avoid adding an instruction for another code path that doesn't reach the phi block |
thanks everyone for the feedback!
carrot@ had a fix for another issue (in https://reviews.llvm.org/D116058) that has overlap with this one, but covering more cases like https://godbolt.org/z/or7W1b7eE and https://godbolt.org/z/MqTh5Te9c
I'm going to hold this for a while; hopefully after https://reviews.llvm.org/D116058 is in, this patch is not needed.
I don't think D116058 is viable (and I'll comment there too).
This patch seems ok, but it's both too restrictive (only works with 'or') and potentially more costly than necessary (at least as a first step, we can check for constants instead of trying to simplify generally and fix the motivating tests). I put up an alternate patch: D117110 .
thanks for the inputs! I agree that this patch is way too restrictive and not using the efficient matcher.
I went through D117110 and learnt another way; only has one comment (for my learning) about whether it's idiomatic validate the newly inserted non-constant instruction could be simplified away in later iterations of instr-combine (basically, a stricter condition than only fold constant).
I'll probably revert this and https://reviews.llvm.org/D114832 after download a patch for my own back-up.
actually diff of abandoned revisions are stored somewhere and seems to be available for download. this is good so no need to maintain a local copy.
I think we should directly call SimplifyInstruction(), no need to constrict this to or
and the naming on this function isn't great anyway, it returns a Value* but starts with could