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/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.
>> Bernd
> The testsuite changes weren't attached to the patch.

quilt vs svn problem; now svn added them.

> 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.

> 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.


Attachment: hmtest.diff
Description: Text document

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