https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70646

--- Comment #25 from Martin Jambor <jamborm at gcc dot gnu.org> ---
(In reply to Martin Jambor from comment #22)
> I suppose the easiest fix is to overload the value field to store the
> size of the access for these two codes and then add the missing check.

OK, so the IS_NOT_CONSTANT case is relatively easy, the following
(untested) patch fixes this PR:

diff --git a/gcc/ipa-inline-analysis.c b/gcc/ipa-inline-analysis.c
index f8ca825..6901cfb 100644
--- a/gcc/ipa-inline-analysis.c
+++ b/gcc/ipa-inline-analysis.c
@@ -867,8 +867,14 @@ evaluate_conditions_for_known_args (struct cgraph_node
*node,
          clause |= 1 << (i + predicate_first_dynamic_condition);
          continue;
        }
-      if (c->code == IS_NOT_CONSTANT || c->code == CHANGED)
+      if (c->code == CHANGED)
        continue;
+      if (c->code == IS_NOT_CONSTANT)
+       {
+         if (!operand_equal_p (c->val, TYPE_SIZE (TREE_TYPE (val)), 0))
+           clause |= 1 << (i + predicate_first_dynamic_condition);
+         continue;
+       }

       if (operand_equal_p (TYPE_SIZE (TREE_TYPE (c->val)),
                           TYPE_SIZE (TREE_TYPE (val)), 0))
@@ -1807,8 +1813,9 @@ set_cond_stmt_execution_predicate (struct
ipa_func_body_info *fbi,
     return;
   FOR_EACH_EDGE (e, ei, bb->succs) if (e->flags & EDGE_FALSE_VALUE)
     {
+      tree opsize = unshare_expr_without_location (TYPE_SIZE (TREE_TYPE
(op2)));
       struct predicate p = add_condition (summary, index, &aggpos,
-                                         IS_NOT_CONSTANT, NULL_TREE);
+                                         IS_NOT_CONSTANT, opsize);
       e->aux = edge_predicate_pool.allocate ();
       *(struct predicate *) e->aux = p;
     }

On the other hand, the CHANGED part is more difficult because an
unchanged value is represented with an error_mark_node which of course
does not encode the size of the unchanged value.  So if we wanted to
handle it, we'd need to encode it differently.  However, I am not
convinced it is necessary because, unless I'm forgetting about
something, it is only used as inlining heuristics and can never lead
to any optimizations and thus neither to miscompilations.  Am I right?

In any event, I'd like to talk to Honza bout this before going any
further.

Reply via email to