Segher Boessenkool writes:
> Hi! > > On Thu, Dec 13, 2018 at 09:39:52AM +0000, senthilkumar.selva...@microchip.com > wrote: >> 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? > > This was introduced in https://gcc.gnu.org/r6342 . Yep :). Was hoping someone would have run into a similar situation, although trawling the gcc mailing lists didn't turn up anything useful. > > >> 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. > > Combine not doing some combination is never incorrect, of course (just not > what you want, possibly, but not the cause of a bug :-) ) Understood. The bug report said the PR does not show up for a bitwise OR, so just wanted to convey that this is where the divergence between the RTL for a bitwise OR vs XOR starts. > >> 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? > > Probably. I was wondering if I should put out a patch that resets just_select for (the nested) IOR's operands, but maybe I should leave this untouched. As you said, this is more a missed optimization, and shouldn't really cause any bugs. > > (Please don't paste lines full of spaces in your emails, it is hard to read). Apologies, didn't notice that. Regards Senthil
