[Bug tree-optimization/21712] missed optimization due with const function and pulling out of loops

["rakdver at atrey dot karlin dot mff dot cuni dot cz" <gcc-bugzilla at gcc dot gnu dot org>]

------- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni dot cz  2005-05-22 22:15 -------
Subject: Re:  missed optimization due with const function and pulling out of loops


> > ------- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni dot cz  2005-05-22 21:50 -------
> > Subject: Re:  missed optimization due with const function and pulling out of loops
> > 
> > > const is different from pure, const cannot read from memory.
> > 
> > this is something that have been discussed many times; some people like
> > the definition with "behaves like if" (that enables you for example to
> > cache or precompute the results of the function) more, and it is used in
> > several existing programs.  Anyway, the argument that the function may
> > be costly is valid regardless of whether you want to strictly enforce
> > the no memory access constraint, or whether you use the more useful
> > definition.
> > 
> 
> These people are strictly wrong, and will in fact get burned by the new
> pure/const detection (which is better about recursive calls).
> 
> We shouldn't let people who have the wrong definition of const get in
> the way of optimization

on the other hand, we should not let the definition make the concept
useless.  Being able to make

int something(int i)
{
  static int a[100];

  if (a[i] == 0)
    a[i] = somewhat_slow_computation;
  return a[i];
}

const is fairly useful.

Anyway, moving possibly non-executed const function may cause also
other problems.  Consider

int my_fancy_divide(int x, int z) attribute(const)
{
  return x / z;
}

while (...)
  {
    if (z != 0)
      x = my_fancy_divide (x,z)
  }

Thus you would also have to require the const function to be total.
Making const still more and more useless.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21712