------- Comment #4 from rguenther at suse dot de  2009-04-08 16:44 -------
Subject: Re:  IPA should compute if a function
 may recurse

On Wed, 8 Apr 2009, hubicka at ucw dot cz wrote:

> Subject: Re:  IPA should compute if a function may recurse
> 
> > Hmm, but will the inlined function not still be visible as such in
> > the cycle?  So what I want to know is whether the local static is
> 
> You have function A with static var used in many places in the program.
> Early inliner inlines A always, so you don't see it anymore and the
> static var essentially behave as non-function-local.
> 
> > referred to in any function the function calls (thus, a more
> > complete analysis would be performed by IPA mod-ref anyway).
> > 
> > > Isn't this however exactly same as asking ipa-pureconst bit?
> 
> well, it is slip here.  I meant ipa-reference.  That one collects all
> direct writes and reads of the static variable in every function and
> propagates it across call making conservative assumption that nonlocal
> calls uses everything.  This seem as far as one can go in this respect
> (except obvious improvements like working per structure fields).
> 
> What am I missing here?

Hmm.  Probably only that it doesn't work for non-local calls as in
this case malloc/free.  The oracle already queries the IPA reference
info:

  /* Check if base is a global static variable that is not written
     by the function.  */
  if (TREE_CODE (base) == VAR_DECL
      && TREE_STATIC (base)
      && !TREE_PUBLIC (base))
    {
      tree callee = gimple_call_fndecl (call);
      bitmap not_written;

      if (callee != NULL_TREE
          && (not_written
                = ipa_reference_get_not_written_global (cgraph_node 
(callee)))
          && bitmap_bit_p (not_written, DECL_UID (base)))
        return false;
    }

so it seems indeed complimentary to that, and in general related
to the fact that we know more about builtins and how they use or
clobber global memory or their arguments.

I'll think about how to solve this in a more general way.

Richard.


-- 


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

Reply via email to