just_select in combine.c:force_to_mode

[SenthilKumar.Selvaraj@microchip.com]

Segher Boessenkool writes:

> Hi!
>
> On Thu, Dec 13, 2018 at 09:39:52AM +0000, SenthilKumar.Selvaraj@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