https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77729
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |missed-optimization
Status|UNCONFIRMED |NEW
Last reconfirmed| |2016-09-25
Ever confirmed|0 |1
Severity|normal |enhancement
--- Comment #10 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
This is how we expand it on aarch64:
(insn 10 9 11 (set (reg:QI 81)
(mem:QI (reg/v/f:DI 80 [ string ]) [0 *string_9(D)+0 S1 A8])) t.c:4 -1
(nil))
(insn 11 10 12 (set (reg:SI 82)
(ior:SI (subreg:SI (reg:QI 81) 0)
(const_int 32 [0x20]))) t.c:4 -1
(nil))
(insn 12 11 13 (set (reg:SI 83)
(zero_extend:SI (subreg:QI (reg:SI 82) 0))) t.c:4 -1
(nil))
(insn 13 12 14 (set (reg:CC 66 cc)
(compare:CC (reg:SI 83)
(const_int 116 [0x74]))) t.c:4 -1
(nil))
-----
(set (reg:SI 83)
(ior:SI (and:SI (subreg:SI (mem:QI (reg/v/f:DI 80 [ string ]) [0
*string_9(D)+0 S1 A8]) 0)
(const_int 223 [0xdf]))
(const_int 32 [0x20])))
Notice how the and there is 223, but really that can be still a zero_extend.
Basically combine is going funny.
---- CUT ----
Note for 33, orr does not accept 33 so combine does not see 33 and does not
change the and part around the subreg.
