On Tue, Jun 3, 2014 at 6:19 PM, Jan Hubicka <hubi...@ucw.cz> wrote: >> On Mon, Jun 2, 2014 at 8:59 PM, Jan Hubicka <hubi...@ucw.cz> wrote: >> >> >> >> Yeah, I discussed this with martin today on irc. For aliasing we'd like >> >> to know whether a decl possibly has its address taken. Currently we only >> >> trust TREE_ADDRESSABLE for statics - and lto might change those to hidden >> >> visibility public :( >> >> >> >> So we want deck_referred_to_by_single_function >> > >> > OK, I will implement this one in IPA mini-pass. It is easy. >> > This property changes by clonning and inlining. What Martin wants to use >> > it for? >> > (I.e. my plan would be to compute it as last IPA pass making it useless for >> > IPA analysis&propagation) >> >> He doesn't want to use it but we talked and he said he'd have a look. >> >> Note that it's important the decls are not refered to by global initializers >> either. >> >> Why is a new pass necessary - can't the IPA reference maintaining code >> update some flag in the varpool magically? > > If the code to add/remove reference was updating the flag, it would became > out of > date as we remove callgraph during the late compilation (we do not keep > references for > functions we already compiled). > I do not want the flags to be computed before end of IPA queue so they won't > become > out of date as we clone/inline. > > We basically need to walk references and check that they are all functions & > either one given function F or a clones inlined to it. Assuming that function > does not have unbounded number of references to given variale, this is > basically constant time test. >> >> >> and deck_may_have_address_taken. >> > >> > We currently clear TREE_ADDRESSABLE for statics that have no address taken >> > at >> > WPA time and that ought to keep the flag cleared at ltrans (I think I even >> > made >> > testcase for this) >> > >> > What I think we could improve is to not consider string functions as ADDR >> > operations >> > for this analysis, i.e. it is common to only memset to 0. >> > >> > How may_have_address_taken would differ here? >> >> I want tree.h:may_be_aliased to return false if a decl doesn't have its >> address >> taken. We don't trust TREE_ADDRESSABLE for TREE_PUBLIC/DECL_EXTERNAL >> decls because other TUs may take the address. I want the check to be >> replaced >> with sth more symtab aware, that is, bring in benefits from LTO (and at the >> same >> time be not confused by statics brought public with hidden visibility). > > > I see, are you sure you need to ignore TREE_ADDRESSABLE for PUBLIC/EXTERNAL? > I belive frontends are resposible to set them for all data that may have > address > taken (even externally) and IPA code maintains it - we clear the flagonly for > variables that are static.
Not sure - we've always not trusted this flag on public/externals. Probably because there could be aliases to them that have their address taken? (well, that's true for locals as well ...) That said, having a varpool way of querying whether a decl may be aliased by a pointer would be nice (with bonus points of handling the alias case). > Or we can just set the flag to true for externally visible vars ealry in IPA > queue if this is false. Well, let me do a simple check (remove the restriction and bootstrap/test). Richard. > Honza >> >> Richard. >> >> > Honza