This is the mail archive of the
mailing list for the GCC project.
Re: Patch 10/9: track subwords of DImode allocnos
- From: Jeff Law <law at redhat dot com>
- To: Bernd Schmidt <bernds at codesourcery dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>, "Vladimir N. Makarov" <vmakarov at redhat dot com>
- Date: Wed, 14 Jul 2010 13:06:36 -0600
- Subject: Re: Patch 10/9: track subwords of DImode allocnos
- References: <4C1B7BC0.email@example.com> <4C1F9B96.firstname.lastname@example.org> <4C3CCFE4.email@example.com> <4C3CD626.firstname.lastname@example.org>
On 07/13/10 15:09, Bernd Schmidt wrote:
On 07/13/2010 10:43 PM, Jeff Law wrote:Yes. Makes perfect sense now. I might have just been burned out when I
stumbled across that somewhat odd hunk.
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)))
+ 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?