ifcvt/crossjump patch: Fix PR 42496, 21803

[Jeff Law]

  On 08/03/10 08:09, Bernd Schmidt wrote:
> On 08/02/2010 06:15 PM, Bernd Schmidt wrote:
>> On 08/02/2010 06:05 PM, Jeff Law wrote:
>>> OK.  If you could highlight in a quick blurb what changed it'd be
>>> appreciated -- it'll save me from having to look over the whole thing
>>> again to figure out what changed from the previous version.
>> I intend to make the change I previously mentioned to add a per-bb flag
>> which notes it's been modified, so that we can use that on the second
>> pass to decide whether or not to try to optimize it, rather than using
>> df_get_bb_dirty (since that gets cleared on df_analyze).  Earlier
>> versions of gcc had a BB_DIRTY bit in bb->flags, I'll reintroduce that
>> as BB_MODIFIED.  That's cheaper to test anyway.
>>
>> The other change I'll make is to be slightly more careful wrt. volatile
>> asms, not moving memory references across them.
> Did that, and also fixed a crash I saw with a PPC cross compiler -
> mustn't try to look at insns in EXIT_BLOCK.  Note that there's still a
> call to clear_bb_flags which I think is left over from before we were
> using df_get_bb_dirty and now has a purpose again.
>
> New patch below; search for BB_MODIFIED, ASM_OPERANDS and EXIT_BLOCK_PTR
> to find these changes.  Also, added the two testcases for i386 as well
> and Paolo's suggestion of a gcc_assert before df_analyze.
>
> Bootstrapped and regression tested on i686-linux.
>
>
> Bernd
The testsuite changes weren't attached to the patch.

I guess one could ask whether or not we really need to carry a bit in 
the BB structure if its only use is head merging -- we could just as 
easily have a bitmap indicating what blocks changed that we allocate & 
free within cfgcleanup.

If we go with the BB_MODIFIED bit in the BB structure, then I would 
suggest documenting BB_MODIFIED slightly better; you describe how it's 
currently used, but I think it's just as important to describe why one 
would use it rather than check if the block is dirty.

I don't see anything which ever clears BB_MODIFIED, so that bit is going 
to accumulate in the block over time.  I don't think it's a correctness 
issue right now, but it could be one day.  With its "like bb_dirty, but 
not quite" semantics we ought to have some clarity on when its cleared 
so that nobody gets surprised in the future.

jeff