CSE opportunity missed with inline functions (but not with macros)

[Melissa O'Neill]

When I replaced some macro definitions with inline functions (following
the claim ``An inline function is as fast as a macro'' in the heading
of section 4.30 of the GCC manual, I was disappointed to find that the
generated code got worse. Suddenly, the optimizer started missing a
simple CSE opportunity.

Here's a reduced test case, based on my production code:

--- csetest.i ------------------------------------------------------
# 1 "csetest.c"
extern int *process_info(void) __attribute__((const));

extern inline void procinfo_set(int newval)
{
  int *const info_ptr = process_info();
  if (info_ptr)
      *info_ptr = newval;
  else
      abort();
}

void print_procinfo(void)
{
  procinfo_set(17);
  procinfo_set(27);
}
--------------------------------------------------------------------

The function process_info represents an expensive library function (e.g.
one that does a bunch of system calls) that always returns a (per-thread)
constant.

CSE ought to spot that process_info returns a constant and only
perform one call. But it doesn't (on m68k-next-nextstep3 anyway).

But CSE does work as expected if I manually inline the calls (mirroring
what would occur if I used a macro rather than an inline function).
Similarly it works if I remove the else clause.

Code for these two test cases and the assembler output can be found on
my web page at http://www.cs.sfu.ca/~oneill/personal/csetest/

    Melissa.

P.S. I was also disappointed by the optimizer's output for the hand-inlined
version, since the optimizer didn't realize that both ifs were testing
the same condition and so tested it twice. It also (perhaps because of
this) missed removing the redundant store.