This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Hoist reciprocal invariant out of loop
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