Bug 37166 - variable is still committed to stack even though it is not aliased
Summary: variable is still committed to stack even though it is not aliased
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: tree-optimization (show other bugs)
Version: 4.4.0
: P3 normal
Target Milestone: 4.5.0
Assignee: Not yet assigned to anyone
URL:
Keywords: missed-optimization
Depends on:
Blocks:
 
Reported: 2008-08-19 19:19 UTC by Andrew Pinski
Modified: 2010-03-02 19:05 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2008-12-27 06:26:01


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Pinski 2008-08-19 19:19:33 UTC
Testcase:
struct f { int a; };


int g(struct f *b, struct f *c)
{
  struct f g;
  if (!b) {
    b = &g;
    b->a = c->a + 1;
    c->a = c->a + 1;
  }
  else if (!c) {
    c = &g;
    c->a = b->a + 1;
    b->a = b->a + 1;
  }
  return c->a + b->a;
}
--- CUT ---
After some changes on the trunk, we get:
<bb 2>:
  if (b == 0B)
    goto <bb 3>;
  else
    goto <bb 4>;

<bb 3>:
  g.a = [plus_expr] c->a + 1;
  prephitmp.13 = c->a + 1;
  c->a = prephitmp.13;
  prephitmp.25 = g.a;
  goto <bb 7>;

<bb 4>:
  if (c == 0B)
    goto <bb 6>;
  else
    goto <bb 5>;

<bb 5>:
  prephitmp.13 = c->a;
  prephitmp.25 = b->a;
  goto <bb 7>;

<bb 6>:
  g.a = [plus_expr] b->a + 1;
  prephitmp.25 = b->a + 1;
  b->a = prephitmp.25;
  prephitmp.13 = g.a;

<bb 7>:
  return prephitmp.25 + prephitmp.13;

--- CUT ---
Notice how g.a is still referenced.  This comes from 
  # b_1 = PHI <&g(3), b_3(D)(7), b_3(D)(5)>

Being in the IR after PRE even though b_1 is no longer referenced.
So for 32bit PPC we get a stack adjustment:
        stwu %r1,-32(%r1)
..
        addi %r1,%r1,32

Even though there is no need for this adjustment as nothing touches the stack but the variable g is still being marked with TREE_ADDRESSABLE as evident by:
Partition 0: size 4 align 4
        g, offset 0
in the .expand dump.
Comment 1 Richard Biener 2008-08-19 19:31:28 UTC
Confirmed.  After PRE is the last time we recompute aliasing (and the set
of addressable vars).
Comment 2 Andrew Pinski 2010-03-02 19:05:17 UTC
This has been fixed on the trunk.