early-remat: Resync with new DF postorders [PR109940]

When I wrote early-remat, the DF_FORWARD block order was a postorder
of a reverse/backward walk (i.e. of the inverted cfg), rather than a
reverse postorder of a forward walk.  A postorder of a backward walk
lacked the important property that dominators come before the blocks
they dominate; instead it ensures that postdominators come after
the blocks that they postdominate.

The DF_BACKWARD block order was similarly a postorder of a forward
walk.  Since early-remat wanted a standard postorder and reverse
postorder with normal dominator properties, it used the DF_BACKWARD
order instead of the DF_FORWARD order.

g:53dddbfeb213ac4ec39f fixed the DF orders so that DF_FORWARD was
an RPO of a forward walk and so that DF_BACKWARD was an RPO of a
backward walk.  This meant that iterating backwards over the
DF_BACKWARD order had the exact problem that the original DF_FORWARD
order had, triggering a flurry of ICEs for SVE.

This fixes the build with SVE enabled.  It also fixes an ICE
in g++.target/aarch64/sve/pr99766.C with normal builds.  I've
included the test from the PR as well, for extra coverage.

gcc/
	PR rtl-optimization/109940
	* early-remat.cc (postorder_index): Rename to...
	(rpo_index): ...this.
	(compare_candidates): Sort by decreasing rpo_index rather than
	increasing postorder_index.
	(early_remat::sort_candidates): Calculate the forward RPO from
	DF_FORWARD.
	(early_remat::local_phase): Follow forward RPO using DF_FORWARD,
	rather than DF_BACKWARD in reverse.

gcc/testsuite/
	* gcc.dg/torture/pr109940.c: New test.

0 files changed, 0 insertions, 0 deletions