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]

Re: [new-regalloc] Problem on x86 with initialization of ra_reg_info




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[6] 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
> m);
>           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
the register.


> One of the problems with this extensive use of
> macros is that it is not clear what types are returned by various
> expressions.
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
definition.

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


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