On 8/17/2022 1:31 AM, Aldy Hernandez via Gcc-patches wrote:
I just have a few high level comments.
On Tue, Aug 16, 2022 at 4:05 PM Richard Biener <rguent...@suse.de> wrote:
The following refactors profitable_path_p in the backward threader,
splitting out parts that can be computed once the exit block is known,
parts that contiguously update and that can be checked allowing
for the path to be later identified as FSM with larger limits,
possibly_profitable_path_p, and final checks done when the whole
path is known, profitable_path_p.
I thought we were removing references to FSM, as they were leftovers
from some previous incarnation. For that matter, I don't think I ever
understood what they are, so if we're gonna keep them, could you
comment what makes FSM threads different from other threads?
FSM refers to the initial implementation from Steve E. IIRC. It was
designed to handle threading backedges in a loop where the path out of
the current iteration would tell us where a multi-way branch in the next
loop iteration would go.
During the integration of Steve's work it was recognized that the
backwards walk was generally a better model and we started moving to the
backwards based threader with the goal of removing the forward threader.
There should be tests in the testsuite which validate that we haven't
lost the key transformation. ssa-thread-backedge.c and pr77445-2.c
The DOM threader has limits? I thought most of those limits were just
due to the fact that it couldn't determine long enough paths? Either
way, I like that we're merging the necessary forward threader bits
here, in preparation for its demise ;-).
The forward threader has structural limitations due to its custom block
copier and CFG update code as well as profitibility limitations.
jeff
