This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Hoist reciprocal invariant out of loop


Hello,

> Zdenek> I think it would be a bit cleaner to move the code that modifies the
> Zdenek> statements to move_computations_stmt.  It would be also nice if
> Zdenek> the code of the transformation was in a separate function.
> 
> 	If I do not modify the statements in
> determine_invariantness_stmt(), then determine_max_movement() will not
> have the invariant statement available to calculate the allowed movement.
> I could annotate the statement as requiring reciprocal transformation with
> a new field in LIM_DATA and perform the transformation in
> move_computations_stmt(), but I still would need to create a fake
> statement for determine_max_movement() or somehow calculate LIM_DATA
> max_loop in determine_invariantness_stmt(), which seems unnecessarily
> convoluted, IMHO.  I think that it is more efficient and more clear to
> perform all of the operations in determine_invariantness_stmt() even
> though it makes the function less single-purposed.

right; I missed that.

Do you really need MOVE_RECIPROCAL, then?  Just checking for this
pattern in determine_invariantness_stmt in case MOVE_POSSIBLE is
returned should work as well.  Probably not that important.

One more detail I noticed now; using expr_invariant_in_loop_p is
a bit too conservative inside invariant analysis.  You may use
outermost_invariant_loop (or outermost_invariant_loop_expr).

Zdenek


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]