On March 16, 2015 8:45:18 PM GMT+01:00, Jeff Law <l...@redhat.com> wrote:
>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
If it fixes a regression then OK for trunk, otherwise please wait for stage 1
to open.
Richard.
>other :-)
>
>Jeff
