Re: new-regalloc vs alpha

[Daniel Berlin <dberlin at redhat dot com>]

On Tue, 30 Jan 2001, Richard Henderson wrote:

> I've run into two problems so far trying this on alphaev6-linux.
>
> One, you should never try to allocate fixed registers, even if they
> are in the proper register class.  Fixed with attachment one.

I actually noticed this when fixing the dataflow bug yesterday. The
problem with just doing it the way you have it is that you've taken away
information from the allocator.  I was trying to decide whether to do it
the way your patch does, or insert them as precolored nodes and make them
interefere with everything. I figured i'd sleep on it and look at what
others do.

> > Two, reload has a sort of phase ordering problem with local-alloc.
> I'm not sure how this doesn't show up with current code.

I run into quite a few of these "I have no idea how this actually works
right now, it shouldn't".

> The sequence of events is
>
>   * The code around line 1140 in update_equiv_regs decides to re-emit the
>     set of a reg near it's (only) use, we lose the memoized INSN_CODE
>     that we'd had before.
>
>   * The allocator chooses a hard reg that is not valid for that insn.
>
>   * reload calls alter_reg for each pseudo, which updates the REGNO
>     of each pseudo, which means the bogus hard reg is reflected in
>     the insn.
>
>   * eliminate_regs_in_insn calls recog_memoized, which fails.  We abort.
>
> The quickest way around this that I saw is to have update_equiv_regs
> copy the insn code while re-emitting the instruction.
>
> I've not committed either of these patches.
>
> You may wish to examine this case further (_fixunsdfsi), as the
> allocation is particularly bletcherous, and results in quite a
> few bogus fp->int and int->fp copies.

Weird. We should't be giving a register to something that isn't compatible
with that register. we use HARD_REGNO_MODE_OK to verify the register can
hold something of the mode of the thing we want to put in it.

--Dan
 >
>
>
> r~
>