Re: rtx_equal_function_value_matters

[Jakub Jelinek <jj at sunsite dot ms dot mff dot cuni dot cz>]

>   > I thought about this problem some more, and I think it is bogus that
>   > local alloc etc. is blowing up.  Local alloc is blowing up because
>   > regclass() is now generating new pseudos and nobody between regclass()
>   > and local alloc resize the reg_info varray.
> When/where/how are we generating new pseudos via regclass?  There's nothing
> that says we can't create new ones during the first regclass pass.  Though it
> is definitely not valid to create them during the second regclass pass.

scan_one_insn calls gen_move_insn.
> 
> Seems to me that we ought to have a global variable that indicates the
> exact moment after which we are not allowed to create new pseudos.

That's what I proposed in my first mail. I think simply replacing a bunch of
(reload_in_progress || reload_completed) tests with
(cannot_generate_new_rtxs) or whatever (you'll probably name it better), it
would fix a lot of bugs that may show up randomly.

> 
> gen_reg_rtx uses (reload_in_progress || reload_completed), but that's not the
> correct test since it is incorrect to create any new pseudos after the first
> life analysis pass has run.
> 
> I worry that other code makes the same approximation.  I know the PA port does.

sparc was using a lot of these assumptions. On the other side, Alpha uses
the (!rtx_equal_function_value_matters), which is much more strict and
changing it on the alpha could help there as well.

Cheers,
    Jakub
___________________________________________________________________
Jakub Jelinek | jj@sunsite.mff.cuni.cz | http://sunsite.mff.cuni.cz
Administrator of SunSITE Czech Republic, MFF, Charles University
___________________________________________________________________
Ultralinux - first 64bit OS to take full power of the UltraSparc
Linux version 2.1.129 on a sparc64 machine (3958.37 BogoMips)
___________________________________________________________________