Re: [PATCH, MIPS] Fix build after no_new_pseudos

[Richard Sandiford <richard at codesourcery dot com>]

Adam Nemet <anemet@caviumnetworks.com> writes:
> This implements what I mentioned in
> http://gcc.gnu.org/ml/gcc/2007-07/msg00528.html.  It turns out that
> besides mips_split_symbol another helper mips_move_integer is also
> called from a splitter and thus requires the same handling.
>
> My solution is to have the caller specify whether creating pseudos is
> permitted.  Callers usually pass what is returned by
> can_create_pseudo_p() except splitters that always pass false.

I'd like Ian to confirm whether combine splitters are still not allowed
to create new pseudos, or whether this was something that should now be
relaxed.  I got the impression from the thread leading up to this change
that, after df, we're supposed to be able to create pseudo registers
freely before reload.  If this doesn't apply to combine splitters,
perhaps we should go back to setting can_create_new_pseudos_p to false
when calling them.  That seems cleaner than having to pass a
"can_create_pseudos" argument around the backend to simulate the
same behaviour.

> With this change the build completes fine now.  There are still some
> regressions from last week (r126353).  We get an ICE on a few tests:
>
>   gcc.c-torture/compile/nested-1.c:9: internal compiler error: in emit_library_call_value_1, at calls.c:3447
>   Please submit a full bug report,
>   with preprocessed source if appropriate.
>   See <URL:http://gcc.gnu.org/bugs.html> for instructions.
>
> Has anybody seen this?  I don't think it is related to no_new_pseudos.
> I will look at it later today.

This is probably fallout from the __builtin_cache_flush change.  When
reviewing it, I wrongly thought that emit_library_call_value_1 would
convert arguments, so no special conversion code would be needed for
Pmode != SImode.  I'll look into it.

Richard