On Tue, 2 Apr 2019, Richard Sandiford wrote:
> Richard Sandiford writes:
> > Richard Biener writes:
> >> After the fix to RPO VN in loop header copying DF via RTL invariant
> >> motion takes 50% of the compile-time for the second testcase in
> >> PR46590. This is caused by the DF live problem i
Richard Sandiford writes:
> Richard Biener writes:
>> After the fix to RPO VN in loop header copying DF via RTL invariant
>> motion takes 50% of the compile-time for the second testcase in
>> PR46590. This is caused by the DF live problem iterating over
>> all dirty blocks for the local problem
On April 1, 2019 4:13:28 PM GMT+02:00, Richard Sandiford
wrote:
>Richard Biener writes:
>> After the fix to RPO VN in loop header copying DF via RTL invariant
>> motion takes 50% of the compile-time for the second testcase in
>> PR46590. This is caused by the DF live problem iterating over
>> a
Richard Biener writes:
> After the fix to RPO VN in loop header copying DF via RTL invariant
> motion takes 50% of the compile-time for the second testcase in
> PR46590. This is caused by the DF live problem iterating over
> all dirty blocks for the local problem which is all blocks of
> the func
After the fix to RPO VN in loop header copying DF via RTL invariant
motion takes 50% of the compile-time for the second testcase in
PR46590. This is caused by the DF live problem iterating over
all dirty blocks for the local problem which is all blocks of
the function because while loop-invarian
