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. Olga > > Richard.
