On Sat, Oct 17, 2026 at 12:46:18PM +0200, Jakub Jelinek wrote: > I guess I can live with that. Would be useful to check if something > later fixes it up (and moves the NOTE_INSN_BEGIN_BLOCK where it should > be and/or equivalently creates a separate bb from that insn only and > then merges them).
Nothing has to fix it up. construct_init_block makes the init block from NEXT_INSN (get_insns ()) to get_last_insn (), and create_basic_block_structure emits the NOTE_INSN_BASIC_BLOCK before that head. The load is emitted right after get_insns (), so it is the first insn of the init block, after the bb note. No separate bb is created. The expand dump of main in 20021015-1.c at -O2 (the expand_phi_nodes path) shows it: (note 1 0 8 NOTE_INSN_DELETED) (note 8 1 4 2 [bb 2] NOTE_INSN_BASIC_BLOCK) (insn 4 8 5 2 (set (reg:SI 201) (const:SI (unspec:SI [...] UNSPEC_GP)))) (insn 5 4 6 2 (clobber (reg:SI 2 $2))) (insn 6 5 2 2 (clobber (reg:SI 3 $3))) (note 2 6 10 2 NOTE_INSN_FUNCTION_BEG) The assign_parms path (fx in 930603-1.c) and the entry_of_function () path (pr125582.c) give the same layout: bb note, $gp load, clobbers, then the rest of the init block. All three compile with -fchecking at -O0 and -O2. v3 follows with expand_phi_nodes in the comment and the commit message. Julius Am Sa., 17. Okt. 2026 um 10:46 Uhr schrieb Jakub Jelinek <[email protected]>: > > On Sat, Oct 17, 2026 at 10:37:50AM +0000, Julius Bairaktaris wrote: > > gentle ping on this one. Is keeping get_insns () for the > > expand_phi_nodes case fine with you? If so, I'll send a v3 that > > I guess I can live with that. Would be useful to check if something > later fixes it up (and moves the NOTE_INSN_BEGIN_BLOCK where it should > be and/or equivalently creates a separate bb from that insn only and > then merges them). > > > names expand_phi_nodes in the comment. If you'd prefer another way, > > I'm happy to change it. > > Jakub >
