On Wed, 11 Jun 2014, Jan Hubicka wrote:
> > Note that I'm happy to revert the change.
> >
> > I am hesitant to any approach that overloads TREE_ADDRESSABLE even more.
> > It already is used for two (slightly) different things - first the
> > "old" meaning that the address of the symbol is needed, second, that
> > the symbol is aliased by pointers. Those are of course related, but
> > as you see they are not 100% equivalent.
>
> An alternative is surely to add a flag to varpool. But again, having several
> flags of similar names and slightly different meanings doesn't make things
> more
> maintaible either.
> >
> > As I already added DECL_NONALIASED (for VAR_DECLs) to "fix" that
> > coverage counter issue (those are TREE_STATIC but they have their
> > address taken - still we know that no pointers alias the accesses),
> > we can as well rely on that flag - but then we should set it whenever
> > a TU-local decl does not have its address taken (!TREE_ADDRESSABLE).
>
> I see, I did not notice this. Will this help me with the situation where
> address is taken, but it is only passed to external calls that do not capture
> it (i.e. memset), so we know it does not appear in the points-to sets?
Yes. But I think it will be hard to keep this correct - if you consider
that sth could pull out the argument to a pointer. This is why I didn't
bother to try to do sth fancy with DECL_NONALIASED. But the
update-address-taken pass could in theory do sth about this (at least
for automatics).
> > So it does impose some redundancy and possibility of things to go
> > out-of-sync.
> >
> > Btw, the C frontend doesn't call varpool_finalize_decl for externals,
> > so setting TREE_ADDRESSABLE there doesn't work unfortunately. It
> > works with doing it in varpool_node_for_decl though.
> >
> > Patch doing both attached (we may choose to do this in different
> > places for DECL_EXTERNALs vs. TREE_PUBLIC && TREE_STATICs?).
> > At LTO input time we directly call symtab_register_node which would
> > side-step this thus an IPA pass could drop TREE_ADDRESSABLE from
> > those decls.
> >
> > Sofar untested.
> >
> > Comments?
>
> I think it may be easier to just set the flag as part of the ipa-visiblity
> pass. I.e. at the time we set externally_visile, we can also set
> TREE_ADDRESSABLE for variable. We don't use alias machinery before
> that, right?
That's the pass_ipa_function_and_variable_visibility pass run during
early small IPA passes right after lowering? No, currently there
are no uses of the alias machinery there - but having an incorrect
state in the IL for quite some time sounds dangerous to me.
I have now reverted the original patch while we discuss things here.
Richard.
2014-06-11 Richard Biener <rguent...@suse.de>
PR middle-end/61437
Revert
2014-06-04 Richard Biener <rguent...@suse.de>
* tree.h (may_be_aliased): Trust TREE_ADDRESSABLE from
TREE_PUBLIC and DECL_EXTERNAL decls.
* gcc.dg/torture/20140610-1.c: New testcase.
* gcc.dg/torture/20140610-2.c: Likewise.
Index: gcc/tree.h
===================================================================
--- gcc/tree.h (revision 211215)
+++ gcc/tree.h (working copy)
@@ -4506,9 +4506,7 @@ static inline bool
may_be_aliased (const_tree var)
{
return (TREE_CODE (var) != CONST_DECL
- && (TREE_PUBLIC (var)
- || DECL_EXTERNAL (var)
- || TREE_ADDRESSABLE (var))
+ && TREE_ADDRESSABLE (var)
&& !((TREE_STATIC (var) || TREE_PUBLIC (var) || DECL_EXTERNAL (var))
&& ((TREE_READONLY (var)
&& !TYPE_NEEDS_CONSTRUCTING (TREE_TYPE (var)))
