ifcvt/crossjump patch: Fix PR 42496, 21803

Bernd Schmidt bernds@codesourcery.com
Thu Jul 29 17:43:00 GMT 2010


On 07/29/2010 07:23 PM, Jeff Law wrote:
>  On 07/27/10 15:35, Bernd Schmidt wrote:
>> Thanks for looking at this, Jeff.
>>
>> On 07/27/2010 07:09 PM, Jeff Law wrote:
>>> It seems to me implementing this optimization well requires insn
>>> movement which is going to affect register lifetimes.   Furthermore,
>>> this optimization is sitting inside a while (changed) style loop.  At
>>> the least we need to mark blocks where the life data has become
>>> inaccurate so that we don't mis-optimize based on inaccurate life data.
>>> I haven't thought deeply about the problem, but it may well be the case
>>> that as the cfgcleanup loop iterates new opportunities may be exposed
>>> and thus it'd be useful to go ahead and update the life information.
>> I'm fairly certain I've observed this to happen.  Note that other
>> transformations done in cfgcleanup can make life information inaccurate
>> before we even try to run head merging, making it impossible to do the
>> analysis.
> If that occurs, we will have set block_was_dirty and changed which tells
> head merging to do nothing.  At the bottom of the loop we call
> df_analyze to get things up-to-date, then start the next iteration which
> then allows head merging its chance at any blocks which were dirty on
> the previous iteration, right?

That's the plan.

> Presumably there's no blocks marked as dirty when cfgcleanup starts :-)

I guess there might be if the previous pass modifies things that affect
liveness.  The effect would be to postpone head-merging until the second
pass of try_cleanup_cfg.  Also, as I said other cfgcleanup
transformations can mark blocks dirty.  If there's a lot going on we'll
just have to iterate until nothing can be improved anymore.


Bernd



More information about the Gcc-patches mailing list