This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [tree-ssa] Removing useless/redundant "const" calls


Hi,

On Thu, 12 Jun 2003, Zack Weinberg wrote:

> This seems like an opportune moment to point out that calls to noreturn
> functions shouldn't count as side effects when determining whether
> functions are pure or const.

Careful.  For instance also throw() is basically a noreturn function.  Is
a function containing a throw free from side-effects?  I.e. is
unpredictable control flow change a side-effect or not?  We can define it
this or that way, and either one would be arguably correct.  We should
define it to be least surprising.  For instance:

  int get_me (int i) {
    if (i < 0)
      throw("worked");
    return i + 1;
  }

  void f (void) {
    try {
      get_me (-1);
    } catch (char *p) {
      printf ("%s\n", p);
    }
  }

Per you definition get_me() would be recognized as pure (even as const!),
and hence the call to it in f() would be optimized away.  (Not using the
return value of pure functions is one of the only two reasons to delete a
call to them).

I think that's not really expected, as normally the expection will occur.

This leads me to the opinion, that unpredictable control flow change _is_
a side-effect, and functions containing such are not pure.  This includes
calls to abort().

It's not that we would gain much from marking such functions pure
automatically (they will be optimized away not that often).  But what
could be done instead is to allow the user to explicitely define functions
as pure (per attribute), _even_ if it contains calls to non-pure noreturn
functions.  So I'm just against detecting such functions automatically as
pure.


Ciao,
Michael.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]