This is the mail archive of the
mailing list for the GCC project.
Re: DECL_CALL_CLOBBERED tweek
> >This is done by reset_cc_flags pass and I am now starting to wonder why
> >it is needed at all? What is the semantic of CALL_CLOBBERED on static
> >variables and why it differs on individual functions? (I can see that
> >perhaps function that is known to never reach functions that might
> >clobber the variable might want to have this flag clear unlike other
> >function that does call something clobbering it. But I am surprised we
> >do that especially because I've temporarily disabled IPA AA passes for
> It may be a case where one function f() calls no clobbering functions,
> while a second function g() does. So the CC state for the same decl is
> considered different for f() and g().
Ineed, still I wonder how it happens with all IPA passes other than
inliner disabled in my tree. But I guess it might be just one function
having no calls at all.
> >I will benchmark it on the testcase suggested and prepare version with
> >inline functions unless we can come with better solution to this
> >problem. If this flag really needs to be local to functions I am
> >affraid I don't have better answer than this patch even if it turns out
> >to be costy :(
> Well, perhaps this will give us another incentive to move to a global
> dense DECL_UID space. But in the meantime, we may need to move to this.
> Dan may have other ideas as he worked on this before.
I intended to write reply to your email about two uids, as I still can
get happy about either sollution I can think of.
If I get it right, your idea is basically:
1) have one space for static DECL_UIDs
2) have separate space for each functions
So function local passes will always have two arrays, one of size of
all static variables in program, other of size of all local variables
indexed by DECL_UIDs with simple check
IPA passes would need to maintain array for each function, probably in
array of arrays indexed by cfun->UID.
I think I can work on progression towards that, probably a bit
incrementally by first inventing DECL_VAR_LUID and then convernting
current DECL_UID users to new infrastructure, or possibly even keeping
bot indexes (DECL_UID as it is makes a lot of sense for some code who is
interested to deal with all DECLs, not just variables, while for sake of
density we probably want to consider only variables in our LUIDs).
What I am however concerned about is that with LTO, we can have quite a
lot of static variables in the program and maintaining info for all
unreferenced static variable per every function might kill us by
quadratic growth. This seems considerable difference to my current
scheme where I can assign UIDs via annotations locally in each function
in dense matter and have size bound by number of referenced variables,
Disadvantage is the obvious extra hashtable query for each access to UID
of static variable.
In genereal I am very hestiated to tie quadratic behaviour into design
of such a basic API to optimizers. I can try to get some numbers
(basically counting number of functions and number of non-function
symbols in some larger application and multiplying the numbers. But
common C++ stuff gets hounderds of thousdands of them as we all know
from dynamic linking threads.
What do you think?