This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] Replace some bitmaps with HARD_REG_SETs
- From: Steven Bosscher <stevenb dot gcc at gmail dot com>
- To: Dimitrios Apostolou <jimis at gmx dot net>
- Cc: gcc-patches at gcc dot gnu dot org, Paolo Bonzini <bonzini at gnu dot org>, Jakub Jelinek <jakub at redhat dot com>
- Date: Sun, 24 Jul 2011 18:43:00 +0200
- Subject: Re: [RFC] Replace some bitmaps with HARD_REG_SETs
- References: <alpine.LNX.2.02.1107241852140.1374@localhost.localdomain>
On Sun, Jul 24, 2011 at 6:08 PM, Dimitrios Apostolou <jimis@gmx.net> wrote:
> Hello all,
>
> attached is my attempt to replace bitmaps, that we are *sure* they will
> never map any pseudo regs, with HARD_REG_SETs. Jakub, I have moved the check
> you suggested, for never surpassing FIRST_PSEUDO_REGS, into hard-reg-set.h,
> that's one of the two patches.
>
> Unfortunately the other patch is a little intrusive and it breaks something.
> I'm out of ideas for some days now, can you spot what's wrong?
Hi Jimis,
Can you please create your patches with the -p option, so that it's
easier to see what function you are changing? Also, even for an RFC
patch a ChangeLog is more than just nice to have ;-)
This hunk in df-problems looks odd:
@@ -2511,9 +2535,9 @@
if (bb_index == EXIT_BLOCK)
{
unsigned regno;
- bitmap_iterator bi;
- EXECUTE_IF_SET_IN_BITMAP (df->exit_block_uses, FIRST_PSEUDO_REGISTER,
- regno, bi)
So this EXECUTE_IF_SET_IN_BITMAP starts with FIRST_PSEUDO_REGISTER
(i.e. works on pseudo registers) ...
+ hard_reg_set_iterator iter;
+ EXECUTE_IF_SET_IN_HARD_REG_SET (df->exit_block_uses, FIRST_PSEUDO_REGISTER,
+ regno, iter)
gcc_unreachable ();
}
else
... and you change it to work only on hard registers. That code looked
like a check to verify that exit_block_uses only contains hard
registers. So you can probably just drop this check.
The only suggestion that I can make for now to investigate the ICE in
reg-stack, is to compare the DF info before your patch and after.
Since your patch does not (or rather: should not) change the logic in
DF, the DF info at reg-stack should be the same. Your ICE suggests
that the register allocator has left a stack register live across an
abnormal edge, and that may be due to changed DF info.
Ciao!
Steven