On 8/5/2022 7:58 AM, Richard Biener wrote:
The following adjusts the costing of PHIs to match how I understand
the comment and maybe the original intent. The will be no
non-degenerate PHI nodes remaining on the threaded path but when there
are alternate path exits PHI nodes at their destinations will likely
require extra copies on those edges and that's what we want to account
for.
Jeff added this code long time ago and at least the special-casing
of (just) m_name does not make sense anymore.
Unfortunately this tweaks heuristics enough to make the threader
thread an unfortunate path in libgomp/team.c so that
-Walloca-larger-than diagnoses an allocation of -1 elements. I'm
not 100% sure this condition is impossible so I've added a guard
not allocating zero or "less" stack. There's also an uninit
diagnostic in opts.cc about best_math::m_best_candidate_len that
looks like a false positive but all but this member are initialized
so the patch initializes this one as well to avoid this false
positive.
I have yet to analyze some fallout as well:
FAIL: gcc.dg/uninit-pred-9_b.c bogus warning (test for bogus messages, line 20)
FAIL: gcc.dg/tree-ssa/phi_on_compare-4.c scan-tree-dump-times dom2 "Removing bas
ic block" 1
FAIL: gcc.dg/tree-ssa/pr59597.c scan-tree-dump-times threadfull1 "Registering jump
thread" 4
FAIL: gcc.dg/tree-ssa/pr61839_2.c scan-tree-dump-times evrp "%" 0
FAIL: gcc.dg/tree-ssa/pr61839_2.c scan-tree-dump-times evrp "972195717 % " 0
FAIL: gcc.dg/tree-ssa/pr61839_2.c scan-tree-dump-times evrp "972195717 / " 0
FAIL: gcc.dg/tree-ssa/pr61839_2.c scan-tree-dump-times evrp "__builtin_abort" 1
the early threading fails are because we now account for the mid-exit
PHI copies and early threading has a limit of a single copied insn.
But this testcase was never about threading but VRP which seemingly
regressed meanwhile...
Bootstrapped and tested (with the above FAILs) on
x86_64-unknown-linux-gnu.
Any comments besides the FAILout?
I don't recall adding that code, but I did find it in the archives.
https://gcc.gnu.org/pipermail/gcc-patches/2016-March/443452.html
But even with that and reviewing the PR, I still don't remember much
about this particular chunk of code. I do recall that I was never
actually happy with pr69196 state and that's why we've kept it open all
these years.
It doesn't look like tree-ssa/pr69196 has regressed, so if you're happy
with the patch, I've got no objections.
jeff
