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 09:31, Bernd Schmidt wrote:
On 08/03/2010 05:15 PM, Jeff Law wrote:
np. They're clearly not the meat of the patch :-)
On 08/03/10 08:09, Bernd Schmidt wrote:
quilt vs svn problem; now svn added them.
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.
OK. WRT the comment, we might want to just say that BB_MODIFIED is set
at the same time as a block is marked dirty, but is not cleared during a
df_analyze allowing a pass to update the DF information and still know
what blocks were modified.
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.
We have a flags word anyway, so I think using that is the simplest way.
That way we also don't have to worry about BB numbers being stable.
I'm open to suggestions for a better comment.
Duh. I shouldn't review code first thing in the morning.
That's what I meant when I mentioned the call to clear_bb_flags above.
I don't see anything which ever clears BB_MODIFIED, so that bit is going
to accumulate in the block over time.