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: Patch 10/9: track subwords of DImode allocnos


On 07/13/2010 10:43 PM, Jeff Law wrote:

> Overall this was relatively straightforward.  You touched on most of the
> non-obvious stuff above.   Answers to most of my questions became clear
> as wrote out the questions.  Here's all that's left:
> 
> 
> In assign_hard_reg, you moved this hunk:
> 
> +          if (allocno_coalesced_p)
> +            {
> +              if (bitmap_bit_p (processed_coalesced_allocno_bitmap,
> +                    ALLOCNO_NUM (conflict_allocno)))
> +            continue;
> +              bitmap_set_bit (processed_coalesced_allocno_bitmap,
> +                      ALLOCNO_NUM (conflict_allocno));
> +            }
> 
> Into the ! ALLOCNO_MAY_BE_SPILLED_P if-clause rather than leaving it to
> execute unconditionally for each conflict allocno.   I don't see the
> reasoning behind this change.

We've found a conflicting object, and looked up the corresponding
allocno.  There are two cases here, either the conflicting allocno has a
hard register already, or it doesn't.  In the first case, we need to
track the conflicts by object, which means we can't ignore the conflict
if we've seen the allocno previously - we might have seen a different
subword.  In the second case, we're just doing some costs bookkeeping,
and here it's OK to skip the allocno if we've seen it before.

Does that make sense?

> I'm happy to let you and Vlad work out the exact timing for when the
> bits get committed.

Vlad, is it better for you if I check in the preliminary bits (6-9) now,
or should I wait until you've had a chance to look at things?


Bernd


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