Re: [RFC/RFA] PR/26830 part 2, delay SSA updating in loop header copying

["Richard Guenther" <richard dot guenther at gmail dot com>]

On 4/2/06, Zdenek Dvorak <rakdver@atrey.karlin.mff.cuni.cz> wrote:
> Hello,
>
> > this patch aims at fixing the compile-time-hog part of PR/26830.  Here
> > we have a BB with several thousands PHIs, each with a thousand
> > arguments.  We also have more than 500 loops whose headers we can copy
> > and, each time a header is copied, tree_duplicate_sese_region calls
> > update_ssa which walks the PHIs to rewrite them.
> >
> > Zdenek originally wrote special code to update the SSA form, but it was
> > subsequently removed as part of the tree-cleanup-branch merge.  It seems
> > to me, however, that tree_duplicate_sese_region is only concerned with
> > the CFG (except for add_phi_args_after_copy, but this function mostly
> > looks at the CFG as well to get the PHI arguments).  If this is true, we
> > can completely delay the SSA update until the end of the loop header
> > copying pass.  This is what the pass does.
> >
> > With it, times for PR/26830 are back to sane values (two times slower
> > than 4.0, but that's expected because salias is still creating all those
> > memory tags).  Memory is still rocketing up to 1.4 gigabytes though, and
> > that's also an aliasing problem as far as I can tell.
> >
> > I don't have any confidence in it, though, and I'm only submitting it
> > because it survived bootstrap (regtest is running) and because I cannot
> > afford to sit and write the manual SSA update code.  Zdenek, do you
> > remember why you didn't do the update just once?
>
> I felt that keeping the ssa form up-to-date is safer, as long as it does
> not cause performance problems (also, it matched the previous
> semantics).
>
> I would like to try reintroducing the special ssa form updating for this
> case first, and to compare the timings with your patch.  Calling
> update_ssa just once per optimization is safe now, but if we happen to
> need to do some code analysis during loop header copying (see eg. the
> proposed patch for PR23855), this might cause problems.

I think it looks safer if we consider it for 4.1, where we won't fix
23855.  If it actually _is_ safe, that is.

Richard.