On Thu, 8 Oct 2026, Julius Bairaktaris wrote: > On Thu, 8 Oct 2026, Richard Biener wrote: > > So the issue does look more prevalent. But! We're dealing with > > sequences here, not with "basic-blocks", so mips should > > probably be using emit_insn_before instead of add_insn_before? > > mips16_gp_pseudo_reg currently uses emit_insn_after (set, scan), which > ends in add_insn_after, and that writes BB_END of the non-BB_RTL block. > > I tried emit_insn_before on the first real insn instead. That works > for the testcase, because add_insn_before only compares against > BB_HEAD and does not touch BB_END. > > But a plain swap crashed 7 other tests in mips.exp: when no real insn > has been emitted yet, NEXT_INSN (scan) is NULL. Keeping > emit_insn_after for that case fixes it: > > rtx_insn *insn = (NEXT_INSN (scan) > ? emit_insn_before (set, NEXT_INSN (scan)) > : emit_insn_after (set, scan)); > > With that, the testcase passes and mips.exp shows no other changes. > > Should I send this as v2 instead of the emit-rtl.cc change? If the > more general problem needs a bigger fix in the expander, I'd rather > leave that to you or Jakub: I used Claude for this, so I can only > send small changes under the AI policy.
Well, I think papering over the issue like you did feels wrong. But I'm not exactly an expert here either. But yes, it seems emit_insn_* will eventually dispatch to add_insn_* again and there's no "BB free" RTL emission anymore? So keeping the GIMPLE IL looks wrong then? Richard. > Julius > -- Richard Biener <[email protected]> SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Stefan Gaiser, Jochen Jaser, Abhinav Puri; (HRB 36809, AG Nuernberg)
