https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71437
--- Comment #8 from amker at gcc dot gnu.org ---
(In reply to amker from comment #7)
> I think it's not PRE's fault. The input to PRE is already sub-optimal to be
> handled.
> Look at the source code:
>
> for( i = 0 ; i < ( I - 1 ) ; i++ )
> {
> if( ( L < pL[i+1] ) && ( L >= pL[i] ) )
> break ;
> }
>
> if( i == ( I - 1 ) )
> L = pL[i] ;
> LD = (float)( L - pL[i] ) /
> (float)( pL[i + 1] - pL[i] ) ;
>
> Following path from the "break" statement, we know i < (I - 1) must be
> satisfied, so control flow can go from "break" directly to assignment to LD.
> This is the case before the change.
> After r235817, all paths from the loop (including the break edge) go to if
> (i == ( I - 1) ) statement. Because in if-then branch, L was assigned, and
> we don't know if pL[i] is modified or not by this assignment by aliasing
> rule, there is no redundancy for load of pL[i].
And maybe that's why -fwhole-program is helpful, because we know L and pL don't
alias with each other.
