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 08/03/10 09:31, Bernd Schmidt wrote:
On 08/03/2010 05:15 PM, Jeff Law wrote:
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.

The testsuite changes weren't attached to the patch.
quilt vs svn problem; now svn added them.
np. They're clearly not the meat of 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.
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.
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 don't see anything which ever clears BB_MODIFIED, so that bit is going
to accumulate in the block over time.
That's what I meant when I mentioned the call to clear_bb_flags above.
Duh. I shouldn't review code first thing in the morning.


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