This is the mail archive of the
mailing list for the GCC project.
Re: ifcvt/crossjump patch: Fix PR 42496, 21803
On 08/03/10 08:09, Bernd Schmidt wrote:
On 08/02/2010 06:15 PM, Bernd Schmidt wrote:
The testsuite changes weren't attached to the patch.
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.
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.