[PATCH] Hoist reciprocal invariant out of loop

[Zdenek Dvorak]

Hello,

> >>>>> Zdenek Dvorak writes:
> 
> Zdenek> Do you really need MOVE_RECIPROCAL, then?  Just checking for this
> Zdenek> pattern in determine_invariantness_stmt in case MOVE_POSSIBLE is
> Zdenek> returned should work as well.  Probably not that important.
> 
> 	With the proposed change to tree_could_trap_p(), I guess that I
> could move it all to determine_invariantness_stmt().
> 
> Zdenek> One more detail I noticed now; using expr_invariant_in_loop_p is
> Zdenek> a bit too conservative inside invariant analysis.  You may use
> Zdenek> outermost_invariant_loop (or outermost_invariant_loop_expr).
> 
> 	I noticed those functions and tried them originally, but I had
> difficulty getting the expected results.  Also, those functions are
> somewhat duplicative of expr_invariant_in_loop_p() and I was advised to
> switch to the latter function.  Those routines should be merged together,
> possibly with a flag for more or less conservative behavior.

no, this is not the case:

-- expr_invariant_in_loop_p is a function used by some passes outside
   invariant motion.  It determines invariantness in just one loop,
   and for large loops it may be somewhat expensive, since it does
   just traverse the du chains.
-- invariant motion traverses function in dominance order, and
   determines the outermost loop in that each statement is invariant.
   This is more efficient than calling expr_invariant_in_loop_p
   repeatedly, since the results are cached, so you spend only constant
   time per statement.  Of course, this cannot be used outside the invariant
   analysis.

Inside invariant analysis, you should use outermost_invariant_loop.

Zdenek