> On Jan 11, 2023, at 2:52 PM, Segher Boessenkool wrote: > > Hi Paul, > > On Tue, Jan 10, 2023 at 02:39:34PM -0500, Paul Koning via Gcc wrote: >> In pdp11.md I have: >> >> (define_insn_and_split "addhi3" >> [(set (match_operand:HI 0 "nonimmediate_operand" "=rR,rR,Q,Q") >> (plus:HI (match_operand:HI 1 "general_operand" "%0,0,0,0") >> (match_operand:HI 2 "general_operand" "rRLM,Qi,rRLM,Qi")))] >> "" >> "#" >> "reload_completed" >> [(parallel [(set (match_dup 0) >> (plus:HI (match_dup 1) (match_dup 2))) >> (clobber (reg:CC CC_REGNUM))])] >> "" >> [(set_attr "length" "2,4,4,6")]) >> >> While compiling libgcc2.c I see this RTL in the .ira dump file: >> >> (insn 49 48 53 5 (set (reg/f:HI 136) >> (plus:HI (reg/f:HI 5 r5) >> (const_int -8 [0xfffffffffffffff8]))) "../../../../../gcc/libgcc/libgcc2.c":276:4 68 {addhi3} >> (expr_list:REG_EQUIV (plus:HI (reg/f:HI 5 r5) >> (const_int -8 [0xfffffffffffffff8])) >> (nil))) > > What hard register was assigned by IRA to r136? It shows this in the > .ira dump file, search for "Disposition:". Disposition: 3:r25 l0 mem 40:r26 l0 4 51:r31 l0 mem 47:r35 l0 mem 42:r45 l0 2 18:r47 l0 mem 38:r52 l0 mem 34:r54 l0 mem 29:r64 l0 2 21:r80 l0 0 15:r88 l0 0 2:r99 l0 0 19:r102 l0 mem 5:r103 l0 mem 31:r110 l0 0 44:r114 l0 0 41:r115 l0 mem 46:r116 l0 0 28:r117 l0 mem 33:r118 l0 0 20:r119 l0 2 14:r120 l0 2 1:r121 l0 2 0:r122 l0 mem 9:r123 l0 mem 8:r124 l0 mem 55:r125 l0 0 53:r126 l0 mem 54:r129 l0 0 52:r135 l0 0 49:r136 l0 5 48:r137 l0 4 50:r139 l0 0 45:r145 l0 mem 43:r146 l0 0 39:r147 l0 0 36:r148 l0 5 35:r149 l0 4 37:r151 l0 0 32:r157 l0 mem 30:r158 l0 0 27:r159 l0 0 25:r160 l0 mem 26:r161 l0 0 24:r164 l0 0 22:r165 l0 mem 23:r166 l0 0 16:r170 l0 mem 17:r171 l0 0 11:r175 l0 0 13:r176 l0 2 12:r177 l0 2 10:r178 l0 0 6:r179 l0 mem 7:r180 l0 0 4:r184 l0 0 so R5, if I read that correctly. Which makes sense given that the input operand is R5. > >> Then in the .reload dump it appears this way: >> >> (insn 49 48 53 5 (set (reg/f:HI 5 r5 [136]) >> (plus:HI (reg/f:HI 6 sp) >> (const_int 40 [0x28]))) "../../../../../gcc/libgcc/libgcc2.c":276:4 68 {addhi3} >> (expr_list:REG_EQUIV (plus:HI (reg/f:HI 5 r5) >> (const_int -8 [0xfffffffffffffff8])) >> (nil))) >> >> which obviously causes an ICE because that RTL doesn't meet the constraints. > > Before reload it did not have operands[0] and operands[1] the same, > already? No, and given that it's an addhi3 pattern that is fine before reload. It's reload that has to make them match because the machine instruction is two operand. >> This happens only when LRA is used. >> >> I also see this in the .reload file, but I don't know what it means: >> >> Choosing alt 1 in insn 49: (0) rR (1) 0 (2) Qi {addhi3} > > It chose alternative 1 in this instruction, which uses constraints rR > for operands[0], a tie to that for operands[1], and Qi for operands[2]. > >> 1 Non-pseudo reload: reject+=2 >> 1 Non input pseudo reload: reject++ >> Cycle danger: overall += LRA_MAX_REJECT >> alt=0,overall=609,losers=1,rld_nregs=2 >> alt=1: Bad operand -- refuse >> alt=2: Bad operand -- refuse >> alt=3,overall=0,losers=0,rld_nregs=0 > > This is for the *next* instruction. There is a "Choosing alt" thing > for that right after this. That will be alt 3: 1 and 2 are refused, > 0 costs 609, 3 costs 0. > > Reading the LRA dumps needs some getting used to ;-) Indeed. So does that mean the discussion about insn 48 is the interesting one? That goes on for a while: Choosing alt 0 in insn 48: (0) =rR (1) RN {movhi} 1 Spill Non-pseudo into memory: reject+=3 Using memory insn operand 1: reject+=3 1 Non input pseudo reload: reject++ alt=0,overall=13,losers=1,rld_nregs=0 0 Spill pseudo into memory: reject+=3 Using memory insn operand 0: reject+=3 0 Non input pseudo reload: reject++ 1 Non-pseudo reload: reject+=2 1 Non input pseudo reload: reject++ alt=1,overall=22,losers=2 -- refuse 0 Spill pseudo into memory: reject+=3 Using memory insn operand 0: reject+=3 0 Non input pseudo reload: reject++ 1 Non-pseudo reload: reject+=2 1 Non input pseudo reload: reject++ alt=2,overall=22,losers=2 -- refuse 0 Spill pseudo into memory: reject+=3 Using memory insn operand 0: reject+=3 0 Non input pseudo reload: reject++ 1 Non-pseudo reload: reject+=2 1 Non input pseudo reload: reject++ alt=3,overall=22,losers=2 -- refuse 0 Spill pseudo into memory: reject+=3 Using memory insn operand 0: reject+=3 0 Non input pseudo reload: reject++ 1 Non-pseudo reload: reject+=2 1 Non input pseudo reload: reject++ alt=4,overall=22,losers=2 -- refuse 0 Spill pseudo into memory: reject+=3 Using memory insn operand 0: reject+=3 0 Non input pseudo reload: reject++ 1 Non-pseudo reload: reject+=2 1 Non input pseudo reload: reject++ alt=5,overall=22,losers=2 -- refuse 0 Spill pseudo into memory: reject+=3 Using memory insn operand 0: reject+=3 0 Non input pseudo reload: reject++ 1 Non-pseudo reload: reject+=2 1 Non input pseudo reload: reject++ alt=6,overall=22,losers=2 -- refuse 0 Spill pseudo into memory: reject+=3 Using memory insn operand 0: reject+=3 0 Non input pseudo reload: reject++ 1 Non-pseudo reload: reject+=2 1 Non input pseudo reload: reject++ alt=7,overall=22,losers=2 -- refuse 1 Non-pseudo reload: reject+=2 1 Non input pseudo reload: reject++ Cycle danger: overall += LRA_MAX_REJECT alt=8,overall=609,losers=1,rld_nregs=1 alt=9,overall=0,losers=0,rld_nregs=0 >> Any ideas? I ran into this when trying to make LRA the default for this target. > > Please show *all* relevant things in the reload dump file? Everything > about insn 49 or any insn added to reload it, for example. I didn't see anything added to 49, but I'm not sure if I would necessarily recognize it. One observation is that the previous and next insns numbers are 48 and 53 in the IRA and Reload dumps both. Attached is a .i file produced from the failing compile, with unneeded parts removed. It's not really tiny but not all that large. It consistently shows the failure using a pdp11-aout targeted GCC built from yesterday's code, when using -O2 or -Os and -mlra. It doesn't fail with -O1 or if -mlra is omitted (defaulting, in the currently committed code, to old reload). paul