https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116560

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
The first problem I see in fwprop1 is:
```
propagating insn 10 into insn 11, replacing:
(set (reg/v:SI 135 [ temp ])
    (zero_extend:SI (subreg:HI (reg:SI 144) 0)))
failed to match this instruction:
(set (reg/v:SI 135 [ temp ])
    (zero_extend:SI (subreg:HI (ior:SI (reg:SI 143)
                (reg:SI 141 [ MEM[(type1 * {ref-all})ptr_3(D)] ])) 0)))
```

Oh wait we don't have nonzero_bits here. If we did, we would see that this is
the same as:
(set (reg/v:SI 135 [ temp ])
    (zero_extend:SI (subreg:HI (reg:SI 141)))

fwprop/late_combine not having nonzero_bits definitely limits these passes.


Also I noticed in combine we don't (redo?) 9 -> 13:
```
(insn 9 8 10 2 (set (reg:SI 143)
        (ashift:SI (reg:SI 142 [ MEM[(type1 * {ref-all})ptr_3(D)]+1 ])
            (const_int 8 [0x8]))) "/app/example.cpp":7:20 294 {*ashlsi3}
     (expr_list:REG_DEAD (reg:SI 142 [ MEM[(type1 * {ref-all})ptr_3(D)]+1 ])
        (nil)))
...
(insn 13 12 16 2 (set (reg:SI 146)
        (lshiftrt:SI (reg:SI 143)
            (const_int 8 [0x8]))) "/app/example.cpp":8:12 296 {*lshrsi3}
     (expr_list:REG_DEAD (reg:SI 143)
        (nil)))
```

Where this would have caused, r146 to be a copy of r142.
I Have not looked into why though.

Reply via email to