On 11/10/2017 01:00 AM, Richard Biener wrote: > > It's the usual issue with an optimizing compiler vs. a static analyzer. > We try to get rid of the little semantic details of the input languages > that in the end do not matter for code-generation but that makes > using those semantic details hard (sometimes the little details > are useful, like signed overflow being undefined). > > For GIMPLE it's also often the case that we didn't really thoroughly > specify the semantics of the IL - like is an aggregate copy a > block copy (that's how we expand it to RTL) or a memberwise copy? > SRA treats it like the latter in some cases but memcpy folding > turns memcpy into aggregate assignments ... (now think about padding). Understood far too well. In fact, I was looking at the aggregate copy stuff not terribly long ago and concluded that depending on either particular behavior was undesirable. Something (glibc IIRC) was depending on the padding being copied because they were actually shoving live data into the pad. Ugh.
> > It's not that GCC doesn't have its set of existing issues with > respect to interpreting GIMPLE semantic as it seems fit in one way > here and in another way there. I'm just always nervous when adding > new "interpretations" where I know the non-existing formal definition > of GIMPLE leaves things unspecified. Right. No disagreement from me. We have these issues and address representation is just one of a class of things which we can represent in gimple that don't "properly" map back to the source language. And that's probably inherent in the lowering from the source language to something like GIMPLE. > > For example we _do_ use array bounds and array accesses (but _not_ > and for now _nowhere_ if they appear in address computations!) > to derive niter information. At the same time, because of this > exploitation, we try very very hard to never (ok, PRE above as a > couter-example) create an actual array access when dereferencing > a pointer that is constructed by taking the address of an array-ref. > That's why Martin added the warning to forwprop because that pass, > when forwarding such addresses, gets rid of the array-ref. Right. IIRC there's some BZs around this issue that come up release-to-release related to how we've changed this code over the last few years. > >>>> Or, if that's not it, what exactly is your concern with this >>>> enhancement? If it's that it's implemented in forwprop, what >>>> would be a better place, e.g., earlier in the optimization >>>> phase? If it's something something else, I'd appreciate it >>>> if you could explain what. >>> >>> For one implementing this in forwprop looks like a move in the >>> wrong direction. I'd like to have separate warning passes or >>> at most amend warnings from optimization passes, not add new ones. >> I tend to agree. That's one of the reasons why I pushed Aldy away from >> doing this kind of stuff within VRP. >> >> What I envision is a pass which does a dominator walk through the >> blocks. It gathers context sensitive range information as it does the walk. >> >> As we encounter array references, we try to check them against the >> current range information. We could also try to warn about certain >> pointer computations, though we have to be more careful with those. >> >> Though I certainly still worry that the false positive cases which led >> Aldy, Andrew and myself to look at path sensitive ranges arent' resolved >> and will limit the utility of doing more array range checking. > > I fear while this might be a little bit cleaner you'd still have to > do this very very early in the optimization pipeline (see all the > hard time we had with __builtin_object_size) and thus you won't catch > very many cases unless you start doing an IPA pass and handle propagating > through memory. Which is when you arrived at a full-blown static > analyzer. Could be. We won't know until we give it a whirl. FWIW, we saw far more problems due to the lack of path sensitivity than anything. Nothing I'm suggesting in this thread addresses that problem. Doing a really good job for warnings with path sensitivity shares a lot of properties with jump threading. Specifically that you need to propagate range knowledge along a path, often past join points in the CFG (ie, you're propagating beyond the dominance frontier). Once you do a good job there, I'd strongly suspect that IPA issues would then dominate. Jeff
