This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
just_select in combine.c:force_to_mode
- From: <SenthilKumar dot Selvaraj at microchip dot com>
- To: <gcc at gcc dot gnu dot org>
- Cc: <kenner at nyu dot edu>
- Date: Thu, 13 Dec 2018 09:39:52 +0000
- Subject: just_select in combine.c:force_to_mode
Hi,
When debugging PR 88253, I found that force_to_mode uses a parameter
(just_select) to prevent the function from returning a const0_rtx even
if none of the bits set by the rtx are needed. The comment says
"If JUST_SELECT is nonzero, don't optimize by noticing that bits in MASK
are all off in X. This is used when X will be complemented, by either
NOT, NEG, or XOR."
and the code behaves the same way, but could someone help me
understand why?
I ran into this, when I found that force_to_mode converts
(ior:QI (subreg:QI (ior:HI (ashift:HI (zero_extend:HI (reg/v:QI 46 [ h ]))
(const_int 8 [0x8]))
(reg:HI 55 [ D.1627 ])) 0)
(const_int 42 [0x2a]))
into
(set (reg:QI 44 [ D.1626 ])
(ior:QI (subreg:QI (reg:HI 55 [ D.1627 ]) 0)
(const_int 42 [0x2a])))
but is unable to do the same thing for the below rtx.
(xor:QI (subreg:QI (ior:HI (ashift:HI (zero_extend:HI (reg/v:QI 46 [ h ]))
(const_int 8 [0x8]))
(reg:HI 55 [ D.1627 ])) 0)
(reg:QI 58))
The only difference is the xor instead of ior at the outermost sexp,
and force_to_mode returns
(set (reg:QI 44 [ D.1626 ])
(xor:QI (ior:QI (subreg:QI (ashift:HI (zero_extend:HI (reg/v:QI 46 [ h ]))
(const_int 8 [0x8])) 0)
(subreg:QI (reg:HI 55 [ D.1627 ]) 0))
(reg:QI 58)))
This more complicated pattern doesn't match, and combine
moves on to another combination of insns, eventually resulting in PR 88253.
Isn't the simplification of
(subreg:QI (ior:HI (ashift:HI (zero_extend:HI (reg/v:QI 46 [ h ]))
(const_int 8 [0x8]))
(reg:HI 55 [ D.1627 ]))
to
(subreg:QI (reg:HI 55 [ D.1627 ])
safe to do, wheter the outer insn code is XOR or IOR?
Regards
Senthil