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

[Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>]

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.

thinking about it again, we now have no easy way how to update ssa form
for virtual operands (since they are not in loop closed ssa form).  So I
think calling update_ssa once per pass is the only solution; for
PR23855, we may update it incrementally just for real operands, which should
not cause performance problems and hopefully also should suffice for its purposes.

Zdenek