On Thu, Mar 23, 2017 at 4:45 PM, Segher Boessenkool
<seg...@kernel.crashing.org> wrote:
> On Thu, Mar 23, 2017 at 04:16:56PM +0100, Richard Biener wrote:
>> On Thu, Mar 23, 2017 at 3:58 PM, Segher Boessenkool
>> <seg...@kernel.crashing.org> wrote:
>> > The algorithm fwprop uses never reconsiders a possible propagation,
>> > although it could succeed if the def (in the def-use to propagate)
>> > has changed. This causes fwprop to do infinite propagations, like
>> > in the scenario in the PR, where we end up with effectively
>> > B = A
>> > A = B
>> > D = A
>> > where only propagations into the last statement are still tried, and
>> > that loops (it becomes D = B, then back to D = A, etc.)
>> >
>> > Fixing this properly isn't easy; this patch instead limits the number
>> > of propagations performed to the number of uses we originally had,
>> > which is the maximum number of propagations that can be done if there
>> > are no such infinite loops.
>> >
>> > Bootstrapped and regression checked on powerpc64-linux {-m64,-m32};
>> > is this okay for trunk?
>>
>> https://gcc.gnu.org/ml/gcc-patches/2017-02/msg01485.html
>>
>> ?
>
> What about it? That suggestion would make fwprop do *less* useful work,
> while in principle the problem is that it *already* does not enough!
Ok, not knowing a lot about fwprop I take your word for it (but GIMPLE level
forwprop works that way and certainly you can't substitute a def into a use
that is before the def).
> If fwprop actually tried all propagations (and never tried substituting
> X with X, which it currently does), there would be no problem.
To me it looked like fwprop tries to iterate over all propagations but
it iterates over a changing data structure which is why it "oscillates".
But I didn't actually verify that theory (in fact, I just very much disliked
Berns patch give its compile-time cost).
> This patch is a workaround; it makes no difference on pretty much any
> code, except this single testcase (which has undefined behaviour,
> uninitialised variables).
Yeah, your fix looks similar to the other hack I suggested.
Richard.
>
> Segher
