the problem in PR98863.
> I won't object further though, so yeah, please go ahead.
The core issue there was memory-usage, that's unlikely going to be
worse with this patch.
I've pushed it to trunk and will keep an eye on our testers that
cover WRF.
Thanks,
Richard.
> R
ah, please go ahead.
Richard
> Thanks,
> Richard.
>
> From d6f57f72fbbdb832b33e4ba5ccbf60a8d90ea264 Mon Sep 17 00:00:00 2001
> From: Richard Biener
> Date: Mon, 19 Feb 2024 11:10:50 +0100
> Subject: [PATCH] rtl-optimization/54052 - RTL SSA PHI insertion compile-time
>
> as part of the PR, since it's the obvious way of applying liveness
> once per block rather than once per edge. But I think it was more
> just sheer weight of numbers.
Note at least this (see below for the actual patch for trunk) is
in the linear part, so it shouldn't trigger any quadra
Richard Biener writes:
> On Mon, 19 Feb 2024, Richard Sandiford wrote:
>
>> Richard Biener writes:
>> > The following tries to address the PHI insertion compile-time hog in
>> > RTL fwprop observed with the PR54052 testcase where the loop computing
>> > the "unfiltered" set of variables possibly
On Mon, 19 Feb 2024, Richard Sandiford wrote:
> Richard Biener writes:
> > The following tries to address the PHI insertion compile-time hog in
> > RTL fwprop observed with the PR54052 testcase where the loop computing
> > the "unfiltered" set of variables possibly needing PHI nodes for each
> >
Richard Biener writes:
> The following tries to address the PHI insertion compile-time hog in
> RTL fwprop observed with the PR54052 testcase where the loop computing
> the "unfiltered" set of variables possibly needing PHI nodes for each
> block exhibits quadratic compile-time and memory-use.
>
>
The following tries to address the PHI insertion compile-time hog in
RTL fwprop observed with the PR54052 testcase where the loop computing
the "unfiltered" set of variables possibly needing PHI nodes for each
block exhibits quadratic compile-time and memory-use.
Instead of only pruning the set of
