On 1/8/24 09:59, Richard Sandiford wrote:
This is a bit of a hopeful stab, but is the problem that recog_data still
had the previous contents of insn 3674, and so extract_insn_cached wrongly
thought that it doesn't need to do anything? If so, does something like:
diff --git a/gcc/recog.cc b/gcc/recog.cc
index a6799e3f5e6..8ba63c78179 100644
--- a/gcc/recog.cc
+++ b/gcc/recog.cc
@@ -267,6 +267,8 @@ validate_change_1 (rtx object, rtx *loc, rtx new_rtx, bool
in_group,
case invalid. */
changes[num_changes].old_code = INSN_CODE (object);
INSN_CODE (object) = -1;
+ if (recog_data.insn == object)
+ recog_data.insn = nullptr;
}
num_changes++;
fix it? I suppose there's an argument that this belongs in whatever code
sets INSN_CODE to a new nonnegative value (so recog_level2 for RTL-SSA).
But doing it in validate_change_1 seems more robust, since anything
calling that function is considering changing the insn code.
Nope, doesn't help at all. I'd briefly put a reset of the INSN_CODE
and a call to recog_memoized in the costing path of rtl-ssa to see if
that would allow things to move forward, but it failed miserably.
I'll pass along the .i file separately. Hopefully it'll fail for you
and you can debug. But given failure depends on stale bits in
recog_data, it may not.
Jeff
