This is an archive of the discontinued LLVM Phabricator instance.

[InstCombine] Convert binop(phi, v) to phi(binop) for constant phi operands
Needs RevisionPublic

Authored by Carrot on Dec 20 2021, 3:27 PM.

Details

Summary

If we have

%p = phi  [c1, pred1], [c2, pred2]
%v = add %p, %op

We'll generate immediate materialization instructions in predecessors. We
can directly fold them into ALU instructions and create phi instruction for
the ALU results.

pred1:
  %op1 = add c1, %op 
  br %bb 
pred2:
  %op2 = add c2, %op 
  br %bb 
bb: 
  %v = phi [%op1, pred1], [%op2, pred2]

Diff Detail

Unit TestsFailed

Event Timeline

Carrot created this revision.Dec 20 2021, 3:27 PM
Carrot requested review of this revision.Dec 20 2021, 3:27 PM
Herald added a project: Restricted Project. · View Herald TranscriptDec 20 2021, 3:27 PM

immediate materialization instructions

There is no such thing in IR, so this sounds like it should be a back-end backtransform?

immediate materialization instructions

There is no such thing in IR, so this sounds like it should be a back-end backtransform?

Although it is not explicitly expressed in LLVM IR, it must be setup in predecessors later.
Back end transformation should also be doable, but is it worth a new back end pass?

This reminds me of the SpeculateAroundPhis pass, see D37467 and D104099.

Carrot added a comment.EditedDec 21 2021, 2:07 PM

This reminds me of the SpeculateAroundPhis pass, see D37467 and D104099.

Right, it is used to solve the same problem, but with simpler implementation. The SpeculateAroundPhis pass can handle more complex cases, but most common cases should be covered by this patch.

On the other hand, this patch doesn't have the problem reported in D104099 because foldOpIntoPhi doesn't split critical edge.

nikic requested changes to this revision.Jan 11 2022, 12:19 AM

I think it's pretty clear that op(phi(c1, c2)) to phi(op(c1), op(c2)) is not the correct canonicalization for the middle-end optimizer, because it increases redundancy. Materialization of phi operands is firmly a backend matter, and this transform should live somewhere in the backend IR pipeline. I do agree that the general idea makes sense if done right (i.e. not overly aggressive, as SpeculateAroundPhis was).

This revision now requires changes to proceed.Jan 11 2022, 12:19 AM

I think it's pretty clear that op(phi(c1, c2)) to phi(op(c1), op(c2)) is not the correct canonicalization for the middle-end optimizer, because it increases redundancy. Materialization of phi operands is firmly a backend matter, and this transform should live somewhere in the backend IR pipeline. I do agree that the general idea makes sense if done right (i.e. not overly aggressive, as SpeculateAroundPhis was).

Agree - I think the first test diff (shrinkLogicAndPhi1) is the inverse of what -simplifycfg would try to do, so this is too general. Alternative patches that should solve the motivating bug are proposed in D115914 and D117110

Just want to point out that this optimization does not introduce redundancy with diamond shape CFG and care needs to be taken for triangular shaped CFG. it might also increase code size though depending on the target -- it might need to be guarded against size optimization.

Some test case change analysis:

  1. llvm/test/Transforms/InstCombine/zext-or-icmp.ll -- the patch produces much *cleaner* code
  1. llvm/test/Transforms/InstCombine/rem.ll --- need to examine why the patch blocks the intended hoisting transformation. Note that the intended the transformation may introduce redundancy depending on branch probablities.
  1. llvm/test/Transforms/InstCombine/phi.ll --- the patch produces *cleaner* and *neater* code
  1. llvm/test/Transforms/InstCombine/not-add.ll -- the patch produces cleaner code with less redundancy
  1. llvm/test/Transforms/InstCombine/narrow.ll -- this is the case Sanjay pointed out. There is potential redundancy introduced with the patch.

If issue in 5) can be detected, all in all this patch can improve IR quality.

lebedev.ri resigned from this revision.Jan 12 2023, 4:57 PM

This review may be stuck/dead, consider abandoning if no longer relevant.
Removing myself as reviewer in attempt to clean dashboard.

Herald added a project: Restricted Project. · View Herald TranscriptJan 12 2023, 4:57 PM
Herald added a subscriber: StephenFan. · View Herald Transcript