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]
Other format: [Raw text]

Re: [PATCH, MIPS] Fix build after no_new_pseudos


Richard Sandiford <richard@codesourcery.com> writes:

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

I think we should fix combine to permit splitters to create new
pseudos.  I don't think it does us any useful service to prohibit
them.

Ian


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