public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Erick Ochoa <erick.ochoa@theobroma-systems.com>
To: Richard Biener <richard.guenther@gmail.com>, gcc@gcc.gnu.org
Subject: Re: Struct declaration and initialization in TREES
Date: Thu, 19 Dec 2019 16:36:00 -0000	[thread overview]
Message-ID: <9952f5d6-a015-f5b2-5c1b-e7f279268d05@theobroma-systems.com> (raw)
In-Reply-To: <bd79d819-9430-9864-5d89-6fff6674d101@theobroma-systems.com>



On 2019-12-18 1:33 p.m., Erick Ochoa wrote:
> 
> 
> On 2019-12-18 6:02 a.m., Richard Biener wrote:
>> On December 17, 2019 8:31:00 PM GMT+01:00, Erick Ochoa <erick.ochoa@theobroma-systems.com> wrote:
>>> Hi,
>>>
>>> I'm interested in printing VAR_DECL trees that are of type
>>> RECORD_TYPE. I am using the function print_generic_decl
>>> for debugging and found this interesting behaviour.
>>>
>>> When I do initialization of structs using the following
>>> syntax:
>>>
>>> ```
>>> struct aStruct { _Bool e; int a; char b; float c; double d; _Bool f;
>>> long h;};
>>> struct aStruct astruct = { .e = 0, .a = 1, .b = 2, .c = 3.0, .d = 4.0,
>>> .f = 5, .h = 6 };
>>> ```
>>>
>>> print_generic_decl will print the following output:
>>>
>>> ```
>>> INTERESTED IN:   static struct aStruct astruct = <<< error >>>;
>>> ```
>>>
>>> Am I using the correct API? Is this a limitation of the API?
>>
>> You need to ask IPA about the static initializer, DECL_INITIAL is adjusted at some point. 
>>
>> Richard. 
> 
> Thanks Richard.
> 
> I still don't understand very well what I should do. I found the
> place in GCC internals where DECL_INITIAL is described.
> 
> https://gcc.gnu.org/onlinedocs/gccint/Working-with-declarations.html
> 
> VAR_DECL
> 
>   If this variable is initialized (but does not require a constructor),
>   the DECL_INITIAL will be an expression for the initializer.
>   The initializer should be evaluated, and a bitwise copy into the variable
>   performed. If the DECL_INITIAL is the error_mark_node, there is an initializer,
>   but it is given by an explicit statement later in the code; no bitwise copy is required.
> 
> So, now I understand that I can now change my patch to something like this:
> 
>>> +iphw_execute()
>>> +{
>>> +  if (!dump_file) return 0;
>>> +  varpool_node *node;
>>> +  FOR_EACH_VARIABLE(node)
>>> +  {
>>> +    gcc_assert(node->decl);
>>> +    tree decl = node->decl;
>>> +    gcc_assert(TREE_CODE(decl) == VAR_DECL);
>>> +
>>> +    tree curr_type = TREE_TYPE(decl);
>>> +    gcc_assert(curr_type);
>>> +
>>> +    const bool is_struct = TREE_CODE(curr_type) == RECORD_TYPE;
>>> +    if (is_struct) fprintf(dump_file, "INTERESTED IN: ");
>  
>         tree expr = DECL_INITIAL(decl);
>         if (expr == error_mark_node) {
>            fprintf(dump_file, "initializer is given by explicit statement later in code\n");
>            continue;
>         }
> 
>>> +    print_generic_decl(dump_file, decl, TDF_DETAILS);
>>> +    fprintf(dump_file, "\n");
>>> +  }
> 
> However I still don't know how to ask IPA about the static initializer.
> I tried iterating over the ipa_refs (i.e.  node->iterate_referring (i, ref))
> and then looking for writes, but there are now writes because it is a
> initialized statically.

I found some more documentation about static initializers
during LTO. In GCC internals it says:
https://gcc.gnu.org/onlinedocs/gccint/LTO-object-file-layout.html#LTO-object-file-layout

  Static variable initializers (.gnu.lto_.vars)

  This section contains all the symbols in the global variable pool. It is
  emitted by lto-cgraph.c:output_varpool and read in lto-cgraph.c:input_cgraph.

Does this mean that I should load an LTO_section and read the information?

However, I'm still a bit confused since I believe input_cgraph gets called
before my pass. My pass is running during WPA. Besides, I can inspect the
initializers for other variables just not those of structs.

Any help will be appreciated. Thanks again!

> 
>>
>>> Would people be interested in me extending this API to print
>>> out something more useful? I already have some code that
>>> iterates over fields and prints out names and types. It
>>> can still use some work though.
>>>
>>> However, I understand if this is the intended behaviour.
>>> Another question (related to the possibility of intended behaviour)
>>> is: how is struct initialization represented in trees?
>>> (I.e. will each field be initialized separately or something else
>>> happens?)
>>>
>>> Thanks! I also include the patch in case people want a simple
>>> working example on how to print declarations.
>>>
>>> diff --git a/gcc/Makefile.in b/gcc/Makefile.in
>>> index 6b857bd..f4f1376 100644
>>> --- a/gcc/Makefile.in
>>> +++ b/gcc/Makefile.in
>>> @@ -1368,6 +1368,7 @@ OBJS = \
>>> 	incpath.o \
>>> 	init-regs.o \
>>> 	internal-fn.o \
>>> +	ipa-hello-world.o \
>>> 	ipa-cp.o \
>>> 	ipa-sra.o \
>>> 	ipa-devirt.o \
>>> diff --git a/gcc/common.opt b/gcc/common.opt
>>> index b4dc31c..304ec9f 100644
>>> --- a/gcc/common.opt
>>> +++ b/gcc/common.opt
>>> @@ -3348,4 +3348,7 @@ fipa-ra
>>> Common Report Var(flag_ipa_ra) Optimization
>>> Use caller save register across calls if possible.
>>>
>>> +fipa-typelist
>>> +Common Report Var(flag_ipa_typelist) TBD
>>> +
>>> ; This comment is to ensure we retain the blank line above.
>>> diff --git a/gcc/ipa-hello-world.c b/gcc/ipa-hello-world.c
>>> new file mode 100644
>>> index 0000000..ed4ae11
>>> --- /dev/null
>>> +++ b/gcc/ipa-hello-world.c
>>> @@ -0,0 +1,78 @@
>>> +#include "config.h"
>>> +#include "system.h"
>>> +#include "coretypes.h"
>>> +#include "backend.h"
>>> +#include "tree.h"
>>> +#include "gimple-expr.h"
>>> +#include "predict.h"
>>> +#include "alloc-pool.h"
>>> +#include "tree-pass.h"
>>> +#include "cgraph.h"
>>> +#include "diagnostic.h"
>>> +#include "fold-const.h"
>>> +#include "gimple-fold.h"
>>> +#include "symbol-summary.h"
>>> +#include "tree-vrp.h"
>>> +#include "ipa-prop.h"
>>> +#include "tree-pretty-print.h"
>>> +#include "tree-inline.h"
>>> +#include "ipa-fnsummary.h"
>>> +#include "ipa-utils.h"
>>> +#include "tree-ssa-ccp.h"
>>> +#include "stringpool.h"
>>> +#include "attribs.h"
>>> +
>>> +
>>> +static unsigned int
>>> +iphw_execute()
>>> +{
>>> +  if (!dump_file) return 0;
>>> +  varpool_node *node;
>>> +  FOR_EACH_VARIABLE(node)
>>> +  {
>>> +    gcc_assert(node->decl);
>>> +    tree decl = node->decl;
>>> +    gcc_assert(TREE_CODE(decl) == VAR_DECL);
>>> +
>>> +    tree curr_type = TREE_TYPE(decl);
>>> +    gcc_assert(curr_type);
>>> +
>>> +    const bool is_struct = TREE_CODE(curr_type) == RECORD_TYPE;
>>> +    if (is_struct) fprintf(dump_file, "INTERESTED IN: ");
>>> +    print_generic_decl(dump_file, decl, TDF_DETAILS);
>>> +    fprintf(dump_file, "\n");
>>> +  }
>>> +  return 0;
>>> +}
>>> +
>>> +namespace {
>>> +const pass_data pass_data_ipa_hello_world =
>>> +{
>>> +  SIMPLE_IPA_PASS,
>>> +  "hello_world",
>>> +  OPTGROUP_NONE,
>>> +  TV_NONE,
>>> +  (PROP_cfg | PROP_ssa),
>>> +  0,
>>> +  0,
>>> +  0,
>>> +  0,
>>> +};
>>> +
>>> +class pass_ipa_hello_world : public simple_ipa_opt_pass
>>> +{
>>> +public:
>>> +  pass_ipa_hello_world (gcc::context *ctx)
>>> +    : simple_ipa_opt_pass(pass_data_ipa_hello_world, ctx)
>>> +  {}
>>> +
>>> +  virtual bool gate(function*) { return flag_ipa_typelist; }
>>> +  virtual unsigned execute (function*) { return iphw_execute(); }
>>> +};
>>> +} // anon namespace
>>> +
>>> +simple_ipa_opt_pass*
>>> +make_pass_ipa_hello_world (gcc::context *ctx)
>>> +{
>>> +  return new pass_ipa_hello_world (ctx);
>>> +}
>>> diff --git a/gcc/passes.def b/gcc/passes.def
>>> index 798a391..52cd14b 100644
>>> --- a/gcc/passes.def
>>> +++ b/gcc/passes.def
>>> @@ -146,6 +146,7 @@ along with GCC; see the file COPYING3.  If not see
>>>   NEXT_PASS (pass_ipa_profile);
>>>   NEXT_PASS (pass_ipa_icf);
>>>   NEXT_PASS (pass_ipa_devirt);
>>> +  NEXT_PASS (pass_ipa_hello_world);
>>>   NEXT_PASS (pass_ipa_cp);
>>>   NEXT_PASS (pass_ipa_sra);
>>>   NEXT_PASS (pass_ipa_cdtor_merge);
>>> diff --git a/gcc/tree-pass.h b/gcc/tree-pass.h
>>> index a987661..915fc69 100644
>>> --- a/gcc/tree-pass.h
>>> +++ b/gcc/tree-pass.h
>>> @@ -498,6 +498,7 @@ extern ipa_opt_pass_d *make_pass_ipa_fn_summary
>>> (gcc::context *ctxt);
>>> extern ipa_opt_pass_d *make_pass_ipa_inline (gcc::context *ctxt);
>>> extern simple_ipa_opt_pass *make_pass_ipa_free_lang_data (gcc::context
>>> *ctxt);
>>> extern simple_ipa_opt_pass *make_pass_ipa_free_fn_summary (gcc::context
>>> *ctxt);
>>> +extern simple_ipa_opt_pass *make_pass_ipa_hello_world (gcc::context
>>> *ctxt);
>>> extern ipa_opt_pass_d *make_pass_ipa_cp (gcc::context *ctxt);
>>> extern ipa_opt_pass_d *make_pass_ipa_sra (gcc::context *ctxt);
>>> extern ipa_opt_pass_d *make_pass_ipa_icf (gcc::context *ctxt);
>>

      reply	other threads:[~2019-12-19 16:36 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-17 19:31 Erick Ochoa
2019-12-18 11:02 ` Richard Biener
2019-12-18 18:33   ` Erick Ochoa
2019-12-19 16:36     ` Erick Ochoa [this message]

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=9952f5d6-a015-f5b2-5c1b-e7f279268d05@theobroma-systems.com \
    --to=erick.ochoa@theobroma-systems.com \
    --cc=gcc@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).