This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix PR66705
- From: Richard Biener <rguenther at suse dot de>
- To: Jan Hubicka <hubicka at ucw dot cz>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Wed, 2 Sep 2015 16:31:51 +0200 (CEST)
- Subject: Re: [PATCH] Fix PR66705
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot LSU dot 2 dot 11 dot 1509021456160 dot 5523 at zhemvz dot fhfr dot qr> <20150902130338 dot GA96189 at kam dot mff dot cuni dot cz> <alpine dot LSU dot 2 dot 11 dot 1509021526310 dot 5523 at zhemvz dot fhfr dot qr> <alpine dot LSU dot 2 dot 11 dot 1509021545020 dot 5523 at zhemvz dot fhfr dot qr> <20150902142302 dot GA44165 at kam dot mff dot cuni dot cz>
On Wed, 2 Sep 2015, Jan Hubicka wrote:
> > On Wed, 2 Sep 2015, Richard Biener wrote:
> >
> > > On Wed, 2 Sep 2015, Jan Hubicka wrote:
> > >
> > > > >
> > > > > I was naiively using ->get_constructor in IPA PTA without proper
> > > > > checking on wheter that succeeds. Now I tried to use ctor_for_folding
> > > > > but that isn't good as we want to analyze non-const globals in IPA
> > > > > PTA and we need to analyze their initialiers as well.
> > > > >
> > > > > Thus I'm trying below with ctor_for_analysis, but I really "just"
> > > > > need the initializer or a "not available" for conservative handling.
> > > > >
> > > > > Bootstrapped and tested on x86_64-unknown-linux-gnu.
> > > > >
> > > > > Honza - I suppose you should doble-check this and suggest sth
> > > > > different (or implement sth more generic in the IPA infrastructure).
> > > >
> > > > Yep, you are correct that we don't currently have way to look into ctor
> > > > without actually loading. But do you need something more than just walking
> > > > references that you already have in ipa-ref lists?
> > >
> > > Hmm, no, ipa-ref list should be enough (unless we start field-sensitive
> > > analysis or need NULL inits for correctness). Still have to figure out
> > > how to walk the list and how the reference would look like (what
> > > is ref->use? IPA_REF_ADDR? can those be speculative?)
> >
> > Sth like the following seems to work.
>
> Yep, it looks good to me. Do you conservatively handle constructors that
> are in other units? Those won't have ipa-ref lists streamed to ltrans
> stage. I suppose you do not care because all references in them can be
> supplied by foreign code, so you need to be conservative anyway.
I use all_refs_explicit_p () to go a conservative path. And indeed
I may trip aliases (well, the code doesn't handle aliases correctly
anyway I guess - I just walk vars via
/* Create constraints for global variables and their initializers. */
FOR_EACH_VARIABLE (var)
{
if (var->alias && var->analyzed)
continue;
get_vi_for_tree (var->decl);
}
and in get_vi_for_tree look at its ref list. So I should only get
"ultimate" alias targets and only those may have initializers?
Richard.