On Thu, May 1, 2008 at 10:42 PM, Olga Golovanevsky <[EMAIL PROTECTED]> wrote: > Richard Guenther <[EMAIL PROTECTED]> wrote on 01/05/2008 16:00:44: > > > > > On Thu, May 1, 2008 at 2:19 PM, Olga Golovanevsky <[EMAIL PROTECTED]> > wrote: > > > > > > > > > [EMAIL PROTECTED] wrote on 28/04/2008 12:36:44: > > > > > > > > > > Hello, > > > > I am looking at a testsuite failure (wo_prof_global_var.c) in my > > > > porting. Somehow, I found GCC 4.3.0 seems to generate unnecessary > malloc > > > > during structure optimization. In the code, the structure is split > into > > > > two individual fields (D.2240 and D.2242) and they are allocated > > > > separately. But the original structure (D.2215) is still allocated, > and > > > > not used afterward. The following RTL-level optimization cannot > > > > eliminate it. > > > > > > I think that p is global, and in my understanding right now we have no > > > whole > > > program dead code elimination optimization in gcc, but may be I am > wrong. > > > > You cannot remove p, but if you could split up the allocation for *p then > you > > can for sure remove the original allocation for *p. Otherwise you > generated > > wrong code in the first place, which you certainly did, if p was global. > > Again, struct-reorg is a whole program optimization. It explicitly checks > the> > "whole-program" flag at its gate. It checks the safety of transformation > through > ipa-type-escape analysis and other escape analysis inside struct-reorg. If > it > decides it is safe to transform, it replace all variables of specific > structure > type along with their allocations and accesses. It has obviously enough > information > to eliminate both a malloc statement and p, even if p is global. But it's > question > whether it's a right place to do it inside struct-reorg. For example, > function > level optimizers rely on dce for this matter.
Sure, a malloc call has side-effects, so a DCE pass cannot just remove it. Only struct-reorg knows that it has replaced all side-effects with others. Richard.
