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.
