Re: [PATCH][RFA] [PR rtl-optimization/64317] Enhance postreload-gcse.c to eliminate more redundant loads

[Jeff Law <law at redhat dot com>]

On 03/16/2015 01:27 PM, Jakub Jelinek wrote:
> On Wed, Mar 11, 2015 at 03:30:36PM -0600, Jeff Law wrote:
> > +#ifndef GCC_GCSE__COMMONH
> > +#define GCC_GCSE__COMMONH
>
> GCC_GCSE_COMMON_H instead?
>
> > @@ -1308,8 +1396,19 @@ gcse_after_reload_main (rtx f ATTRIBUTE_UNUSED)
> >
> >     if (expr_table->elements () > 0)
> >       {
> > +      /* Knowing which MEMs are transparent through a block can signifiantly
> > +	 increase the number of reundant loads found.  So compute transparency
> > +	 information for for each memory expression in the hash table.  */
>
> s/for for/for/ ?
>
> > +      df_analyze ();
> > +      /* This can not be part of the normal allocation routine because
> > +	 we have to know the number of elements in the hash table.  */
> > +      transp = sbitmap_vector_alloc (last_basic_block_for_fn (cfun),
> > +				     expr_table->elements ());
> > +      bitmap_vector_ones (transp, last_basic_block_for_fn (cfun));
> > +      expr_table->traverse <FILE *, compute_expr_transp> (dump_file);
> >         eliminate_partially_redundant_loads ();
> >         delete_redundant_insns ();
> > +      sbitmap_vector_free (transp);
> >
> >         if (dump_file)
> >   	{
>
> What effect does the patch have on compile time on say x86_64 or ppc64?
>
> I'm slightly leaning towards trying it even in stage4, but if e.g. richi
> disagrees, we could defer it to stage1 too.
Oh yea, forgot to mention, for PPC the compile-time testing results were 
essentially the same -- there's significantly more variation in the 
timings, but the before/after comparisons were in the noise.

Jeff