Re: [PATCH] Fix PR84086

[Richard Biener <rguenther at suse dot de>]

On Mon, 29 Jan 2018, Jakub Jelinek wrote:

> On Mon, Jan 29, 2018 at 11:05:28AM +0100, Richard Biener wrote:
> > 
> > This fixes another case of the SCEV cache containing references to
> > released SSA names.  This time it is the vectorizer releasing defs
> > of OMP_SIMD uses.  Instead of pluggin this hole like the others,
> > sprinkling scev_reset[_htab] calls throughout passes, it plugs
> > the holes in flush_ssaname_freelist which is called after each
> > pass TODO and is used to flip the two SSA name freelists we have
> > now.
> > 
> > I'm not sure maintaining SCEV info across passes is worth the
> > trouble we're seeing, also given its implementation makes flushing
> > info for a particular SSA name / loop expensive (and thus not
> > implemented).  But it's not the time to change this...
> > 
> > Now, would you rather prefer sticking a scev_reset[_htab] into
> > the vectorizer?
> 
> But any other pass can invalidate it similarly, can't it?

Yes.  But it's only during the loop pipeline that we cache SCEV
across passes (a bad decision IMHO).

> I think your patch is ok, if the scev_reset_htab call isn't too expensive
> all the time.  If scalar_evolution_info is NULL, it will return right away,
> if it is non-NULL but the htab is empty, it should be just subtraction of
> two scalar fields from the htab and finding out the difference is 0 and not
> doing anything.

Yeah.  For GCC 9 I'll see to rip the caching out but we've started
to use scev_initialized_p () as a flag to decide whether a pass
runs within the loop pipeline or not...

Richard.