This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH][RFA] [PR rtl-optimization/64317] Enhance postreload-gcse.c to eliminate more redundant loads
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Jeff Law <law at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Mon, 16 Mar 2015 20:27:36 +0100
- Subject: Re: [PATCH][RFA] [PR rtl-optimization/64317] Enhance postreload-gcse.c to eliminate more redundant loads
- Authentication-results: sourceware.org; auth=none
- References: <5500B3FC dot 7040303 at redhat dot com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
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.
Jakub