LRA produces RTL not meeting constraint

LRA produces RTL not meeting constraint

[Paul Koning]

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)))

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.  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}
            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

Any ideas?  I ran into this when trying to make LRA the default for this target.

	paul

Re: LRA produces RTL not meeting constraint

[Segher Boessenkool]

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:".

> 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?

> 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 ;-)

> 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.


Segher

Re: LRA produces RTL not meeting constraint

[Paul Koning]

[-- Attachment #1: Type: text/plain, Size: 7483 bytes --]



> On Jan 11, 2023, at 2:52 PM, Segher Boessenkool <segher@kernel.crashing.org> 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


[-- Attachment #2: _mulvdi3.i --]
[-- Type: application/octet-stream, Size: 2937 bytes --]

typedef int SItype __attribute__ ((mode (SI)));
typedef unsigned int USItype __attribute__ ((mode (SI)));

typedef int DItype __attribute__ ((mode (DI)));
typedef unsigned int UDItype __attribute__ ((mode (DI)));

extern DItype __mulvdi3 (DItype, DItype);

  struct DWstruct {SItype high, low;};

typedef union
{
  struct DWstruct s;
  DItype ll;
} DWunion;

DItype
__mulvdi3 (DItype u, DItype v)
{


  const DWunion uu = {.ll = u};
  const DWunion vv = {.ll = v};

  if (__builtin_expect (uu.s.high == uu.s.low >> ((4 * 8) - 1), 1))
    {

      if (__builtin_expect (vv.s.high == vv.s.low >> ((4 * 8) - 1), 1))
 {


   return (DItype) uu.s.low * (DItype) vv.s.low;
 }
      else
 {

   DWunion w0 = {.ll = (UDItype) (USItype) uu.s.low
   * (UDItype) (USItype) vv.s.low};
   DWunion w1 = {.ll = (UDItype) (USItype) uu.s.low
   * (UDItype) (USItype) vv.s.high};

   if (vv.s.high < 0)
     w1.s.high -= uu.s.low;
   if (uu.s.low < 0)
     w1.ll -= vv.ll;
   w1.ll += (USItype) w0.s.high;
   if (__builtin_expect (w1.s.high == w1.s.low >> ((4 * 8) - 1), 1))
     {
       w0.s.high = w1.s.low;
       return w0.ll;
     }
 }
    }
  else
    {
      if (__builtin_expect (vv.s.high == vv.s.low >> ((4 * 8) - 1), 1))
 {


   DWunion w0 = {.ll = (UDItype) (USItype) uu.s.low
   * (UDItype) (USItype) vv.s.low};
   DWunion w1 = {.ll = (UDItype) (USItype) uu.s.high
   * (UDItype) (USItype) vv.s.low};

   if (uu.s.high < 0)
     w1.s.high -= vv.s.low;
   if (vv.s.low < 0)
     w1.ll -= uu.ll;
   w1.ll += (USItype) w0.s.high;
   if (__builtin_expect (w1.s.high == w1.s.low >> ((4 * 8) - 1), 1))
     {
       w0.s.high = w1.s.low;
       return w0.ll;
     }
 }
      else
 {

   if (uu.s.high >= 0)
     {
       if (vv.s.high >= 0)
  {
    if (uu.s.high == 0 && vv.s.high == 0)
      {
        const DItype w = (UDItype) (USItype) uu.s.low
   * (UDItype) (USItype) vv.s.low;
        if (__builtin_expect (w >= 0, 1))
   return w;
      }
  }
       else
  {
    if (uu.s.high == 0 && vv.s.high == (SItype) -1)
      {
        DWunion ww = {.ll = (UDItype) (USItype) uu.s.low
        * (UDItype) (USItype) vv.s.low};

        ww.s.high -= uu.s.low;
        if (__builtin_expect (ww.s.high < 0, 1))
   return ww.ll;
      }
  }
     }
   else
     {
       if (vv.s.high >= 0)
  {
    if (uu.s.high == (SItype) -1 && vv.s.high == 0)
      {
        DWunion ww = {.ll = (UDItype) (USItype) uu.s.low
        * (UDItype) (USItype) vv.s.low};

        ww.s.high -= vv.s.low;
        if (__builtin_expect (ww.s.high < 0, 1))
   return ww.ll;
      }
  }
       else
  {
    if ((uu.s.high & vv.s.high) == (SItype) -1
        && (uu.s.low | vv.s.low) != 0)
      {
        DWunion ww = {.ll = (UDItype) (USItype) uu.s.low
        * (UDItype) (USItype) vv.s.low};

        ww.s.high -= uu.s.low;
        ww.s.high -= vv.s.low;
        if (__builtin_expect (ww.s.high >= 0, 1))
   return ww.ll;
      }
  }
     }
 }
    }


  __builtin_trap ();
}

[-- Attachment #3: Type: text/plain, Size: 2 bytes --]

Re: LRA produces RTL not meeting constraint

[Paul Koning]

> On Jan 11, 2023, at 7:38 PM, Paul Koning via Gcc <gcc@gcc.gnu.org> wrote:
> 
> 
> 
>> On Jan 11, 2023, at 2:52 PM, Segher Boessenkool <segher@kernel.crashing.org> 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.

It occurs to me there's a strange transformation LRA made that I don't understand, which is the cause of the trouble.

Input:

(insn 49 48 53 5 (set (reg/f:HI 136)
        (plus:HI (reg/f:HI 5 r5)
            (const_int -8 [0xfffffffffffffff8]))) "_mulvdi3.i":38:4 68 {addhi3}
     (expr_list:REG_EQUIV (plus:HI (reg/f:HI 5 r5)
            (const_int -8 [0xfffffffffffffff8]))
        (nil)))
(insn 53 49 50 5 (set (reg/f:HI 137)
        (symbol_ref:HI ("__muldi3") [flags 0x41]  <function_decl 0x104927d00 __muldi3>)) "_mulvdi3.i":38:4 25 {movhi}
     (expr_list:REG_EQUIV (symbol_ref:HI ("__muldi3") [flags 0x41]  <function_decl 0x104927d00 __muldi3>)
        (nil)))

and the IRA "disposition" says it assigned R5 for R136, which is what should happen given that operand 1 (in the plus:HI) is R5 and the constraint says that operands 0 and 1 should match.

However, Reload shows that it is given:

(insn 49 48 53 5 (set (reg/f:HI 5 r5 [136])
        (plus:HI (reg/f:HI 6 sp)
            (const_int 40 [0x28]))) "_mulvdi3.i":38:4 68 {addhi3}
     (expr_list:REG_EQUIV (plus:HI (reg/f:HI 5 r5)
            (const_int -8 [0xfffffffffffffff8]))
        (nil)))

In other words, R136 was replaced by R5 as expected -- but at the same time, the source operands were replaced by something entirely different.  It is a misguided attempt to eliminate the frame pointer?  R5 can be the frame pointer, if it is needed for that purpose.  And replacing an FP reference by an SP reference is reasonable enough, but such a substitution has to verify that the constraints are still satisfied.  Is that something the target code has to provide?  I'm not aware of it.

	paul

Re: LRA produces RTL not meeting constraint

[Segher Boessenkool]

On Wed, Jan 11, 2023 at 07:38:44PM -0500, Paul Koning wrote:
> > On Jan 11, 2023, at 2:52 PM, Segher Boessenkool <segher@kernel.crashing.org> wrote:
> > On Tue, Jan 10, 2023 at 02:39:34PM -0500, Paul Koning via Gcc wrote:
> > 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.

Sure.  And one here is a pseudo, so it actually *can* reasonably be
tied.

> Indeed.  So does that mean the discussion about insn 48 is the interesting one?  That goes on for a while:

No, the insns 49 one is the useful one.

            2 Non-pseudo reload: reject+=2
            2 Non input pseudo reload: reject++
          alt=0,overall=9,losers=1,rld_nregs=1
          alt=1,overall=0,losers=0,rld_nregs=0
            1 Matching alt: reject+=2
            1 Non-pseudo reload: reject+=2
            1 Non input pseudo reload: reject++
            alt=0,overall=11,losers=1 -- refuse
            1 Matching alt: reject+=2
            1 Non-pseudo reload: reject+=2
            1 Non input pseudo reload: reject++
            alt=1,overall=11,losers=1 -- refuse
            0 Spill pseudo into memory: reject+=3
            Using memory insn operand 0: reject+=3
            0 Non input pseudo reload: reject++
            alt=2,overall=13,losers=1 -- refuse
            0 Spill pseudo into memory: reject+=3
            Using memory insn operand 0: reject+=3
            0 Non input pseudo reload: reject++
            alt=3,overall=13,losers=1 -- refuse
         Choosing alt 1 in insn 49:  (0) rR  (1) 0  (2) Qi {addhi3}

For all four constraints it could tie operands[1] to it got "refuse".
This can't be good.

> > 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.

It would look like e.g.
    Inserting insn reload before:
  413: r179:SI=r25:SI
or
    Inserting insn reload after:
  414: r45:SI=r179:SI

> 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).

It helped, I can reproduce the problem.  Thanks!

Open a PR for the problem?  So that people can cooperate on it easier,
and to battle the "attention span of a goldfish" problem?


Segher