Re: [graphite] Get graphite backend working again [scalar variable handling]
Tobias Grosser wrote:
> I would like to improve the way how we handle scalar variables and ivs
> during graphite transformation.
> I am not sure, if I got it right and where to put my code in the backend.
> So it would be great, if you could read over my ideas.
>
> The problem:
>
> In graphite we represent the complete loop structure using polyhedrons to
> apply our transformations.
> To go back to gimple we have to generate new loop structures and delete
> the old loop structures.
> One step is to remove old ivs and generate new ones.
>
>
> Example:
>
> 1. original bb:
>
> D.1918_7 = a[i_22];
> D.1919_8 = D.1918_7 + 1;
> a[j_21] = D.1919_8;
> j_9 = j_21 + 1;
>
>
>
> 2. Add new ivs
>
> graphiteIV_1 = PHI (0, graphiteIV_2)
>
> D.1918_7 = a[i_22];
> D.1919_8 = D.1918_7 + 1;
> a[j_21] = D.1919_8;
> j_9 = j_21 + 1;
>
> graphiteIV_2 = graphiteIV_1 + 1
>
>
> 3. Move ivs usages to the ivs.
>
> graphiteIV_1 = PHI (0, graphiteIV_2)
>
> D.1918_7 = a[i_22];
> D.1919_8 = D.1918_7 + 1;
> a[graphiteIV_1] = D.1919_8;
> j_9 = j_21 + 1;
>
> graphiteIV_2 = graphiteIV_1 + 1
>
>
> 4. remove ivs (Here {j_9, j_21})
>
>
> D.1918_7 = a[i_22];157235101 disconnected
> D.1919_8 = D.1918_7 + 1;
> a[graphiteIV_1] = D.1919_8;
>
That's my understanding as well.
> The problem seems to become more complicate, if there exist two or more
> ivs.
More complicated if you want to make sure all dead variables are removed
(with the associated definition code), but is it critical, given that a
PRE/CSE will clean this up afterwards?
> How I would like to solve it:
> =
>
> During gimple->graphite transformation we ignore all scalar variables,
> that we can represent using scev. (These contain also all the ivs)
>
> Here {D.1918_7, D.1919_8} are not representable, as they depend on the
> value of a[i_22]. Therefore we can not ignore them.
> But {j_9, j_21} will be representable and we ignore them.
>
> During graphite we have all ivs virtually removed.
This would be very good. I fully agree, yet more motivated by dependence
removal rather than clean-output goals (cf. PRE/CSE argument).
> The next step is during code generation:
> We remove all scalar variables, we ignored before, and recreate for the
> places, where they where used, new scalar variables, that depend on the
> new ivs.
The tricky part might be that those so-called "new variables" have to be
named like the old ones, although plenty of new variables will have
been synthesized in the mean time.
> Why remove all and not just the ivs?
>
>
> There are two points.
>
> 1. Detection ivs is much work. So I prefer this general algorithm, as I
> hope it is easier to implement and runs faster.
Agree.
> 2. If we can ignore the scalar variables, we can also ignore their
> dependencies. So we have more freedom to schedule the bbs.
Exactly.
>
> See you
> Tobi
>
> P.S.: To start working on my code I would like to get block-0.c running.
> Jan, can I help you with anything?
Re: Creating own Backend: Segmentation fault in mark_jump_label_1
Ben Elliston schrieb: > Perhaps you could get a stack backtrace and try to understand why you're > getting a NULL_RTX passed in? I already made a stack backtrace and posted it in my first mail: Program received signal SIGSEGV, Segmentation fault. 0x081c5d48 in mark_jump_label_1 (x=0x0, insn=0xb7b77118, in_mem=0 '\0', is_target=0 '\0') at ../.././gcc/jump.c:987 987 RTX_CODE code = GET_CODE (x); (gdb) where #0 0x081c5d48 in mark_jump_label_1 (x=0x0, insn=0xb7b77118, in_mem=0 '\0', is_target=0 '\0') at ../.././gcc/jump.c:987 #1 0x081c60e0 in mark_jump_label_1 (x=0xb7b70e28, insn=0xb7b77118, in_mem=0 '\0', is_target=0 '\0') at ../.././gcc/jump.c:1108 #2 0x081c5d2f in mark_jump_label (x=0xb7b70e28, insn=0xb7b77118, in_mem=0) at ../.././gcc/jump.c:974 #3 0x081c4af4 in mark_all_labels (f=0xb7bdb120) at ../.././gcc/jump.c:194 #4 0x081c48f7 in rebuild_jump_labels (f=0xb7bdb120) at ../.././gcc/jump.c:86 #5 0x08418fdf in tree_expand_cfg () at ../.././gcc/cfgexpand.c:1935 #6 0x08203198 in execute_one_pass (pass=0x856a640) at ../.././gcc/passes.c:1122 #7 0x082032e4 in execute_pass_list (pass=0x856a640) at ../.././gcc/passes.c:1175 #8 0x082ca0fd in tree_rest_of_compilation (fndecl=0xb7bd7a10) at ../.././gcc/tree-optimize.c:404 #9 0x083db7bd in cgraph_expand_function (node=0xb7b73280) at ../.././gcc/cgraphunit.c:1157 #10 0x083da461 in cgraph_assemble_pending_functions () at ../.././gcc/cgraphunit.c:523 #11 0x083da72d in cgraph_finalize_function (decl=0xb7bd7a10, nested=0 '\0') at ../.././gcc/cgraphunit.c:641 #12 0x0805a470 in finish_function () at ../.././gcc/c-decl.c:6803 #13 0x080a7f9b in c_parser_declaration_or_fndef (parser=0xb7be2b28, fndef_ok=1 '\001', empty_ok=1 '\001', nested=0 '\0', start_attr_ok=1 '\001') at ../.././gcc/c-parser.c:1424 #14 0x080a7920 in c_parser_external_declaration (parser=0xb7be2b28) at ../.././gcc/c-parser.c:1179 #15 0x080a762c in c_parser_translation_unit (parser=0xb7be2b28) at ../.././gcc/c-parser.c:1081 #16 0x080b44c1 in c_parse_file () at ../.././gcc/c-parser.c:8011 #17 0x0809b675 in c_common_parse_file (set_yydebug=0) at ../.././gcc/c-opts.c:1291 #18 0x082861fa in compile_file () at ../.././gcc/toplev.c:1042 #19 0x08287bc4 in do_compile () at ../.././gcc/toplev.c:2247 #20 0x08287c26 in toplev_main (argc=2, argv=0xbfa608c4) at ../.././gcc/toplev.c:2279 #21 0x080bba42 in main (argc=Cannot access memory at address 0x0 ) at ../.././gcc/main.c:35 But it doesn't really help me, because I don't know all this functions. Do you know what they do and when they are called? I found out that the RTX which enters mark_jump_label and later causes the error is a "parallel". That is strange, because a don't use parallels in my machine description file(*.md) yet. The parallel RTX is passed to mark_jump_label() and from there to mark_jump_label_1(). In mark_jump_label_1 in line 1108 it takes XVECEXP (x, i, j) from the RTX x and the value of this XVECEXP-expression is null. So I thik the error occures either because the RTX is not valid or because VECEXP dont't work right or because the variables i and j are too big/wrong. The value of i goes from GET_RTX_LENGTH (code), where code is GET_CODE(RTX x), to 0. j goes from XVECLEN (x, i) - 1 to 0. Can I influence one of these things with the Target Makros or the Machine Description? signature.asc Description: OpenPGP digital signature
Re: [graphite] Get graphite backend working again [scalar variable handling]
On Wed, 2008-08-20 at 09:10 +0200, Albert Cohen wrote:
> Tobias Grosser wrote:
> > I would like to improve the way how we handle scalar variables and ivs
> > during graphite transformation.
> > I am not sure, if I got it right and where to put my code in the backend.
> > So it would be great, if you could read over my ideas.
> >
> > The problem:
> >
> > In graphite we represent the complete loop structure using polyhedrons to
> > apply our transformations.
> > To go back to gimple we have to generate new loop structures and delete
> > the old loop structures.
> > One step is to remove old ivs and generate new ones.
> >
> >
> > Example:
> >
> > 1. original bb:
> >
> > D.1918_7 = a[i_22];
> > D.1919_8 = D.1918_7 + 1;
> > a[j_21] = D.1919_8;
> > j_9 = j_21 + 1;
> >
> >
> >
> > 2. Add new ivs
> >
> > graphiteIV_1 = PHI (0, graphiteIV_2)
> >
> > D.1918_7 = a[i_22];
> > D.1919_8 = D.1918_7 + 1;
> > a[j_21] = D.1919_8;
> > j_9 = j_21 + 1;
> >
> > graphiteIV_2 = graphiteIV_1 + 1
> >
> >
> > 3. Move ivs usages to the ivs.
> >
> > graphiteIV_1 = PHI (0, graphiteIV_2)
> >
> > D.1918_7 = a[i_22];
> > D.1919_8 = D.1918_7 + 1;
> > a[graphiteIV_1] = D.1919_8;
> > j_9 = j_21 + 1;
> >
> > graphiteIV_2 = graphiteIV_1 + 1
> >
> >
> > 4. remove ivs (Here {j_9, j_21})
> >
> >
> > D.1918_7 = a[i_22];157235101 disconnected
> > D.1919_8 = D.1918_7 + 1;
> > a[graphiteIV_1] = D.1919_8;
> >
>
> That's my understanding as well.
>
> > The problem seems to become more complicate, if there exist two or more
> > ivs.
>
> More complicated if you want to make sure all dead variables are removed
> (with the associated definition code), but is it critical, given that a
> PRE/CSE will clean this up afterwards?
You are right. May be we can ignore that step completely.
>
> > How I would like to solve it:
> > =
> >
> > During gimple->graphite transformation we ignore all scalar variables,
> > that we can represent using scev. (These contain also all the ivs)
> >
> > Here {D.1918_7, D.1919_8} are not representable, as they depend on the
> > value of a[i_22]. Therefore we can not ignore them.
> > But {j_9, j_21} will be representable and we ignore them.
> >
> > During graphite we have all ivs virtually removed.
>
> This would be very good. I fully agree, yet more motivated by dependence
> removal rather than clean-output goals (cf. PRE/CSE argument).
Yes, that's also my important point. Later I hope to get rid of all
dependencies between scalar variables, but let's start with the easier
ones, already representable using scev.
>
> > The next step is during code generation:
> > We remove all scalar variables, we ignored before, and recreate for the
> > places, where they where used, new scalar variables, that depend on the
> > new ivs.
>
> The tricky part might be that those so-called "new variables" have to be
> named like the old ones, although plenty of new variables will have
> been synthesized in the mean time.
Why is there a need to name the new ones like the old ones? The only
reason I can think about is debugging. And I am not sure if their exists
a strong relation between old an new ones, that makes it reasonable to
call them identical. During all the code motion, we ignored the scalar
variables completely, and the recreation using scev has only a weak
relation to the original variables. So I think we may get completely new
ones as for me it does not make sense to keep these relation.
But you seem to have a different opinion. What makes you think, the new
ones have to be called like the old ones? What relation do you see?
>
> > Why remove all and not just the ivs?
> >
> >
> > There are two points.
> >
> > 1. Detection ivs is much work. So I prefer this general algorithm, as I
> > hope it is easier to implement and runs faster.
>
> Agree.
>
> > 2. If we can ignore the scalar variables, we can also ignore their
> > dependencies. So we have more freedom to schedule the bbs.
>
> Exactly.
>
> >
> > See you
> > Tobi
> >
> > P.S.: To start working on my code I would like to get block-0.c running.
> > Jan, can I help you with anything?
>
Re: Creating own Backend: Segmentation fault in mark_jump_label_1
Balthasar Biedermann <[EMAIL PROTECTED]> writes: > #0 0x081c5d48 in mark_jump_label_1 (x=0x0, insn=0xb7b77118, in_mem=0 > '\0', is_target=0 '\0') at ../.././gcc/jump.c:987 > #1 0x081c60e0 in mark_jump_label_1 (x=0xb7b70e28, insn=0xb7b77118, > in_mem=0 '\0', is_target=0 '\0') at ../.././gcc/jump.c:1108 Some insn was generated incorrectly: the field of the insn should not be NULL. You are going to have to find out why. This is a bug in your backend. There is no way that we can possibly know what the problem is. > I found out that the RTX which enters mark_jump_label and later causes > the error is a "parallel". That is strange, because a don't use > parallels in my machine description file(*.md) yet. > The parallel RTX is passed to mark_jump_label() and from there to > mark_jump_label_1(). In mark_jump_label_1 in line 1108 it takes XVECEXP > (x, i, j) from the RTX x and the value of this XVECEXP-expression is > null. So I thik the error occures either because the RTX is not valid or > because VECEXP dont't work right or because the variables i and j are > too big/wrong. The value of i goes from GET_RTX_LENGTH (code), where > code is GET_CODE(RTX x), to 0. j goes from XVECLEN (x, i) - 1 to 0. Yes. The RTX is not valid. > Can I influence one of these things with the Target Makros or the > Machine Description? Yes. Look to find out where that PARALLEL was created, and why. Use debug_rtx to find the insn uid. Set a breakpoint on, e.g., make_jump_insn_raw and find out what is creating that particular insn. Writing your own gcc backend requires digging into the code and figuring it out. It's not simple. We can't answer precise and detailed questions about how it is supposed to work, but we can't help you debug it. Ian
Re: Better GCC diagnostics
> That is clear. Thanks. I personally would be perfectly happy if the > compiler said > bug.c:4.COLUMN: error: called object is not a function > That is, fixing the compiler to includes parts of the source code in > the error message itself is, for me, of considerably lower priority > than fixing the compiler to generate good column numbers. I agree. Any decent IDE or source editor will point to the proper location once you have the correct column number. Arno
Re: Better GCC diagnostics
> Oh yes. Well, there is a lot of fine-tunning to do but I think that
> would be covered by A.1 and the binary_op expression would have at
> least two locations begin/end pointing to X and r. If we are able to
> print ({break;}), in the example I gave earlier, then we will be able
> to print nice ranges most of the time.
Interestingly, I am working right now on improving location information
in the C (and possibly in the future C++) front-end, for the need of
static analysis tools, and generation of cross-ref information (for use
by IDEs), and have added locally support for additional locations for
many expressions.
The way I did it, since I thought that adding a new location_t field in
the expr struct would likely be a no-no (due to additional memory usage) is to
use a hash table "on the side", and use macros (SET_EXPR_LOCATION2,
GET_EXPR_LOCATION2) that are no-ops by default, and that populate the
hash table when a given switch is enabled.
I was planning to submit these changes at some later point, since this
is still work in progress at this stage, but can work on submitting these
earlier if this would help people in other contexts, and/or avoid duplicate
work.
Note that my patch not only adds support for additional locations (and it
even adds as much locations as needed for each argument of a function call),
but also fixes column number information in several cases.
Arno
[graphite] Use of loops_mappings (SVN r138161)
Hi Jan, hi Sebastian, while looking in the graphite backend code I stepped over a commit (r138161) introducing graphite_loops_mapping. At the moment I do not understand perfectly for what it is used, as it seems to mirror a feature I already implemented (see graphite.h): --- /* LOOPS contains for every column in the graphite domain the corresponding gimple loop. If there exists no corresponding gimple loop LOOPS contains NULL. Example: Original code: for (i = 0; i <= 20; i++) for (j = 5; j <= 10; j++) A Original domain: (I)eq i j 1 1 1 0 0 # i >= 0 1 -1 0 20 # i <= 20 1 0 1 0 # j >= 0 1 0 -1 10 # j <= 10 Original loops vector: 0 1 Loop iLoop j After some changes (Exchange i and j, strip-mine i): Domain: (I)eq j ii i k 1 1 0 0 1 0 0 # i >= 0 1 0 0 -1 0 20 # i <= 20 1 1 0 0 0 0 # j >= 0 1 -1 0 0 0 10 # j <= 10 1 0 -1 1 0 0 # ii <= i 1 0 1 -1 0 1 # ii + 1 >= i 1 0 -1 0 2 0 # ii <= 2k 1 0 1 0 -2 0 # ii >= 2k Iterator vector: 012 3 Loop j NULL Loop iNULL Means the original loop i is now at column two of the domain and loop j in the original loop nest is now at column 0. Column 1 and 3 are emtpy. */ VEC (loop_p, heap) *loops; /* Returns the gimple loop, that corresponds to the loop_iterator_INDEX. If there is no corresponding gimple loop, we return NULL. */ static inline loop_p gbb_loop_at_index (graphite_bb_p gb, int index); /* Returns the corresponding loop iterator index for a gimple loop. */ static inline int gbb_loop_index (graphite_bb_p gb, loop_p loop); --- During your commit you removed my code from the graphite_trans_* functions. Can you explain why you decided to replace GBB_LOOPS with loops_mapping? Where there any shortcomings in my implementation or did you need some different features? Is GBB_LOOPS completely replaced by loops_mapping? In this case I will remove the remaining parts of GBB_LOOPS. It would be great, if you could add some documentation for loops_mapping, as I am not sure, if I understand your code correct. It seems, that you make a mapping from SCOP_LOOPS() to the index in the cloog matrices. I think, that this is not always possible. If we have for example a loop A in SCOP_LOOPS (), that we split during graphite into two loops B1, B2. The first loop, B1, can be blocked the second one, B2, not. So we get for the A->B1 a different mapping as for A->B2. Thanks Tobi
Re: Better GCC diagnostics
2008/8/20 Arnaud Charlet <[EMAIL PROTECTED]>: > > The way I did it, since I thought that adding a new location_t field in > the expr struct would likely be a no-no (due to additional memory usage) is to > use a hash table "on the side", and use macros (SET_EXPR_LOCATION2, > GET_EXPR_LOCATION2) that are no-ops by default, and that populate the > hash table when a given switch is enabled. > > I was planning to submit these changes at some later point, since this > is still work in progress at this stage, but can work on submitting these > earlier if this would help people in other contexts, and/or avoid duplicate > work. As far as I know nobody is working on adding more locations, so do as you please. If I ever get the time, I would like to abstract our line-map implementation within a "location_manager" object and API but I don't think this conflicts directly with your work. Would your implementation also handle two locations for tokens that come from macro expansion? > Note that my patch not only adds support for additional locations (and it > even adds as much locations as needed for each argument of a function call), > but also fixes column number information in several cases. Those fixes should be submitted as soon as you find them, please. Cheers, Manuel.
Re: Better GCC diagnostics
> Would your implementation also handle two locations for tokens that
> come from macro expansion?
macro expansion are tricky to handle as far as I could see, so currently
this is not handled. It's tricky because some locations are "real" in
the source, and some are "virtual" from the macro.
Consider for example:
#define PLUS(a) ((a) + global_var)
when in the source you have:
source: PLUS (x)
column: 1 5 7
you would like to have a location associated with 'x' ('a' in the macro),
pointing to column 7, and not to e.g. column 1 as done currently.
On the other hands, the implicit reference to 'global_var' is what I
call "virtual", and I guess the closest approximation in terms of
location in the original source would be 'column 7' as well, assuming
we want to represent it.
> Those fixes should be submitted as soon as you find them, please.
Sure, some clean ups are still needed, but submitted them as soon as
practical is part of the plans (my work is based on gcc trunk, so at least
there's no issue of forward porting my changes).
Thanks for your feedback,
Arno
Re: Better GCC diagnostics
> "Manuel" == Manuel López-Ibáñez <[EMAIL PROTECTED]> writes: Manuel> If I ever get the time, I would like to abstract our line-map Manuel> implementation within a "location_manager" object and API but Manuel> I don't think this conflicts directly with your work. I am curious to know how this would be different from what we have now. I think the line-map API is rather ugly, personally, but it seems to me that a "struct line_maps" is essentially a location manager object. Tom
Re: Better GCC diagnostics
2008/8/20 Tom Tromey <[EMAIL PROTECTED]>:
>> "Manuel" == Manuel López-Ibáñez <[EMAIL PROTECTED]> writes:
>
> Manuel> If I ever get the time, I would like to abstract our line-map
> Manuel> implementation within a "location_manager" object and API but
> Manuel> I don't think this conflicts directly with your work.
>
> I am curious to know how this would be different from what we have
> now.
>
> I think the line-map API is rather ugly, personally, but it seems to
> me that a "struct line_maps" is essentially a location manager object.
It is essentially. However, all the internal things are exposed all
over the place for no good reason.
This is in gcc/c-lex.c
/* #define callback for DWARF and DWARF2 debug info. */
static void
cb_define (cpp_reader *pfile, source_location loc, cpp_hashnode *node)
{
- const struct line_map *map = linemap_lookup (line_table, loc);
- (*debug_hooks->define) (SOURCE_LINE (map, loc),
+ (*debug_hooks->define) (location_source_line (location_manager, loc),
(const char *) cpp_macro_definition (pfile, node));
}
This is in tree.h
-expanded_location
-expand_location (source_location loc)
-{
- expanded_location xloc;
- if (loc == 0)
-{
- xloc.file = NULL;
- xloc.line = 0;
- xloc.column = 0;
- xloc.sysp = 0;
-}
- else
-{
- const struct line_map *map = linemap_lookup (line_table, loc);
- xloc.file = map->to_file;
- xloc.line = SOURCE_LINE (map, loc);
- xloc.column = SOURCE_COLUMN (map, loc);
- xloc.sysp = map->sysp != 0;
-};
- return xloc;
-}
+#define expand_location(LOC) location_expand (location_manager, (LOC))
+
Moreover, the location_manager probably should be separated from CCP.
If we want to implement re-opening files and reading strings given
locations, then opening/reading files should also be moved out of CCP
to its own module/namespace/object.
Cheers,
Manuel.
Re: Better GCC diagnostics
> If we want to implement re-opening files and reading strings given > locations, then opening/reading files should also be moved out of CCP > to its own module/namespace/object. Agreed. Other modules may find these APIs very handy. Currently many features are only available very deep or hidden inside libcpp implementation that could be useful in other contexts (such as e.g. getting source file dependency information). Arno
Re: Better GCC diagnostics
2008/8/20 Arnaud Charlet <[EMAIL PROTECTED]>: >> If we want to implement re-opening files and reading strings given >> locations, then opening/reading files should also be moved out of CCP >> to its own module/namespace/object. > > Agreed. Other modules may find these APIs very handy. > Currently many features are only available very deep or hidden inside > libcpp implementation that could be useful in other contexts (such > as e.g. getting source file dependency information). Not just that, probably Fortran/Ada are already duplicating stuff that is in libcpp or they are implementing their own version of stuff that C/C++ are lacking (caret diagnostics? character encodings?). Cheers, Manuel.
Re: Better GCC diagnostics
> Not just that, probably Fortran/Ada are already duplicating stuff that > is in libcpp or they are implementing their own version of stuff that > C/C++ are lacking (caret diagnostics? character encodings?). Well, clearly, the preprocessor and handling of #include is very C/C++ specific, and not used by Ada or Fortran. As for diagnostics, Ada does use its own mechanism, mainly because it's much more powerful than the one in libcpp, and handles e.g. multiple locations related to cascaded generic package instantiations (C++ templates), as well as many other goodies already described by Robert is previous messages. It has also handled column info from day one (and we would not want any of the e.g. -fshow-column stuff: why would you *not* want to display column information ? :-) So from GNAT's point of view, what's the point in duplicating all this work done and written in Ada in another less capable language (which would also make it more painful for GNAT developers to use), in particular if this capability is only available in very recent GCC versions. Arno
RE: [graphite] Use of loops_mappings (SVN r138161)
> Hi Jan, hi Sebastian, > > Can you explain why you decided to replace GBB_LOOPS with > loops_mapping? > Where there any shortcomings in my implementation or did you need some > different features? I think we got confused about the existing implementation. The concern was that a transform could affect multiple GBBs/loops, but everything is done to individual GBBs so that is not the case. > Is GBB_LOOPS completely replaced by loops_mapping? In this case I will > remove the remaining parts of GBB_LOOPS. We should remove the loops_mapping instead since the existing implementation is simpler. I tired to remove the loops_mapping and use the GBB_LOOPS instead and all the tests pass. - Jan
Re: Creating own Backend: Segmentation fault in mark_jump_label_1
On Wed, Aug 20, 2008 at 06:31:11AM -0700, Ian Lance Taylor wrote: > Writing your own gcc backend requires digging into the code and > figuring it out. It's not simple. We can't answer precise and > detailed questions about how it is supposed to work, but we can't help > you debug it. I think you meant to say "We can answer precise and detailed ...".
Re: Creating own Backend: Segmentation fault in mark_jump_label_1
Joe Buck <[EMAIL PROTECTED]> writes: > On Wed, Aug 20, 2008 at 06:31:11AM -0700, Ian Lance Taylor wrote: >> Writing your own gcc backend requires digging into the code and >> figuring it out. It's not simple. We can't answer precise and >> detailed questions about how it is supposed to work, but we can't help >> you debug it. > > I think you meant to say "We can answer precise and detailed ...". Um, yes. Sorry, and thanks for the correction. Ian
Re: Better GCC diagnostics
Manuel López-Ibáñez wrote: 2008/8/20 Arnaud Charlet <[EMAIL PROTECTED]>: If we want to implement re-opening files and reading strings given locations, then opening/reading files should also be moved out of CCP to its own module/namespace/object. Agreed. Other modules may find these APIs very handy. Currently many features are only available very deep or hidden inside libcpp implementation that could be useful in other contexts (such as e.g. getting source file dependency information). Not just that, probably Fortran/Ada are already duplicating stuff that is in libcpp or they are implementing their own version of stuff that C/C++ are lacking (caret diagnostics? character encodings?). The error mechanism in Ada is very extensive, probably would be quite a bit of work to find out how to interface effectively to this API, but something that would be nice to do in the long run. Cheers, Manuel.
[graphite] Google Summer of Code 2008 is over - Thank you
Hi gcc community, hi graphities, since Monday Google Summer of Code 2008 is over and I would like to write a little bit about my SOC project. First of all I would like to thank Sebastian for being my mentor. It was really fun to work with you. I never felt alone and always got great mail or phone response, if I was not sure where to go. And also thanks to all the other gcc and graphite people, that contributed to graphite and helped me working on my GSoC project. I got many valuable mails and bug reports helping me improving my code. What I really liked was the good integration in the graphite team, so that from the first days I felt like home. I got all support I needed and our weekly (except exceptions) phone conferences helped me to get to know the team better. Now I know some of you by hearing your voice, but it would be even better to see you once in real live! I also would like to thank Laurent for the CompileFarm account. A very useful service for gcc development. In the last weeks I realized a little problem in my graphite work. As I worked so well with the graphite folks, I just completely forgot to use the gcc mailing lists and to get in touch with the countless gcc developers. So I apologize for this and will try to change this now. As a starter I would like to inform you, what I have done during the last 4 months: What I wanted to do: […] At the moment the general shape of the GRAPHITE framework is quite clear and people have started to work on different areas. While they reached new areas of development, it became quite clear, that the GRAPHITE frontend, the translation from GIMPLE to GRAPHITE has some serious drawbacks, which stop people to continue their development fast and efficiently. During Summer of Code I would like to solve these problems and build a solid basis for further graphite development. […] More on my proposal at: http://students.fim.uni-passau.de/~grosser/gcc_soc/ What is done: = 1. SCoP detection - We scan the CFG to detect all parts, that we can transform to the polyhedral representation (GRAPHITE). * This pass works and is verified by the graphite and polyhedron test suites. * We detect conditions containing (<=, <, >, >=), perfect loop nests with single exit, and allow parameters in loop borders and conditons. 2. GIMPLE => GRAPHITE - Now the control flow of the detected SCoPs is translated to the polyhedral representation. This means loop borders and conditions are inserted into a matrix, that tells us for which values of the loop indeces the bbs are executed. * Works for all detected SCoPs 3. Cloog Output --- Cloog is the library we use to regenerate the CFG. We insert the polyhedral model and get an ast, describing the loop structure after applied optimizations. Cloog is also able to optimize in control structures (e.g. move conditions out of loops) so even without optimizations passes we get optimizations. * Works for all detected SCoPs 4. Loop blocking * I wrote a first experimental pass, to show how graphite transformations work. So GRAPHITE has now a front end, that is able to detect most of the common loop nests and get them into the graphite representation. In Polyhedron e.g. we detect already 411 SCoPs with 536 loops and 1303 bbs. These are 15% of all loops (3587). And there is many space for improvements. What is left to be done: 1. SCoP detection - * Conditional statements containing “||” or “&&”. * Switch statements. * Loops with multiple exits. * Iterative optimization to maximize SCoP size. 2. GIMPLE => GRAPHITE - * Conditional statements containing “||” or “&&”. * Switch statements. * Loops with multiple exits. * Allow scev parameter detection in SCoPs, that are not surrounded by a loop. 3. Graphite middle end -- Here we reach hardly touched ground, where a large number of optimizations are possible. For example: * Dependency detection * Loop splitting * Loop fusing * … * Automatic parallization I will keep on working on graphite, the next weeks on the import and after that heading to some of the open tasks. So even if Google Summer of Code has finished. I do not want to say “Goodbye”, but “Hello” to you. I am looking forward to work with you on gcc and graphite! See you Tobi
gcc-4.2-20080820 is now available
Snapshot gcc-4.2-20080820 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20080820/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.2 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_2-branch revision 139353 You'll find: gcc-4.2-20080820.tar.bz2 Complete GCC (includes all of below) gcc-core-4.2-20080820.tar.bz2 C front end and core compiler gcc-ada-4.2-20080820.tar.bz2 Ada front end and runtime gcc-fortran-4.2-20080820.tar.bz2 Fortran front end and runtime gcc-g++-4.2-20080820.tar.bz2 C++ front end and runtime gcc-java-4.2-20080820.tar.bz2 Java front end and runtime gcc-objc-4.2-20080820.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.2-20080820.tar.bz2The GCC testsuite Diffs from 4.2-20080813 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.2 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: [graphite] Google Summer of Code 2008 is over - Thank you
Hi Tobias, On Wed, Aug 20, 2008 at 4:45 PM, Tobias Grosser <[EMAIL PROTECTED]> wrote: > So even if Google Summer of Code has finished. I do not want to say > "Goodbye", but "Hello" to you. > I am looking forward to work with you on gcc and graphite! > I would like to say a big thank you for your contributions. It was a pleasure to work with you during this SOC, and I hope to have your valuable opinion, remarks and patches for loop optimizations and parallelization on top of the graphite infrastructure. Sebastian
How to use gcc source and try new optmization techniques
Hi, I am a student in Utah State University researching on compilers optimization techniques. I wanted to know how I could use gcc for experimenting with optimization. Here is what I intend to do: 1) Understand the control flow graphs being generated by GCC, which I could build using the -fdump-tree-cfg option. 2) Write code that could convert CFG to a different graph. 3) Use this new graph for optimization. 4) Use the optimized graph to generate machine code (say Intel architecture for now). Please let me know how I could leverage the GCC code for this purpose, and if you any suggestions/comments for me you are most welcome ! :) Thanks, Rohan
Re: How to use gcc source and try new optmization techniques
Hi, I may not have correctly understood your questions but from what I understand I think you mean to ask how you could easily plug in your optimization pass into GCC so as to test your implementation of some optimization. Well, the way to do that would be to understand the pass structure and decide where in the order of passes should your pass be inserted i.e after which and before which other pass should your optimization pass fit in. Look at passes.c to see how the order of passes is specified. Once you have told the compiler when to execute your pass (primarily through passes.c) and provided your optimization has been correctly implemented in the context of GCC you should be good to go. HTH, Pranav On Wed, Aug 20, 2008 at 7:45 PM, Rohan Sreeram <[EMAIL PROTECTED]> wrote: > Hi, > > I am a student in Utah State University researching on compilers optimization > techniques. > I wanted to know how I could use gcc for experimenting with optimization. > > Here is what I intend to do: > > 1) Understand the control flow graphs being generated by GCC, which I could > build using the -fdump-tree-cfg option. > 2) Write code that could convert CFG to a different graph. > 3) Use this new graph for optimization. > 4) Use the optimized graph to generate machine code (say Intel architecture > for now). > > Please let me know how I could leverage the GCC code for this purpose, and if > you any suggestions/comments for me you are most welcome ! :) > > Thanks, > Rohan > > > > >
Re: How to use gcc source and try new optmization techniques
Hi Rohan, I have already worked on cfg data structure, plugin "data flow pass" on cfg. For this purpose, following links would be useful. http://www.cse.iitb.ac.in/~uday/gcc-workshop/?file=downloads more info can be available at http://www.cse.iitb.ac.in/grc/ - Seema On Thu, Aug 21, 2008 at 6:51 AM, Pranav Bhandarkar <[EMAIL PROTECTED]> wrote: > > Hi, > > I may not have correctly understood your questions but from what I > understand I think you mean to ask how you could easily plug in your > optimization pass into GCC so as to test your implementation of some > optimization. > > Well, the way to do that would be to understand the pass structure and > decide where in the order of passes should your pass be inserted i.e > after which and before which other pass should your optimization pass > fit in. Look at passes.c to see how the order of passes is specified. > > Once you have told the compiler when to execute your pass (primarily > through passes.c) and provided your optimization has been correctly > implemented in the context of GCC you should be good to go. > > HTH, > Pranav > > On Wed, Aug 20, 2008 at 7:45 PM, Rohan Sreeram <[EMAIL PROTECTED]> wrote: > > Hi, > > > > I am a student in Utah State University researching on compilers > > optimization techniques. > > I wanted to know how I could use gcc for experimenting with optimization. > > > > Here is what I intend to do: > > > > 1) Understand the control flow graphs being generated by GCC, which I could > > build using the -fdump-tree-cfg option. > > 2) Write code that could convert CFG to a different graph. > > 3) Use this new graph for optimization. > > 4) Use the optimized graph to generate machine code (say Intel architecture > > for now). > > > > Please let me know how I could leverage the GCC code for this purpose, and > > if you any suggestions/comments for me you are most welcome ! :) > > > > Thanks, > > Rohan > > > > > > > > > >
optimizations with -mcpu=cortex-a8, -mtune=cortex-a8
Hi, I came across the -mpcu=cortex-a8 option in the codesourcery gcc. When I added that to build the Linux kernel, I found that there are no differences in the kernel code with and without the options. The following are the gcc options that where used to build the kernel. Am I missing something? -nostdinc -isystem /data/arm-2007q3/bin/../lib/gcc/arm-none-linux-gnueabi/4.2.1/include -mlittle-endian -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Os -fno-stack-protector -marm -fno-omit-frame-pointer -mapcs -mno-sched-prolog -mabi=aapcs-linux -mno-thumb-interwork -march=armv7a -mcpu=cortex-a8 -mtune=cortex-a8 -msoft-float -Uarm -fno-omit-frame-pointer -fno-optimize-sibling-calls -g -Wdeclaration-after-statement -Wno-pointer-sign Thanks, -Romit
