On Thu, 31 Aug 2023, Andrew Pinski wrote: > On Thu, Aug 31, 2023 at 5:15?AM Richard Biener via Gcc-patches > <gcc-patches@gcc.gnu.org> wrote: > > > > On Thu, 31 Aug 2023, Filip Kastl wrote: > > > > > > The most obvious places would be right after SSA construction and > > > > before RTL expansion. > > > > Can you provide measurements for those positions? > > > > > > The algorithm should only remove PHIs that break SSA form minimality. > > > Since > > > GCC's SSA construction already produces minimal SSA form, the algorithm > > > isn't > > > expected to remove any PHIs if run right after the construction. I even > > > measured it and indeed -- no PHIs got removed (except for 502.gcc_r, > > > where the > > > algorithm managed to remove exactly 1 PHI, which is weird). > > > > > > I tried putting the pass before pass_expand. There isn't a lot of PHIs to > > > remove at that point, but there still are some. > > > > That's interesting. Your placement at > > > > NEXT_PASS (pass_cd_dce, false /* update_address_taken_p */); > > NEXT_PASS (pass_phiopt, true /* early_p */); > > + NEXT_PASS (pass_sccp); > > > > and > > > > NEXT_PASS (pass_tsan); > > NEXT_PASS (pass_dse, true /* use DR analysis */); > > NEXT_PASS (pass_dce); > > + NEXT_PASS (pass_sccp); > > > > isn't immediately after the "best" existing pass we have to > > remove dead PHIs which is pass_cd_dce. phiopt might leave > > dead PHIs around and the second instance runs long after the > > last CD-DCE. > > Actually the last phiopt is run before last pass_cd_dce:
I meant the second instance of pass_sccp, not phiopt. Richard.
