Re: [gimplefe] Merge from trunk rev 173770
On Fri, May 6, 2011 at 2:16 AM, Diego Novillo wrote: > This merge brings the gimple-front-end branch up to 4.7. It needed > some minimal adjustments, but things seem to be working. Sandeep, > please make sure it does. You may need to rebase your patch before > committing it. > I got the build working on my machine. So preliminarily things seem to be working. In case this merge brings our branch up to 4.7 should "gcc -v" be showing it? It is not currently. > We need some tests in testsuite/gimple. Sandeep, do you think you > could add some? If you need a hand with dejagnu, let me know. We > still cannot generate code, but we should start adding some minimal > parsing tests. > Sure. I will see how dejagnu works since I have no prior experience using it. I will try adding some testcases to the testsuite. -- Cheers Sandy
[gimplefe] Ran into a internal compiler error
Hi,
I was trying to make a symbol table for all the variable declarations
for the gimple front end. Following is a patch:
Index: parser.c
===
--- parser.c(revision 174754)
+++ parser.c(working copy)
@@ -28,6 +28,7 @@
#include "tree.h"
#include "gimple.h"
#include "parser.h"
+#include "hashtab.h"
#include "ggc.h"
/* The GIMPLE parser. Note: do not use this variable directly. It is
@@ -807,6 +808,31 @@
}
}
+
+struct gimple_symtab_entry_def
+{
+ tree decl;
+};
+
+static hashval_t
+gimple_symtab_entry_hash (const void *entry)
+{
+ const struct gimple_symtab_entry_def *base =
+(const struct gimple_symtab_entry_def *)entry;
+ return IDENTIFIER_HASH_VALUE (base->decl);
+}
+
+static int
+gimple_symtab_eq_hash (const void *entry1, const void *entry2)
+{
+ const struct gimple_symtab_entry_def *p1 =
+(const struct gimple_symtab_entry_def *)entry1;
+ const struct gimple_symtab_entry_def *p2 =
+(const struct gimple_symtab_entry_def *)entry2;
+
+ return (p1->decl == p2->decl);
+}
+
/* The Declaration section within a .gimple file can consist of
a) Declaration of variables.
b) Declaration of functions.
@@ -871,10 +897,29 @@
gp_parse_var_decl (gimple_parser *parser)
{
const gimple_token *next_token;
+ const gimple_token *name_token;
+ const char* name;
enum tree_code code ;
+ htab_t gimple_symtab;
+ void **slot1, **slot2;
+ struct gimple_symtab_entry_def e;
+
+ gimple_symtab = htab_create_ggc (10, gimple_symtab_entry_hash,
gimple_symtab_eq_hash, NULL);
gl_consume_expected_token (parser->lexer, CPP_LESS);
- gl_consume_expected_token (parser->lexer, CPP_NAME);
+ name_token = gl_consume_expected_token (parser->lexer, CPP_NAME);
+ name = gl_token_as_text(name_token);
+ e.decl = build_decl (UNKNOWN_LOCATION, VAR_DECL,
get_identifier(name), void_type_node);
+ slot1 = htab_find_slot (gimple_symtab ,&e, INSERT);
+ slot2 = htab_find_slot (gimple_symtab, &e, NO_INSERT);
+ if (slot1 == slot2)
+{
+ printf ("I think this is right\n");
+}
+ else
+{
+ printf ("Or this is wrong\n");
+}
gl_consume_expected_token (parser->lexer, CPP_COMMA);
next_token = gl_consume_token (parser->lexer);
@@ -1391,7 +1436,6 @@
parser_gc_root__ = NULL;
}
-
/* Main entry point for the GIMPLE front end. */
void
@@ -1402,7 +1446,6 @@
parser_gc_root__ = parser = gp_init (main_input_filename);
if (parser->lexer->filename == NULL)
return;
-
gl_lex (parser->lexer);
gp_parse (parser);
gp_finish (parser);
It gives me a internal compiler error saying:
gimple1: internal compiler error: tree check: expected
identifier_node, have var_decl in gimple_symtab_entry_hash
Is there something that I have gotten wrong or something that I had to
do before that I missed?
--
Cheers
Sandy
Re: [gimplefe] Ran into a internal compiler error
On Tue, Sep 20, 2011 at 10:48 PM, Diego Novillo wrote: > On 11-09-19 23:32 , Sandeep Soni wrote: > >> It gives me a internal compiler error saying: >> gimple1: internal compiler error: tree check: expected >> identifier_node, have var_decl in gimple_symtab_entry_hash > > As Balaji said, the problem is that you need to pass DECL_NAME(base->decl) > to IDENTIFIER_HASH_VALUE(). > > When you build a decl node, its DECL_NAME is the IDENTIFIER_NODE that you > created with get_identifier(). > It worked. Thanks Balaji and Diego. -- Cheers Sandy
loop optimization in gcc
Hi All, I have been studying the gcc code lately as part of my project.I have got info from this mailing list about CFG and DFG information.I want to know how gcc uses this information to perform loop optimization? Does it Follow any particular algorithm or in particular what are the different techniques that it uses to parallelize the code by performing the loop optimizations?(correct me please if this sentence is not right). If possible please provide any pointers to any form of literature available regarding it. Thanks in advance. -- cheers sandy
Re: loop optimization in gcc
On Mon, Oct 12, 2009 at 12:13 PM, Ian Lance Taylor wrote: > I'm not really sure what you are asking. gcc supports OpenMP for > parallelizing loops. That is mostly done in the frontends. I have been told that openMP does parallelizing of loops, but these types of optimizations are generally done for a large clusters of computers (Is this correct?).Meaning thereby that these optimizations are not used for low scale systems. What i aim for in parallelizing, is to improve the speed of execution of relatively simple tools used for distribution of packages.(for eg: speed improvements in using dwarf utilities and elf utilities during distribution of software to test for backward compatibilities and dependency checks) for modestly multicore (2 or 4 to start out) processors.A few ideas in this regard are brewing in which i will be trying out along with my team in the near future. I will also be happy to know if there are any good ideas to improve the speed of execution by optimizing the loops with a focus to parallelize them than the one which are in place in gcc so that i can try this out with my team. -- cheers sandy
Re: loop optimization in gcc
On Mon, Oct 12, 2009 at 11:28 PM, Ian Lance Taylor wrote: > sandeep soni writes: > >> On Mon, Oct 12, 2009 at 12:13 PM, Ian Lance Taylor wrote: >> >>> I'm not really sure what you are asking. gcc supports OpenMP for >>> parallelizing loops. That is mostly done in the frontends. >> >> I have been told that openMP does parallelizing of loops, but these >> types of optimizations are generally done for a large clusters of >> computers (Is this correct?).Meaning thereby that these optimizations >> are not used for low scale systems. > > That is not correct. OpenMP parallelizes loops within a single > system, using pthreads. It does not parallelize loops across > different systems. > > Ian > Well i was under a misconception then.Thanks for clearing this. -- cheers sandy
Re: loop optimization in gcc
> Hi, > > you also might want to take a look at the Graphite project. > http://gcc.gnu.org/wiki/Graphite where we do loop optimizations and > automatic parallelization based on the polytop model. If you need any > help feel free to ask. > > Tobias > > Hi, This seems to be quite interesting and challenging.Moreover,it is very close to what we are trying to achieve as well (on a small scale that is).I have started preliminary reading on the polytope model and the working of GRAPHITE. I will ask you if i face any doubts.It would be nice to contribute to this project. For the starters, can you tell me if GRAPHITE also does source to source transformations or otherwise to optimize??Coz i had read somewhere else that the polyhedral model used source to source transformations. -- cheers sandy
Re: loop optimization in gcc
On Wed, Oct 14, 2009 at 9:02 PM, Tobias Grosser wrote: > On Wed, 2009-10-14 at 20:12 +0530, sandeep soni wrote: >> > Hi, >> > >> > you also might want to take a look at the Graphite project. >> > http://gcc.gnu.org/wiki/Graphite where we do loop optimizations and >> > automatic parallelization based on the polytop model. If you need any >> > help feel free to ask. >> > >> > Tobias >> > >> > >> >> Hi, >> >> This seems to be quite interesting and challenging.Moreover,it is very >> close to what we are trying to achieve as well (on a small scale that >> is).I have started preliminary reading on the polytope model and the >> working of GRAPHITE. I will ask you if i face any doubts.It would be >> nice to contribute to this project. >> >> >> For the starters, can you tell me if GRAPHITE also does source to >> source transformations or otherwise to optimize??Coz i had read >> somewhere else that the polyhedral model used source to source >> transformations. > > Hi, > > you are right. There are several polytope frameworks that work on the > source code level (LooPo, Cloog/Clan from Cedric Bastoul), however > Graphite works on the intermediate level tree-ssa in gcc. Therefore we > can not do any source to source transformations. > The idea is to not be limited to specific input languages or special > formatting of the code, but to be able to use the powerful analysis in > the gcc middle end. > This allows us to work on any input language and to detect loops that do > not even look like a loop in the input program (goto-loops). Using the > powerful scalar evolution framework in gcc Graphite also handles loops > that do not look like affine linear loops. > This is a powerful approach in its earlier stages. Basic loops and > simple code transformations already work, but there is still a lot left > to be done. > > Tobi > > Hi, Sounds absolutely convincing to me. I am too keen to contribute in this in any way possible.I will first try to understand how it works totally .Would you mind me pressing on with some of issues in the near future? I am afraid though that they might be a bit more theoretical to begin with. -- cheers sandy
entry point of gimplification
Hi, I have been trying to understand the gcc source code and am interested in customizing gcc to support speculative parallelization of conditional branching and loop instructions instructions.I am considering gimple as input. I want to know what is the entry point to the gimplification pass? and given a function body which are the functions in the gcc source that convert the body into equivalent gimple statements? Also is there a way in which i can selectively step through the execution of the source related to this? Any other help on the main aim of speculative parallelization will also be most helpful. Apologies if the question sounds vague. -- cheers sandy
Re: entry point of gimplification
On Tue, Jan 5, 2010 at 8:44 PM, Diego Novillo wrote: > On 1/4/10 14:57 , sandeep soni wrote: > >> I want to know what is the entry point to the gimplification pass? and >> given a function body which are the functions in the gcc source that >> convert the body into equivalent gimple statements? > > This is controlled from the callgraph manager. You need to start > looking at cgraphunit.c:cgraph_analyze_functions. It traverses the > cgraph queue converting each node into gimple (the call to > cgraph_analyze_function). > >> Also is there a way in which i can selectively step through the >> execution of the source related to this? > > Yes. You need to debug cc1/cc1plus and set a breakpoint in > cgraph_analyze_functions. The function debug_cgraph() will show you the > callgraph at that point. > > > Diego. > Hi, I recently read in the internal documentation of gcc that the main entry point to the gimplification pass is the function defined in gimplify.c: gimplify_function_tree function.Is there something which I m missing? plus can someone point to me to of any way in which I can achieve my aim of speculatively parallelizing the code at runtime? chiefly I wanna know if gcc supports it ? (If not) would it be possible to do? -- cheers sandy
How to make make changes in gcc code
Hi, I posted this question on the mailing list gcc-h...@gcc.gnu.org but did not get any reply about it. I have bootstrapped gcc 4.4.2 on my machine and now i have to make changes in gcc code. However, I dont know how to make those changes effective.Do I need to change the source files accordingly and bootstrap again or is there any other way of making changes in the source code and compiling only the affected source files. Point me to any documentation that may be available. Thanks in advance -- cheers sandy -- cheers sandy
Tree-SSA question
Hi,
I am working to knw the details of the tree-ssa pass.I had this small
piece of code as my test case:
void func()
{
int x=10;
int a=5;
if(a==x)
{
x=x+1;
}
else
{
x=x-1;
}
a=x;
}
and when i did a
> gcc -fdump-ftree-ssa -O3 foo.c
I got the following output :
func ()
{
int a;
int x;
:
x_2 = 10;
a_3 = 5;
if (a_3 == x_2)
goto ;
else
goto ;
:
x_4 = x_2 + 1;
goto ;
:
x_5 = x_2 + -1;
:
# x_1 = PHI
a_6 = x_1;
return;
}
Well..now I want to know what is the structure which this pass
maintains to emit these statements.Where can i find it (In which
source files)and can it be modified?
I chiefly want to separate the predicate of the if condition, the if
block and the else block..can it be done?
Point to me to the sources please.
Thanks In Advance
--
cheers
sandy
GIMPLE Front End (GSOC 2010)
-- Forwarded message -- From: Diego Novillo Date: Thu, Apr 29, 2010 at 7:05 PM Subject: Re: [LTO] Open items in the ToDo list To: Sandeep Soni Cc: Andi Hellmund Thanks Sandeep. Could you please add your proposal to the GCC wiki? Creating a new wiki page is fairly easy. You add your new page and then link it from the main page, put it somewhere in the index for 'Current projects' (keep it alphabetized, please). You can copy the format from another existing project page. Thanks. Diego. Hi, I added the following page to the wiki. http://gcc.gnu.org/wiki/GimpleFrontEnd Any comments/suggestions or ideas related to the project are welcome. Thanks. -- cheers sandy -- Cheers Sandy
Re: GIMPLE Front End (GSOC 2010)
On Thu, Apr 29, 2010 at 11:01 PM, Manuel López-Ibáñez wrote: > On 29 April 2010 19:25, Sandeep Soni wrote: >> I added the following page to the wiki. >> >> http://gcc.gnu.org/wiki/GimpleFrontEnd >> >> Any comments/suggestions or ideas related to the project are welcome. > > Hi Sandy, > > It may be helpful to take a look to wiki pages of previous SoC > projects, such as > http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings, for > formatting/structure ideas. > Indeed. The above mentioned page is extremely well detailed. I will be adding the granular details about the project as I work on it during this period and keep the wiki page updated.So will incorporate the structuring present on that page. Thanks indeed for the help. > Cheers, > > Manuel. > -- Cheers Sandy
Re: Build Error
On Tue, May 11, 2010 at 6:30 PM, Diego Novillo wrote: > [ Moved to gcc@gcc.gnu.org ] > Hmm, it did not detect elf_getshdrstrndx and yet it tried to use it > later on. I think that's the bug. Yes, please file a bug. I believe > it's going to be easy to fix, though. There should be an unguarded > use of that function somewhere, it needs to be changed. Filed a bug. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44079 Thanks. -- Cheers Sandy
Design Considerations of GIMPLE Front End
Hi, As part of GSoC 2010, I am developing a front end for GIMPLE. You can find the basic theme of the project at: http://gcc.gnu.org/wiki/GimpleFrontEnd One of the most important components in this GIMPLE Front End is to convert the GIMPLE tuples into text. How such a textual representation should be, will obviously dictate the design and complexity of the subsequent parsing component. So, as per Diego's suggestion, to have a view on some of the issues I have started this thread. Following are some of the issues/questions that have come up: 1. What should be the format of representation of the GIMPLE tuples in text? Ideally, the textual representation should be satisfying two goals: Easy to parse and easy for a programmer to write by hand.Considering this,what is the best way in which the GIMPLE tuples be represented. For example: A textual GIMPLE tuple for the statement a=b+c can be like > (As demonstrated by the internal manual also). Is such a representation easy to parse? The other alternative is to represent the tuples in a C-like syntax much like what -fdump-tree-gimple flag does. Which is more better? In terms of ease in parsing, intuitiveness for a programmer to code by hand etc. Any other alternative? 2. The most important aspect in the representation is that of types. Since there are many possibilities in the types, mapping each in a common representation can be difficult. An approach suggested by Diego is to read what fields are read from 'tree' structures and then lay out the tuples as follows: > So, we make all the sub-structures into nested tuples. This seems to be easy to parse. Again the question: Are there any ideas from anybody about the way the types be represented so that the parsing becomes simple? 3. Finally, what could be the overall structure of such a textual gimple file. A possible way could be to have the same structure as the sections encoded in the bytestream.So we can have a section for types, symbols, function bodies etc. Such a simple structure will be helpful for any programmer and be relatively easy to parse. Any other ideas? arguments against such a structure? So, If there are any alternative ideas to any one of these or arguments in favour of /against the ideas presented in this mail. Please add it to this thread. If there are any more vital points which are missing in this mail but require serious discussions, please add them to this thread too. -- Cheers Sandy
Re: Design Considerations of GIMPLE Front End
On Tue, May 18, 2010 at 2:34 AM, Andrew Haley wrote: >> For example: >> A textual GIMPLE tuple for the statement a=b+c can be like >> > (As demonstrated by the internal >> manual also). >> Is such a representation easy to parse? > > S-expressions are easier to parse and more compact, and are consistent > with gcc's back end. Also, there are editors that already know how to > edit and indent S-expressions. Thanks Andrew . Any thoughts on the 3rd point? > > Andrew. > -- Cheers Sandy
Re: Design Considerations of GIMPLE Front End
On Tue, May 18, 2010 at 8:33 PM, Diego Novillo wrote: > Yup. This shade of blue can be changed later. Sandi, let's start > with the S-expression syntax for everything. Richard is correct in > pointing out that even gimple expressions have metadata associated > with them that will need to be represented. Yes. I will start editing the wiki page created to document the S-expression syntax and the grammar. This will be an ongoing process though, in parallel with my current work of getting familiar with the LTO code base, so might take some time earlier on. > > > Diego. > -- Cheers Sandy
