Re: just_select in combine.c:force_to_mode

[Segher Boessenkool]

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 .


>    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 :-) )

>    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.

(Please don't paste lines full of spaces in your emails, it is hard to read).


Segher