Hi again,
On Sat, Feb 08, 2020 at 11:54:48AM +0100, Uros Bizjak wrote:
> On Fri, Feb 7, 2020 at 5:41 PM Segher Boessenkool
> <[email protected]> wrote:
> > On Thu, Feb 06, 2020 at 12:13:35PM +0100, Uros Bizjak wrote:
> > > The names of split_before_sched2 ("split4") and split_before_regstack
> > > ("split3") do not reflect their insertion point in the sequence of passes,
> > > where split_before_regstack follows split_before_sched2. Reorder the code
> > > and rename the passes to reflect the reality.
> >
> > Renaming them to other splitN doesn't help much :-/ Having stable names
> > is more important (some archs actually use these names), I'd say. But
>
> True, this is why I took care to found and fix all references to
> existing names. It is a simple substitution of old name with a new.
Yeah, and reading the patch is a bit challenging ;-) If we had real
names here, this would be simpler. Something for the future.
> I'm not familiar with tree passes, how the situation is handled there.
> If a new instance of the same pass is inserted before existing pass,
> does name of the existing pass get changed?
I don't know either.
> > > +bool
> > > +pass_split_before_regstack::gate (function *)
> > > +{
> > > +#if HAVE_ATTR_length && defined (STACK_REGS)
> > > + /* If flow2 creates new instructions which need splitting
> > > + and scheduling after reload is not done, they might not be
> > > + split until final which doesn't allow splitting
> > > + if HAVE_ATTR_length. */
> > > + return !enable_split_before_sched2 ();
> > > +#else
> > > + return false;
> > > +#endif
> > > +}
> >
> > flow.c was deleted in 2006... Is this split still needed at all? If
> > so, change the comment please? :-)
>
> Hm, I don't know in general, but x86 needs a late split at the point
> where instantiated registers won't change in the insn.
Right, but the explanation given in the comment is very out of date.
> As you suggested in the other mail, the issue with many late split
> passes (passes 3-5) should be rewiewed, considering also other (e.g.
> non-stack regs) targets.
Yeah. But that is not a stage 4 thing. Your patch is safe for stage 4
as far as I can see.
Segher
