On Thu, May 19, 2022 at 09:22:32AM -0400, Andrew MacLeod wrote: > On 5/18/22 16:40, Segher Boessenkool wrote: > >On Wed, May 18, 2022 at 04:24:06PM -0400, Andrew MacLeod wrote: > >>On 5/18/22 14:13, Segher Boessenkool wrote: > >>>"Side effect" already has a meaning, very commonly used in language > >>>theory, and even in the C standard itself: a function has a side effect > >>>if it does something more than just return a value: if it changes state. > >>>This can be some I/O, or it can just be writing to some non-local data. > >>> > >>>Side effects are crucial to what a compiler does, and they are used all > >>>over the place (the gcc/ dir has some thousand mentions of it for > >>>example). > >>> > >>>Please don't make life hard for everyone by overloading this term. > >>> > >>I'm open to suggestions for a better term! > >Glad to hear that, and this isn't set in stione yet! > > > >>Is there a commonly used alternate term to describe an observable effect > >>on the value of an input operand? > >I'd use something with "known" in the name. But: > > > >As far as I understand what you are doing this is not an effect on the > >operand at all! It cannot be one even, the operand is an input only > >after all. Instead, it changes what is known about the value of that > >input: it cannot be 0 in this case, it is known to not be 0. > > > >This is similar to other known value things we have in GCC already. Can > >you not just use one of those, even? What are the benefit to this new > >abstraction? > > Well, This is a component of ranger tracking value ranges.. it is > recording the "side-effect" of the stmt on the known range of an object. > The file is called "gimple-range-side-effect.h"
So the file name is confusingly wrong as well. > Its a generalization of how ranger tracks non-null pointer values, > enabling it to track arbitrary observable ranges values. (The old > mechanism also utilized immediate-use chains, which prevented it from > being utilized in gimple-folding) > > WIth this change, we can also track things like a = b / c causing the > effect that c is known non-zero after the statement if there were no > traps, or https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31178 , which > after 15 years, we can now simply indicate that for a = b >> c , its > only defined behaviour if c is in the range [0, PRECISION(b)] > > So its basically just a generalization of how we track known values > within the range system. Sure. Just the name is harmful :-( Segher
