Eliminate write-only variables

Jan Hubicka hubicka@ucw.cz
Mon May 19 03:41:00 GMT 2014


> 
> Hmmmm, I'm guessing this was some concern about invalid code motion
> around a setjmp.  Our original analysis document lists "F does not
> call setjmp" as a requirement for the optimization, so this was
> probably a case where we were being excessively conservative.

I suppose it was because you needed to prove that the value stored in static
variable is dead at the function return and setjmp may let you to jump
from somewhere else.  This should transparently work with mainline approach.

> >
> >Richi, is there a way to teach early FRE to get this transformation?
> >I see it is a partial redundancy problem...
> 
> Hmmmm, bummer that we don't get this one for free.  :-(

Yeah, lets not forget about this one. On the plus side we got quite few cases
your code didn't ;)

> >Sandra,
> >do you think you can drop the testcases that are not valid and commit the valid one minus
> >remove-local-statics-7.c for which we can fill in enhancement request?
> 
> OK.  Keep the original numbering or re-number them to fill up the
> holes left by the deletions?

Since the original testcases never hit mainline, I would preffer them to be renumbered ;)

> 
> >For cases like local-statics-7 your approach can be "saved" by adding simple IPA analysis
> >to look for static vars that are used only by one function and keeping your DSE code active
> >for them, so we can still get rid of this special case assignments during late compilation.
> >I am however not quite convinced it is worth the effort - do you have some real world
> >cases where it helps?
> 
> Um, the well-known benchmark.  ;-)

Very informative, does my implementation handle it well? ;)

I suppose for benchmarks using static where they should not, the analysis that static
is used only in one function and pass to turn it into automatic variable would still
make sense. The approach removing write only variables and relying on FRE to completely
clean up is bit fragile by requiring very complex machinery to work perfectly...

Honza
> 
> >I am rather thinking about cutting the passmanager queue once again after main
> >tree optimization and re-running IPA unreachable code removal after them. This
> >should help with rather common cases where we optimize out code as effect
> >of inlining.
> >
> >This would basically mean running pass_all_optimizations from late IPA pass
> >and scheduling one extra fixup_cfg and perhaps DCE pass at begginig of
> >pass_all_optimizations.
> >
> >Honza
> >
> 
> -Sandra
> 



More information about the Gcc-patches mailing list