This is the mail archive of the gcc-patches@gcc.gnu.org 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 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





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