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: auto-detected pure functions are ``inlined'' in spire of noinline


Hi Alex,

On 5 Dec 2003, Alexandre Oliva wrote:
> Now I'm no longer sure, and thought of two ways to address the problem:
>
> (i) adjust the docs of attribute noinline so as to mention this case,
> such that it is not surprising to those who learn about noinline in
> the docs and then don't understand why it's not working, or
>
> (ii) arrange for attribute noinline to disable the code that
> auto-detects the purity/constness of functions.
>
> I have implemented and tested both changes, but I can't decide which
> one I like the best.


Alternatively, there's a third option.  Add the check for the noinline
attribute to the tests in expand_call, that actually implements this
optimization.  The source code at line 2243 of calls.c reads...

  /* If the result of a pure or const function call is ignored (or void),
     and none of its arguments are volatile, we can avoid expanding the
     call and just evaluate the arguments for side-effects.  */
  if ((flags & (ECF_CONST | ECF_PURE))
      && (ignore || target == const0_rtx
          || TYPE_MODE (TREE_TYPE (exp)) == VOIDmode))


By adding the test for no-inline here, we still mark the function as
constant, so that the RTL optimizers know that memory isn't clobbered,
etc..., but you're still able to set a break-point at the desired routine.

You'll need to check whether the function call subsequently gets
eliminated by the RTL optimizers, but if it can be made to work, it
may have benefits over scheme (ii) above.


Just a thought.

Roger
--


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