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