Re: [patch] Fix PR tree-optimization/47056

[Jan Hubicka <hubicka at ucw dot cz>]

> 2011/1/4 Jan Hubicka <hubicka@ucw.cz>:
> >> On Tue, Jan 4, 2011 at 1:03 PM, Eric Botcazou <ebotcazou@adacore.com> wrote:
> >> > Hi,
> >> >
> >> > this is the link failure of 10 ACATS tests on IA64/Linux. ?The problem is that
> >> > reachability analysis fails to see that some functions are needed because
> >> > they are referenced in the code. ?More precisely, CCP turns:
> >> >
> >> > ?pr47056___alignment.46_308 = pr47056___alignment;
> >> > ?D.2264_309 = MEM[(struct ?*)pr47056___alignment.46_308].D.227;
> >> >
> >> > into
> >> >
> >> > ?D.2264_309 = MEM[(struct ?*)pr47056___alignment].D.227;
> >> >
> >> > (pr47056___alignment being a function) and while walk_stmt_load_store_addr_ops
> >> > recognizes the former as an address-of pattern (the & is implicit for
> >> > functions), it doesn't for the latter (unlike for TARGET_MEM_REF) so
> >>
> >> Yeah, the TARGET_MEM_REF thing looks from before the MEM_REF
> >> merge. ?It shouldn't recognize it as an address either.
> >>
> >> > build_cgraph_edges is fooled and missed the reference to pr47056___alignment.
> >> >
> >> > The attached patch adds a specific kludge to mark_load for this case. ?It also
> >> > removes bogus ATTRIBUTE_UNUSED markers and makes mark_store pass the STMT to
> >> > ipa_record_reference like the 2 other functions (mark_load and mark_address).
> >> >
> >> > It passed regression testing on x86. ?OK after a complete testing cycle?
> >>
> >> I don't know if manipulating the descriptor would count effectively as
> >> an address-taking of the function. ?Maybe Honza can comment. ?Otherwise
> >> the patch is ok.
> >
> > Hi,
> > I am having problems to parse the gimple. pr47056___alignment is function
> > and MEM[(struct | *)pr47056___alignment].D.227 is read from the ?function's text
> > (i.e. something quite underfined?).
> > If it is so, then indeed this should count as address taken in cgraph sense.
> 
> We print &function-decl as just function-decl to confuse us ;)  (because
> of calls I guess)

OK.
There is bit of quirk that cgraph is not really considering posibility of direct
read or write to/from function, only to/from var.  I guess modeling all of these
as dereferences is safe for reachability analysis and we don't need to care
about efectivity since the code is undefined anyway.
(we lose some code quality by considering such function as having address taken,
but I don't think we care.  Adding read/write edges for functions is possible
but would just confuse prople IMO)

Honza
> 
> Richard.
> 
> >
> > Honza
> >