This is the mail archive of the 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: About the is_gimple_min_invariant predicate

On 7/4/07, Eric Botcazou <> wrote:
> This is invalid gimple.

Right, but nevertheless is_gimple_val.

> Can you figure our why we don't gimplify this to
> tmp_1 = MAX_EXPR <D.738_31, 0>;
> tmp_2 = (<unnamed-signed:32>)tmp_1;
> tmp_3 = tmp_2 + 1;
> &p_name_buffer[tmp3]

Because there is no code to do it. If I add it:

Index: tree-ssa-pre.c
--- tree-ssa-pre.c      (revision 126300)
+++ tree-ssa-pre.c      (working copy)
@@ -3682,6 +3682,8 @@ eliminate (void)
                  && (TREE_CODE (*rhs_p) != SSA_NAME
                      || may_propagate_copy (*rhs_p, sprime)))
+                 tree forced_stmts;
                  gcc_assert (sprime != *rhs_p);

                  if (dump_file && (dump_flags & TDF_DETAILS))
@@ -3705,7 +3707,24 @@ eliminate (void)
                    sprime = fold_convert (TREE_TYPE (*rhs_p), sprime);

+                /* Force the available computation to be a sequence of GIMPLE
+                    statements.
+                    We have to call unshare_expr because force_gimple_operand
+                    may modify the tree we pass to it.  */
+                 sprime = force_gimple_operand (unshare_expr (sprime),
+                                                &forced_stmts, false, NULL);
                  propagate_tree_value (rhs_p, sprime);
+                 if (forced_stmts)
+                   {
+                     tree_stmt_iterator tsi = tsi_start (forced_stmts);
+                     for (; !tsi_end_p (tsi); tsi_next (&tsi))
+                       mark_symbols_for_renaming (tsi_stmt (tsi));
+                     bsi_insert_before (&i, forced_stmts, BSI_SAME_STMT);
+                   }

it doesn't do anything since the expression is_gimple_val.

Ok. So either we want to disallow invariant addresses as gimple value altogether or do more elaborate checks, to rule out such bogus cases. At least the transformation PRE is doing doesn't make sense -- and I know other optimization passes that treat is_gimple_min_invariant() values as "as cheap as constants", which in this case surely is not true.

So maybe you can try reworking is_gimple_min_invariant to restrict this case to
where the address computation is indeed as cheap as a constant or
register value?


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