https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118570
--- Comment #5 from rguenther at suse dot de <rguenther at suse dot de> --- On Tue, 21 Jan 2025, hubicka at ucw dot cz wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118570 > > --- Comment #4 from Jan Hubicka <hubicka at ucw dot cz> --- > I was thinking of this especially WRT situations where we have user > specified const/pure which we may not be able to detect ourself. > Since we do no optimization before early inline, we throw away those > hints quite aggressively. > > (In case of autodetected const/pure, like in this testcase, of course > gimple passes has all the info to do the job, but clearly this is not > always easy.) > > We used to have way to mark code of inline const/pure function in RTL > via notes which enabled some optimizations, like invariant motion, to > threat the whole block as a single "instruction". This was nasty to > keep intact across optimizations and removed once we got better on tree > optimization. I don't think we want to revive this on gimple level. > > I was not able to come with something smarter. In SSA form perhaps one > can keep have builtin "this SSA name depends only on those SSA names" > which can wrap return value of const/pure function. > > I.e. > wrapped_retval = __builtin_depends_on (retval, a, b) > wrapped_retval = __builtin_depends_on (retval, a, c) > in this testcase which means that wrapped_retval is a copy of retval, > but really can be computed as soon as ssa name a,b (or b,c) are ready. > > That would be more transparent to optimizers, and make easy to discover > that the values are loop invariants. But then we would need to move > relevant computation out of loop... I think invariant motion is mostly about hoisting control flow which we cannot do in full generality. The other case is CSE which is also limited to some extent when it comes to PHIs.
