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.