public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jan Hubicka <hubicka@ucw.cz>
To: Richard Biener <richard.guenther@gmail.com>
Cc: Jan Hubicka <hubicka@ucw.cz>, GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH 7/7] Plug ipa-prop escape analysis into gimple_call_arg_flags
Date: Fri, 23 May 2014 22:29:00 -0000	[thread overview]
Message-ID: <20140523222911.GE30708@kam.mff.cuni.cz> (raw)
In-Reply-To: <CAFiYyc0Oq8DgXZBxiBQR=xJu=Fg8y56u3GS0oMBfTfQ2Uy1LyA@mail.gmail.com>

> Well, allocate_struct_function has a abstract_p argument for that.  But
> yes, a simple patch like
> 
> Index: gcc/function.c
> ===================================================================
> --- gcc/function.c      (revision 210845)
> +++ gcc/function.c      (working copy)
> @@ -64,6 +64,7 @@ along with GCC; see the file COPYING3.
>  #include "params.h"
>  #include "bb-reorder.h"
>  #include "shrink-wrap.h"
> +#include "cgraph.h"
> 
>  /* So we can assign to cfun in this file.  */
>  #undef cfun
> @@ -4512,6 +4513,8 @@ allocate_struct_function (tree fndecl, b
> 
>    if (fndecl != NULL_TREE)
>      {
> +      if (!abstract_p)
> +       cgraph_get_create_node (fndecl);
>        DECL_STRUCT_FUNCTION (fndecl) = cfun;
>        cfun->decl = fndecl;
>        current_function_funcdef_no = get_next_funcdef_no ();
> 
> ICEs during bootstrap with (at least)
> 
> /space/rguenther/src/svn/trunk/libgcc/config/i386/cpuinfo.c:405:1:
> error: node differs from symtab decl hashtable
>  }
>  ^
> __get_cpuid_max.constprop.0/42 (__get_cpuid_max.constprop) @0x7ff486232290
>   Type: function definition analyzed
>   Visibility: artificial
>   previous sharing asm name: 43
>   References:
>   Referring:
>   Function __get_cpuid_max.constprop/42 is inline copy in __get_cpuid_output/40
>   Availability: local
>   First run: 0
>   Function flags: local only_called_at_startup
>   Called by: __get_cpuid_output/40 (1.00 per call) (inlined)
>   Calls:
> /space/rguenther/src/svn/trunk/libgcc/config/i386/cpuinfo.c:405:1:
> internal compiler error: verify_cgraph_node failed
> 
> so I guess we would need to have a way to create a "dummy" cgraph
> node first and later populate it properly.

Yep, I was wondering about following:

struct GTY(()) tree_decl_with_vis {
 struct tree_decl_with_rtl common;
 tree assembler_name;
 tree section_name;
 tree comdat_group;

for majority of decl_with_vis we create we won't have section name/assembler
name and comdat group.

We already do memory optimization for INIT_PRIORITY in the following way:
#define DECL_HAS_INIT_PRIORITY_P(NODE) \
  (VAR_DECL_CHECK (NODE)->decl_with_vis.init_priority_p)
#define DECL_INIT_PRIORITY(NODE) \
  (decl_init_priority_lookup (NODE))

where init priority sits on separate hashtab.

I think at the moment we can't move assembler_name/section_name/comat_group
all to symbol table, because we do need the for off-symbol table things
(CONST_DECL, LABEL_DECL, off symtab VAR_DECL).
But I would suggest dropping them to off-tree hashtables, too, and have
pointer in symtab.
The accessor would be then something like

tree get_comdat_group (tree node)
{
  if (!node->decl_with_vis.comdat_group_p)
    return NULL;
  if (node->decl_with_vis.symtab_node)
    return node->decl_with_vis.symtab_node->comdat_group;
  decl_comdat_group_loop (node);
}
> 
> But as we currently have a back-pointer from struct function to fndecl
> it would be nice to hook the cgraph node in there - that way we get
> away without any extra pointer (we could even save symtab decl
> pointer and create a cyclic fndecl -> cgraph -> function -> fndecl
> chain ...).
> 
> I'm fine with enlarging tree_function_decl for now - ideally we'd push
> stuff from it elsewhere (like target and optimization option tree nodes,
> or most of the visibility and symbol related stuff).  Not sure why
> tree_type_decl inherits from tree_decl_non_common (and thus
> tree_decl_with_vis).  Probably because of the non-common parts
> being (ab-)used by FEs.  Otherwise I'd say simply put a symtab
> node pointer into tree_decl_with_vis ... (can we move
> section_name and comdat_group more easily than assembler_name?)

Lets see, I suppose putting it on side first is good incremental step.
Then we need to revisit frontends to avoid defining those too early,
that might be relatively simple to do (at least for C++ FE, I think it all
is defined at a time we call import/export decl.)

Honza
> 
> Richard.
> 
> > Honza
> >>
> >> Richard.
> >>
> >> >I think we may be on better track moving DECL_ASSEMBLER_NAME that is
> >> >calculated later,
> >> >but then we have problem with DECL_ASSEMBLER_NAME being set for
> >> >assembler names and
> >> >const decls, too that still go around symtab.
> >> >Given that decl_assembler_name is a function, I suppose we could go
> >> >with extra conditoinal
> >> >in there.
> >> >
> >> >Getting struct function out of frontend busyness would be nice indeed,
> >> >too, but probably
> >> >should be independent of Martin's work here.
> >> >
> >> >Honza
> >> >>
> >> >> Thanks,
> >> >> Richard.
> >> >>
> >> >> > Thanks,
> >> >> >
> >> >> > Martin
> >> >> >
> >> >> >>
> >> >> >> > +       }
> >> >> >> >      }
> >> >> >> > +
> >> >> >> > +  return ret;
> >> >> >> >  }
> >> >> >> >
> >> >> >> >  /* Detects return flags for the call STMT.  */
> >> >> >> >
> >>

  reply	other threads:[~2014-05-23 22:29 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-21 13:31 [PATCH 0/7] ipa-prop escape analysis Martin Jambor
2014-05-21 13:31 ` [PATCH 4/7] Break up determine_known_aggregate_parts Martin Jambor
2014-05-26  0:54   ` Jan Hubicka
2014-06-06 13:28     ` Martin Jambor
2014-05-21 13:31 ` [PATCH 5/7] Advanced aggregate jump function construction Martin Jambor
2014-05-21 13:31 ` [PATCH 1/7] Add missing documentation of four IPA-CP params Martin Jambor
2014-05-21 15:58   ` Jeff Law
2014-06-10 12:13   ` Gerald Pfeifer
2014-06-29 23:07     ` Gerald Pfeifer
2014-07-15 12:01       ` Martin Jambor
2014-05-21 13:31 ` [PATCH 7/7] Plug ipa-prop escape analysis into gimple_call_arg_flags Martin Jambor
2014-05-21 14:27   ` Richard Biener
2014-05-22 12:49     ` Martin Jambor
2014-05-22 13:34       ` Richard Biener
2014-05-22 15:24         ` Jan Hubicka
2014-05-22 15:36           ` Richard Biener
2014-05-22 18:11             ` Jan Hubicka
2014-05-23 10:03               ` Richard Biener
2014-05-23 22:29                 ` Jan Hubicka [this message]
2014-05-24  7:39                 ` Jan Hubicka
2014-05-26 13:03                   ` Rainer Orth
2014-05-27 17:51                     ` Jan Hubicka
2014-05-27 18:16                       ` Rainer Orth
2014-05-26  1:01         ` Jan Hubicka
2014-05-21 13:31 ` [PATCH 6/7] Real aggregate contents merge and application of deltas Martin Jambor
2014-05-21 13:31 ` [PATCH 3/7] IPA-CP escape and clobber analysis Martin Jambor
2014-05-21 14:51   ` Richard Biener
2014-05-23 14:50     ` Martin Jambor
2014-05-21 13:31 ` [PATCH 2/7] Analyze BBs in DOM order in ipa-prop.c Martin Jambor
2014-05-26  9:00 [PATCH 7/7] Plug ipa-prop escape analysis into gimple_call_arg_flags Dominique Dhumieres
2014-05-26  9:16 ` Andrew Pinski
2014-05-26  9:29   ` Christophe Lyon
2014-05-26 16:32     ` Jan Hubicka
2014-05-28  7:26   ` Thomas Schwinge
2014-05-28 21:55     ` Jan Hubicka
2014-06-03  9:56       ` Thomas Schwinge

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140523222911.GE30708@kam.mff.cuni.cz \
    --to=hubicka@ucw.cz \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=richard.guenther@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).