On 03/16/15 13:27, 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?
:-) Will fix.
@@ -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/ ?
Similarly.
+ 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'll test both. In the common case, the cost is going to be the basic
bookkeeping so that we can compute the transparent property. The actual
computation of transparency and everything else is guarded on having
something in the hash tables -- and the overwhelming majority of the
time there's nothing in the hash tables.
Regardless, I'll pin down boxes and do some testing.
I'm slightly leaning towards trying it even in stage4, but if e.g. richi
disagrees, we could defer it to stage1 too.
I'd be OK either way. I just want us to make a decision one way or the
other :-)
Jeff
