Take the following example from PR 21591: struct a { int length; int a1[256]; }; struct a *malloc1(__SIZE_TYPE__) __attribute__((malloc)); void free(void*); void f(void) { struct a *a = malloc1(sizeof(struct a)); struct a *b = malloc1(sizeof(struct a)); struct a *c = malloc1(sizeof(struct a)); int i; for (i = 0; i < 256; i++) { b->a1[i] = i; c->a1[i] = i; } for (i = 0; i < 256; i++) { a->a1[i] = b->a1[i] + c->a1[i]; } free(a); free(b); free(c); } ---- In .alias1: i.0_18 = i_1; # HEAP.7_46 = V_MAY_DEF <HEAP.7_22>; b_6->a1[i.0_18] = i_1; i.0_19 = i_1; # HEAP.8_47 = V_MAY_DEF <HEAP.8_23>; c_8->a1[i.0_19] = i_1; i_20 = i_1 + 1; In .alias2: # HEAP.19_14 = V_MAY_DEF <HEAP.19_21>; b_5->a1[i_65] = i_65; # HEAP.20_73 = V_MAY_DEF <HEAP.20_10>; c_7->a1[i_65] = i_65; i_20 = i_65 + 1; --- I don't know how much harm in compile time does this hurt in normal code but we then keep on adding them to clobbered variables: # HEAP.6_27 = V_MAY_DEF <HEAP.6_24>; # HEAP.7_28 = V_MAY_DEF <HEAP.7_25>; # HEAP.8_29 = V_MAY_DEF <HEAP.8_26>; # HEAP.18_6 = V_MAY_DEF <HEAP.18_9>; # HEAP.19_8 = V_MAY_DEF <HEAP.19_64>; # HEAP.20_1 = V_MAY_DEF <HEAP.20_4>; a_3 = malloc1 (1028);
I think this is the issue I am hitting for PR 15855.
Subject: Re: New: [4.1 Regression] tree-ssa-alias creates a new virtual variable for malloc each time may_alias is run (HEAP) On Sun, 2005-08-14 at 03:36 +0000, pinskia at gcc dot gnu dot org wrote: > ---- > In .alias1: > i.0_18 = i_1; > # HEAP.7_46 = V_MAY_DEF <HEAP.7_22>; > b_6->a1[i.0_18] = i_1; > i.0_19 = i_1; > # HEAP.8_47 = V_MAY_DEF <HEAP.8_23>; > c_8->a1[i.0_19] = i_1; > i_20 = i_1 + 1; > > In .alias2: > # HEAP.19_14 = V_MAY_DEF <HEAP.19_21>; > b_5->a1[i_65] = i_65; > # HEAP.20_73 = V_MAY_DEF <HEAP.20_10>; > c_7->a1[i_65] = i_65; > i_20 = i_65 + 1; Uh, so? This is because we recompute all the alias info, which means we really recompute the alias info. > > --- > I don't know how much harm in compile time does this hurt in normal code but we then keep on adding > them to clobbered variables: > # HEAP.6_27 = V_MAY_DEF <HEAP.6_24>; > # HEAP.7_28 = V_MAY_DEF <HEAP.7_25>; > # HEAP.8_29 = V_MAY_DEF <HEAP.8_26>; > # HEAP.18_6 = V_MAY_DEF <HEAP.18_9>; > # HEAP.19_8 = V_MAY_DEF <HEAP.19_64>; > # HEAP.20_1 = V_MAY_DEF <HEAP.20_4>; > a_3 = malloc1 (1028); This is wrong. malloc functions don't *clobber* anything, AFAIK. --Dan
Subject: Re: [4.1 Regression] tree-ssa-alias creates a new virtual variable for malloc each time may_alias is run (HEAP) On Aug 13, 2005, at 11:40 PM, dberlin at dberlin dot org wrote: > Uh, so? We keep the virtual variable around even in the clobbered variables. Add a function call to an different function like say f so it does not get GC'd and we keep on adding more and more V_MAY_DEFs: # HEAP.6_36 = V_MAY_DEF <HEAP.6_73>; # HEAP.7_37 = V_MAY_DEF <HEAP.7_71>; # HEAP.8_38 = V_MAY_DEF <HEAP.8_70>; # HEAP.18_78 = V_MAY_DEF <HEAP.18_77>; # HEAP.19_79 = V_MAY_DEF <HEAP.19_14>; # HEAP.20_80 = V_MAY_DEF <HEAP.20_76>; g (); -- Pinski
Subject: Re: [4.1 Regression] tree-ssa-alias creates a new virtual variable for malloc each time may_alias is run (HEAP) On Sun, 2005-08-14 at 03:38 +0000, pinskia at gcc dot gnu dot org wrote: > ------- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-14 03:38 ------- > I think this is the issue I am hitting for PR 15855. Do you have *anything* to back this up? There are still no timings, dumps, or anything attached to 15855 >
Subject: Re: [4.1 Regression] tree-ssa-alias creates a new virtual variable for malloc each time may_alias is run (HEAP) On Sun, 2005-08-14 at 03:48 +0000, pinskia at physics dot uc dot edu wrote: > ------- Additional Comments From pinskia at physics dot uc dot edu 2005-08-14 03:48 ------- > Subject: Re: [4.1 Regression] tree-ssa-alias creates a new virtual variable for malloc each time may_alias is run (HEAP) > > > On Aug 13, 2005, at 11:40 PM, dberlin at dberlin dot org wrote: > > > Uh, so? > We keep the virtual variable around even in the clobbered variables. I thought the call clobbered list was recomputed at the same time, which should alleviate this problem. If not, *that* is buggy. Recreating the heap variables is *not* a bug. Redoing alias information is sometihng we may not want to do, but the fact that it requires us to recreate heap variables is a fact of life.
Confirmed. Reduced testcase: struct a { int length; int a1[256]; }; void *malloc(long size) __attribute__((malloc)); void f(void) { struct a *a = malloc(sizeof(struct a)); } we pile up heap variables: (t62.alias5) <bb 0>: # HEAP.5D.1297_4 = V_MAY_DEF <HEAP.5D.1297_3>; # HEAP.11D.1303_5 = V_MAY_DEF <HEAP.11D.1303_2>; # HEAP.17D.1309_7 = V_MAY_DEF <HEAP.17D.1309_6>; # HEAP.23D.1315_9 = V_MAY_DEF <HEAP.23D.1315_8>; # HEAP.29D.1321_11 = V_MAY_DEF <HEAP.29D.1321_10>; D.1287_1 = malloc (1028);
Assigning to D. Berlin per his request.
Leaving as P2.
Subject: Bug 23382 Author: dberlin Date: Tue Nov 8 16:34:48 2005 New Revision: 106643 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106643 Log: 2005-11-08 Daniel Berlin <dberlin@dberlin.org> Fix PR tree-optimization/23382 * tree-ssa-alias.c (compute_may_aliases): Call delete_old_heap_vars. * tree-dfa.c (referenced_var_remove): New function. * tree-ssa.c (delete_tree_ssa): Call delete_old_heap_vars. * tree-flow.h (referenced_var_remove): Add prototype. (delete_old_heap_vars): Ditto. * tree-ssa-structalias.c (heapvars): New variable. (oldheapvars): Ditto. (get_constraint_for): Put heap vars on heapvars list. (delete_old_heap_vars): New function. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr23382.c Modified: trunk/gcc/ChangeLog trunk/gcc/tree-dfa.c trunk/gcc/tree-flow.h trunk/gcc/tree-ssa-alias.c trunk/gcc/tree-ssa-structalias.c trunk/gcc/tree-ssa.c
Fixed