[Bug tree-optimization/33136] [4.1/4.2/4.3 Regression] wrong code due to alias with allocation in loop

jakub at gcc dot gnu dot org gcc-bugzilla@gcc.gnu.org
Fri Aug 24 15:39:00 GMT 2007



------- Comment #20 from jakub at gcc dot gnu dot org  2007-08-24 15:38 -------
Created an attachment (id=14103)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14103&action=view)
gcc43-pr33136.patch

Here is what I have been playing with.
But I'd really like to see some testcases where the
ipa_type_escape_field_does_not_clobber_p is supposed to help.

I tried to write:

/* PR tree-optimization/33136 */
/* { dg-do compile } */
/* { dg-options "-O2" } */

struct S
{
  void *a;
  int b;
  float f;
};

static struct S s;

static int *
__attribute__((noinline, const))
foo (void)
{
  return &s.b;
}

float
__attribute__((noinline))
bar (float *f)
{
  s.f = 1.0;
  *f = 4.0;
  return s.f;
}

int
__attribute__((noinline))
baz (int *x)
{
  s.b = 1;
  *x = 4;
  return s.b;
}

int
t (void)
{
  float f = 8.0;
  return bar (&f) + baz (foo ());
}
My understanding would be this is a perfect example where this optimization
should help, ipa-type-escape-var analysis says
ipa_type_escape_field_does_not_clobber_p (<struct S>, <void *>) == 1
ipa_type_escape_field_does_not_clobber_p (<struct S>, <int>) == 0
ipa_type_escape_field_does_not_clobber_p (<struct S>, <float>) == 1
which is IMHO correct.  In the baz function, we aren't supposed to optimize
out the read from s.b, as x may point to it (and in the testcase actually
does).
In bar on the other side, I believe we can optimize this to
float
__attribute__((noinline))
bar (float *f)
{
  s.f = 1.0;
  *f = 4.0;
  return 1.0;
}
because as ipa-type-escap analysis found nothing ever takes address of any
float field in struct S, so f can't point to it.
But may_alias_p in that case is not called with var with struct S type (nor any
pointer thereof), so ipa_type_escape_star_count_of_interesting_type will
always return -1.  It is called just with STRUCT_FIELD_TAGs with float or int
or void * type or f var_decl in function t.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33136



More information about the Gcc-bugs mailing list