This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ifcvt/crossjump patch: Fix PR 42496, 21803

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
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?

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]