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
