[Bug tree-optimization/71915] A missed opportunity for SLSR

[wschmidt at gcc dot gnu.org]

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

--- Comment #5 from Bill Schmidt <wschmidt at gcc dot gnu.org> ---
This is an example of a known limitation in SLSR.  The explanation is in
analyze_increments:

      /* FORNOW: If we need to add an initializer, give up if a cast from       
         the candidate's type to its stride's type can lose precision.          
         This could eventually be handled better by expressly retaining the     
         result of a cast to a wider type in the stride.  Example:              

           short int _1;                                                        
           _2 = (int) _1;                                                       
           _3 = _2 * 10;                                                        
           _4 = x + _3;    ADD: x + (10 * _1) : int                             
           _5 = _2 * 15;                                                        
           _6 = x + _3;    ADD: x + (15 * _1) : int                             

         Right now replacing _6 would cause insertion of an initializer         
         of the form "short int T = _1 * 5;" followed by a cast to              
         int, which could overflow incorrectly.  Had we recorded _2 or          
         (int)_1 as the stride, this wouldn't happen.  However, doing           
         this breaks other opportunities, so this will require some             
         care.  */

In this case, we have "int" rather than "short int," and "int *" rather than
"int".  Assuming a 64-bit machine, casting from a 64-bit wrapping type to a
32-bit non-wrapping type isn't legal.

I need to look at the stride-selection logic again.  The various cast-sensitive
bits of this are tricky to get right.