<div dir="ltr"><div><div><div>There are at least 3 active proposals to add reassociative optimizations in IR:<br>[1] <a href="https://reviews.llvm.org/D41574">D41574 </a>- a new pass for reassociation/factoring<br>[2] <a href="https://reviews.llvm.org/D46336">D46336</a> - enhance -instcombine to do more reassociation/factoring<br>[3] <a href="https://reviews.llvm.org/D45842" rel="noreferrer" target="_blank">D45842</a> - add to the existing -reassociate pass to enable factoring<br><br></div>Here's a basic motivating example that we fail to optimize:<br><a href="https://godbolt.org/g/64NmJM">https://godbolt.org/g/64NmJM</a><br><a href="https://rise4fun.com/Alive/wec">https://rise4fun.com/Alive/wec</a><br></div><br></div><div>Currently, responsibility for reassociative transforms is split between -reassociate and -instcombine. I don't know if that split is intentional or just how the code evolved. Debug stats for test-suite compiled with -O3 show:<br>78K "reassociations" by -instcombine.<br>58K "reassociated" by -reassociate<br></div><div><br>A debug stat with D45842 showed that that transform fired 1.3K times.<br><br></div><div>Keep in mind that instcombine runs 1st, runs to fixed-point, and runs 8 times in the -O2 pipeline. Reassociate runs 1 time and doesn't run to fixed-point. Some transforms are unique to 1 pass or the other, but there is some overlapping functionality already there.<br><br></div><div>So the questions are: <br>1. How do we solve these remaining reassociation optimizations?<br></div><div>2. Do we want to consolidate existing reassociation transforms in 1 pass or is there value in splitting the folds across multiple passes?<br></div><br><div><br><br></div></div>