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 > <seg...@kernel.crashing.org> 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