On Mon, 23 Jun 2014, Jan Hubicka wrote:
> > > On Fri, 13 Jun 2014, Jan Hubicka wrote:
> > >
> > > > >
> > > > > When you extract the address and use it. For example when you
> > > > > do auto-parallelization and outline a part of your function it
> > > > > passes arrays as addresses.
> > > > >
> > > > > Or if you start to introduce address induction variables like
> > > > > the vectorizer or IVOPTs does.
> > > >
> > > > I see, nothing really done by current early/IPA optimizers and in those
> > > > cases
> > > > we also want to set TREE_ADDRESSABLE bit, too I suppose.
> > > > Do you think I should make patch for setting the NOVOPS bits in ipa
> > > > code?
> > >
> > > No, please don't introduce new users of NOVOPS (it's a quite broken
> > > hack - it's sth like a 'const' function with side-effects so we should
> > > have instead used 'const' and some kind of volatile flag). We're
> > > not using NOVOPS much and that's good (I think handling of such
> > > function calls are somewhat broken).
> >
> > I meant DECL_NONALIASED. I will test the patch and lets see.
>
> Hi,
> this patch adds the discussed code to set DECL_NOALIASED so we get better AA
> with partitioning. We probably also can sed DECL_NOALIASED for variables
> whose address is passed only to external calls that do not capture the
> parameters (i.e. memset).
>
> I suppose I can teach ipa-ref code about this, but will need a bit of
> extra infrastructure for that, since currently REF_ADDR does not associate
> any information about these.
>
> Martin, this is related to your controlled uses. What do you think about
> adding
> stable UIDs into ipa_ref datastructure and then adding a vector into cgraph
> edges
> that describe what REFs are directly used as parameters of a given callsite?
> It will take some work to maintain these, but we will be able to remove them
> when
> call site or parameter was eliminated in a more general way.
>
> I suppose we could also use these to associate REFs with given use in the
> satement or constructor (i.e. have pointer to statement as well as pointer to
> specific use within the statement). With this we will be able to redirect
> references same way as we redirect callgraph edges now. This is something I
> need to for the ipa-visibility optimizations.
I don't like this very much. It's fragile and it will be very hard to
detect bugs caused by it.
Please don't spread uses of the DECL_NONALIASED "hack".
If we are only concerned about LTO I'd rather have a in_lto_p check
in may_be_aliased and trust TREE_ADDRESSABLE there.
Richard.
> Honza
>
> Bootstrapped/regtested and lto-bootstrapped x86_64-linux, will commit it
> shortly.
>
> * ipa.c (clear_addressable_bit): Set also DECL_NONALIASED.
> (ipa_discover_readonly_nonaddressable_var): Compute also NONALIASED.
> Index: ipa.c
> ===================================================================
> --- ipa.c (revision 211881)
> +++ ipa.c (working copy)
> @@ -669,6 +669,10 @@ clear_addressable_bit (varpool_node *vno
> {
> vnode->address_taken = false;
> TREE_ADDRESSABLE (vnode->decl) = 0;
> + /* Set also non-aliased bit. In LTO, when program is partitioned, we no
> longer
> + trust TREE_ADDRESSABLE for TREE_PUBLIC variables and then
> DECL_NONALIASED is
> + useful to improve code. */
> + DECL_NONALIASED (vnode->decl) = 1;
> return false;
> }
>
> @@ -690,6 +694,7 @@ ipa_discover_readonly_nonaddressable_var
> FOR_EACH_VARIABLE (vnode)
> if (!vnode->alias
> && (TREE_ADDRESSABLE (vnode->decl)
> + || !DECL_NONALIASED (vnode->decl)
> || !vnode->writeonly
> || !TREE_READONLY (vnode->decl)))
> {
> @@ -703,8 +708,8 @@ ipa_discover_readonly_nonaddressable_var
> continue;
> if (!address_taken)
> {
> - if (TREE_ADDRESSABLE (vnode->decl) && dump_file)
> - fprintf (dump_file, " %s (non-addressable)", vnode->name ());
> + if ((TREE_ADDRESSABLE (vnode->decl) || !DECL_NONALIASED
> (vnode->decl)) && dump_file)
> + fprintf (dump_file, " %s (non-addressable non-aliased)",
> vnode->name ());
> varpool_for_node_and_aliases (vnode, clear_addressable_bit, NULL,
> true);
> }
> if (!address_taken && !written
>
>
--
Richard Biener <rguent...@suse.de>
SUSE / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746
GF: Jeff Hawn, Jennifer Guild, Felix Imend"orffer
