This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Eliminate write-only variables


> On 05/18/2014 08:45 PM, Sandra Loosemore wrote:
> >On 05/18/2014 02:59 PM, Jan Hubicka wrote:
> >>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.  ;-)
> 
> I looked at the generated code for this benchmark and see that your
> patch is indeed not getting rid of all the pointless static
> variables, while ours is, so this is quite disappointing.  I'm
> thinking now that we will still need to retain our patch at least
> locally, although we'd really like to get it on trunk if possible.

Yours patch can really be improved by adding simple IPA analysis to work
out what variables are refernced by one function only instead of using
not-longer-that-relevant local static info.
As last IPA pass for each static variable with no address taken, look at all
references and see if they all come from one function or functions inlined to
it.
> 
> Here is another testcase vaguely based on the same kind of
> signal-processing algorithm as the benchmark, but coded without
> reference to it.  I have arm-none-eabi builds around for both 4.9.0
> with our remove_local_statics patch applied, and trunk with your
> patch.  With -O2, our optimization produces 23 instructions and gets
> rid of all 3 statics, yours produces 33 and only gets rid of 1 of
> them.
> 
> Of course it's lame to use static variables in this way, but OTOH
> it's lame if GCC can't recognize them and optimize them away, too.
> 
> -Sandra
> 

> void
> fir (int *coeffs, int coeff_length, int *input, int input_length, int *output)
> {
>   static int *coeffp;
>   static int *inputp;
>   static int *outputp;

Here inputp read is rmeoved only at 101.dceloop1 pass. That is really late.
coeffp is removed late, too.

>   int i, c, acc;
> 
>   for (i = 0; i < input_length; i++)
>     {
>       coeffp = coeffs;
>       inputp = input + i;
>       outputp = output + i;
>       acc = 0;
>       for (c = 0; c < coeff_length; c++)
> 	{
> 	  acc += *coeffp * *inputp;
> 	  coeffp++;
> 	  inputp--;
> 	}

It seems like AA can not work out the fact that inputp is unchanged until that
late.  Richi, any ideas?

Honza
>       *outputp = acc;
>     }
> }
> 
>   


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]