Thanks David,
I'll give it a try. By the way, I'm trying to force one partition
with "-flto-partition=one" I'm not sure if that makes a difference.
Gary
________________________________
From: David Malcolm <dmalc...@redhat.com>
Sent: Friday, January 3, 2020 3:52 PM
To: Gary Oblock <gobl...@marvell.com>; gcc@gcc.gnu.org <gcc@gcc.gnu.org>
Subject: [EXT] Re: Mechanism to get at function information seems not to work
External Email
----------------------------------------------------------------------
On Fri, 2020-01-03 at 23:02 +0000, Gary Oblock wrote:
> I'm having some grief attempting to get at the local definitions
> in LTO (more about the options used later.)
>
> Here's the sequence of code in my optimization (part of attempt
> at structure reorganization optimizations.)
>
> cgraph_node* node;
> FOR_EACH_FUNCTION_WITH_GIMPLE_BODY ( node)
> {
> tree decl;
> unsigned i;
> struct function *fn = DECL_STRUCT_FUNCTION ( node->decl);
>
> // I'm assuming it's obvious what my debugging macros do...
> DEBUG( "fn %p\n", fn);
> DEBUG_F( print_generic_decl, stderr, node->decl, (dump_flags_t)-
> 1);
> DEBUG( "\n");
> // I don't know why this is coming up null.... but I'll
> // skip it for now because causes a crash.
> if( fn == NULL )
> {
> continue;
> }
>
> FOR_EACH_LOCAL_DECL ( fn, i, decl)
> {
> :
>
> What it returns is:
>
> fn 0xffffb0fc9210
> static intD.xxxx max1.constprop.0D.xxxx (struct type_t *);
> fn 0xffffb0fc9370
> static doubleD.xxxx max2.constprop.0D.xxxx (struct type_t *);
> fn (nil)
> static intD.xxxx mainD.xxxx (void);
> fn (nil)
> static struct type_t * setupD.xxxx (size_t);
>
[...snip...]
> Here is how I compile them:
>
> GCC=/home/goblock/str-reorg-gcc-build-dir/install/bin/gcc
> OPTIONS="-O2 -flto -flto-partition=one -fipa-structure-reorg"
>
> $GCC $OPTIONS -c main.c
> $GCC $OPTIONS -c aux.c
> $GCC $OPTIONS -o exe main.o aux.o
>
> ./exe
>
> I'm wondering if this is a fundamental issue, if there's a bug
> or perhaps I'm doing something dumb. I any advice is appreciated
> here because my only real alternative here is insanely ugly.
This looks like the same issue as one I ran into when trying to add LTO
support to the static analyzer [1].
AIUI the LTO infrastructure partitions the functions in a kind of
sharding operation. There's no guarantee for any given partition's
invocation of lto1 that it has a particular function body.
I fixed this in the analyzer by putting this loop at the top of the
pass:
/* If using LTO, ensure that the cgraph nodes have function bodies. */
cgraph_node *node;
FOR_EACH_FUNCTION_WITH_GIMPLE_BODY (node)
node->get_untransformed_body ();
which seems to fix it for me (my pass then goes on to do a non-trivial
interprocedural traversal, so it needs to have all the function bodies
present first).
I'm not sure if this is the correct fix for your issue, but it worked
for my pass (I'm just using "-flto", FWIW).
Hope this is helpful
Dave
[1]
https://urldefense.proofpoint.com/v2/url?u=https-3A__gcc.gnu.org_wiki_DavidMalcolm_StaticAnalyzer&d=DwICaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=HVs3hYm_BnTtuG8V-km21WLujN2g6AKxQlP-LTQPUQI&m=PLNbIn26nObhyevJgxSrCwF8SwZVo7ILB5s5Uu2DmRk&s=quDOZbDeR-DxertzdPRUzHiBYIXOpQ6cRmjMsvC9EbE&e=
