This is the mail archive of the
mailing list for the GCC project.
Re: [new-regalloc] Problem on x86 with initialization of ra_reg_info
- To: Geert Bosch <bosch at gnat dot com>
- Subject: Re: [new-regalloc] Problem on x86 with initialization of ra_reg_info
- From: Daniel Berlin <dberlin at redhat dot com>
- Date: Fri, 2 Feb 2001 13:37:43 -0500 (EST)
- cc: Richard Henderson <rth at redhat dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
On Fri, 2 Feb 2001, Geert Bosch wrote:
> Hi Daniel,
> The new register allocator crashes badly on x86 at line 703 of
> new-regalloc.c, trying to access the degree of ra_reg_info which
> is 0:
> /* If it's of significant degree, place it on the spill_worklist. */
> if (ra_reg_info[reg_num]->degree >= reg_freedom (reg_num))
> if (rtl_dump_file != NULL && debug_new_regalloc > 1)
> fprintf (rtl_dump_file, "Inserting %d onto spill_worklist\n", reg_nu
> SET_REGNO_REG_SET (spill_worklist, reg_num);
> This seems to be a result of ra_reg_info not being initialized properly.
> Only registers 0, 3 and 7 were initialized (%eax, %edx and %esp).
> This seems to be because the test for is_reg_candidate returns false
> for all other registers.
> /* Determine if regno is a candidate for this pass of register
> allocation. */
> static int
> is_reg_candidate (regno)
> unsigned int regno;
> return DF_REGNO_FIRST_DEF (df_analyzer, regno) != 0;
> There is not really a comment that tells what the condition is
> for a register to be a candidate for register allocation, and
> I can't figure out what DF_REGNO_FIRST_DEF means as this macro
> is undocumented.
df.h should make it pretty clear that it's finding the first definition of
> One of the problems with this extensive use of
> macros is that it is not clear what types are returned by various
DF_REGNO_FIRST_DEF returns a struct ref *.
> I would guess that it would somehow return the instruction where
> the given register is first defined in the dataflow information
> contained in df_analyzer. Then however it doesn't make sense to
> only consider a register to be a candidate for allocation if it
> actually is defined somewhere.
Yes it does. There is no point in considering non hard, non fixed
registers, that are never set, anywhere.
If we did, we'd be considering registers that were used before their
> I'm trying to understand this code as I'd like to help getting it
> in good shape, so please bear with my comments, I hope they'll
> improve the code in the end.