[Bug tree-optimization/97960] [8/9/10 Regression] Wrong code at -O3 since r8-6511-g3ae129323d

["jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97960

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[8/9/10/11 Regression]      |[8/9/10 Regression] Wrong
                   |Wrong code at -O3 since     |code at -O3 since
                   |r8-6511-g3ae129323d         |r8-6511-g3ae129323d

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed on the trunk by

https://gcc.gnu.org/g:4cf70c20cb10acd6fb1016611d05540728176b60                  

commit r11-5904-g4cf70c20cb10acd6fb1016611d05540728176b60                       
Author: Richard Sandiford <richard.sandiford@arm.com>                           
Date:   Thu Dec 10 12:10:00 2020 +0000                                          

    data-ref: Rework integer handling in split_constant_offset [PR98069]        

    PR98069 is about a case in which split_constant_offset miscategorises       
    an expression of the form:                                                  

      int foo;                                                                  
      …                                                                         
      POINTER_PLUS_EXPR<base, (sizetype)(INT_MIN - foo) * size>                 

    as:                                                                         

      base: base                                                                
      offset: (sizetype) (-foo) * size                                          
      init: INT_MIN * size                                                      

    “-foo” overflows when “foo” is INT_MIN, whereas the original expression     
    didn't overflow in that case.                                               

    As discussed in the PR trail, we could simply ignore the fact that          
    int overflow is undefined and treat it as a wrapping type, but that         
    is likely to pessimise quite a few cases.                                   

    This patch instead reworks split_constant_offset so that:                   

    - it treats integer operations as having an implicit cast to sizetype       
    - for integer operations, the returned VAR has type sizetype                

    In other words, the problem becomes to express:                             

      (sizetype) (OP0 CODE OP1)                                                 

    as:                                                                         

      VAR:sizetype + (sizetype) OFF:ssizetype                                   

    The top-level integer split_constant_offset will (usually) be a sizetype    
    POINTER_PLUS operand, so the extra cast to sizetype disappears.  But adding 
    the cast allows the conversion handling to defer a lot of the difficult     
    cases to the recursive split_constant_offset call, which can detect         
    overflow on individual operations.                                          

    The net effect is to analyse the access above as:                           

      base: base                                                                
      offset: -(sizetype) foo * size                                            
      init: INT_MIN * size                                                      

    See the comments in the patch for more details.                             

    gcc/                                                                        
            PR tree-optimization/98069                                          
            * tree-data-ref.c (compute_distributive_range): New function.       
            (nop_conversion_for_offset_p): Likewise.                            
            (split_constant_offset): In the internal overload, treat integer    
            expressions as having an implicit cast to sizetype and express      
            them accordingly.  Pass back the range of the original (uncast)     
            expression in a new range parameter.                                
            (split_constant_offset_1): Likewise.  Rework the handling of        
            conversions to account for the implicit sizetype casts.