SoC Project: Incremental Parsing (of C++)
--Rationale-- (to be expanded in the actual application) * Parsing of C++ is slow * On large projects, compile times often dominate the compile/edit/debug cycle * Changes in source are often small and isolated * Preprocessed compilation units are often huge - esp. compared to the size of changes. => Recompiling only the changed part(s) should yield better compile times. --Proposal-- I propose to implement incremental parsing in C++ (through hand-waving, C++ has been decided to be the language most in need of incremental parsing), similar to the approach in article [1]. Basically, a diff algorithm is run on the character or token stream, producing a list of insertions, modifications, and deletions, and this list of changed characters/tokens is compared to the previous parse tree to decide what parts of the tree need reparsing and recompilation. In this project, I wouldn't even try to attack incremental code generation, but just run the entire middle/back end on an updated tree. A future extension would be to use the information about which trees have changed to perform minimal code generation. This approach obviously limits the improvement in compile time, and an important initial part of the project would be to measure the time spent in lexing, parsing and everything after parsing to see what the potential gain would be. --Implementation Ideas-- My implementation would store the tree representation and the token stream from a source file in the object file as a custom section or in an auxiliary file, and on each incremental compilation, the new source would be tokenized and a diff algorithm run on the old and the new token stream. This tree and token stream would be marked with compiler version (and probably build too, depending on the way in which they are serialized), and in case of a version mismatch the compiler would revert to a complete recompilation. For starters, I would only consider top-level constructs (i.e. if any token in a function, type or global-scope variable has changed, the entire declaration/ definition would be reparsed), in order to make the implementation simple. Presumably, the time spent on needlessly parsing unchanged portions of functions or types is very small due to the small number of changed declarations. The parser would be given the two token streams and the old tree, and every time a declaration or other top-level construct is parsed, you would check if any tokens in the declaration has changed and re-parsing is needed. --Observations-- A number of changes in source affect more than the tree of the construct itself (inline functions, function default values, templates etc.. see Problems below). In these cases, the initial implementation would just identify the dangerousness of the changes, abort, and initiate a complete recompilation of the file. A part of this project would be to identify *all* these cases, and handle them correctly. Would it be feasible to construct a dependency map of the tree, to handle these cases with minimal recompilation? How large would such a dependency map have to be? For checking, the initial implementation should also provide for a way to compare the result of the incremental reparse against a complete recompilation. Some of the information that is saved and updated in the aux file or object file is probably the same as what is saved in a GCH file. Would incremental update of GCH files be possible/interesting? Should this all be integrated into the precompiled header framework? I can't say I know enough about GCC's header precompilation to know what to do with it, though. --Problems and other thoughts-- * Changing a declaration (function arguments, default values), also affects all uses of the same declaration. * Adding and removing a template specialization changes all uses of the template after the declaration. * If code inside an inlined function body is changed, all (inlined) uses of the function also change. * What other cases like these have not yet been considered? * How much space does a serialized token stream take? * How much space does a serialized tree representation take? * How much time is actually spent in the parser? * Future: Incremental code generation --References-- [1] Incremental scanning and parsing with Galaxy. IEEE. Trans. Softw. Eng. 17, 7 (July), 641-651. (http://doi.ieeecomputersociety.org/10.1109/32.83901) Anyone interested in mentoring this project? Any other thoughts?
Re: We're out of tree codes; now what?
Steven Bosscher wrote: On 3/20/07, Mark Mitchell <[EMAIL PROTECTED]> wrote: I think it's fair for front ends to pay for their largesse. There are also relatively cheap changes in the C++ front end to salvage a few codes, and postpone the day of reckoning. I think that day of reckoning will come very soon again, with more C++0x work, more autovect work, OpenMP 3.0, and the tuples and LTO projects, etc., all requiring more tree codes. For that matter, does increasing the tree code limit to 512 codes instead of 256 actually put off the day of reckoning enough to be worth it? - Brooks
Re: Problem with building libgfortran on PPC
> > I've been using binutils 2.17 on various distributions of powerpc64-linux > and have had no problem with it. I used binutils 2.15. I guess this is the problem. Thanks, Revital > > Janis
Re: [4.2 RC1] Can't bootstrap with ada on cygwin
2007/3/18, Christian Joensson <[EMAIL PROTECTED]>: Under cygwin, I get a stage 2 and 3 comparison failure that's not supposed to be there... Comparing stages 2 and 3 warning: ./cc1-checksum.o differs warning: ./cc1obj-checksum.o differs warning: ./cc1objplus-checksum.o differs warning: ./cc1plus-checksum.o differs warning: ./libgcc/_chkstk.o differs Bootstrap comparison failure! ./ada/exp_aggr.o differs make[2]: *** [compare] Error 1 Any idea on why this happens? As I don't see any recent testresults for cygwin, I just need to ping here again... Has something gone wrong for cygwin such that there now are severe problems bootstrapping? -- Cheers, /ChJ
RE: We're out of tree codes; now what?
On 19 March 2007 22:41, Gabriel Dos Reis wrote: > > yeah, the trouble is that we don't seem to agree on what is good for > long-term, or if and when we agree whether we would find and allocate > resources to implement the solution. So, we end up accumulating > small% regressions over small% regressions. Then we get busy with > short-term fixes, because that is what gets the releases out the door. > Until the next trouble. > > -- Gaby As concise a summary of the report of the 1968 Nato conference on the crisis in software engineering as ever I've read! cheers, DaveK -- Can't think of a witty .sigline today
RE: Listing file-scope variables inside a pass
On 19 March 2007 22:16, Karthikeyan M wrote: > What should I do if I want a list of all file-scope variables inside > my own pass ? > > The file_scope variable is local to c-decl.c . Is there a reason why > the scope holding variables are local to c-decl.c ? Because we want to keep front-, mid- and back- ends of the compiler as modular and non-interdependent as possible, perhaps? If you need a routine to dump that data, why not write it in c-decl.c and just expose the prototype in a suitable header file (c-tree.h)? cheers, DaveK -- Can't think of a witty .sigline today
Re: We're out of tree codes; now what?
On 3/20/07, Brooks Moses <[EMAIL PROTECTED]> wrote: Steven Bosscher wrote: > On 3/20/07, Mark Mitchell <[EMAIL PROTECTED]> wrote: >> I think it's fair for front ends to pay for their >> largesse. There are also relatively cheap changes in the C++ front end >> to salvage a few codes, and postpone the day of reckoning. > > I think that day of reckoning will come very soon again, with more > C++0x work, more autovect work, OpenMP 3.0, and the tuples and LTO > projects, etc., all requiring more tree codes. For that matter, does increasing the tree code limit to 512 codes instead of 256 actually put off the day of reckoning enough to be worth it? I think so. It took us, what, 10 years to go through 256 codes? Even if we accelerate the pace of development significantly, we'll still get a few years out of 512 codes. All the while, we should be hunting to eliminate more of the "common" bits in tree_base (moving them into more specific substructures, like decl_common), allowing the tree code to increase in size. When we hit that 16-bit tree code, we'll get a small bump in performance when all of the masking logic just disappears. 16 bits is my goal, 9 bits is today's fix. Cheers, Doug
Re: We're out of tree codes; now what?
On Tue, 20 Mar 2007, Doug Gregor wrote: > On 3/20/07, Brooks Moses <[EMAIL PROTECTED]> wrote: > > Steven Bosscher wrote: > > > On 3/20/07, Mark Mitchell <[EMAIL PROTECTED]> wrote: > > >> I think it's fair for front ends to pay for their > > >> largesse. There are also relatively cheap changes in the C++ front end > > >> to salvage a few codes, and postpone the day of reckoning. > > > > > > I think that day of reckoning will come very soon again, with more > > > C++0x work, more autovect work, OpenMP 3.0, and the tuples and LTO > > > projects, etc., all requiring more tree codes. > > > > For that matter, does increasing the tree code limit to 512 codes > > instead of 256 actually put off the day of reckoning enough to be worth it? > > I think so. It took us, what, 10 years to go through 256 codes? Even > if we accelerate the pace of development significantly, we'll still > get a few years out of 512 codes. All the while, we should be hunting > to eliminate more of the "common" bits in tree_base (moving them into > more specific substructures, like decl_common), allowing the tree code > to increase in size. When we hit that 16-bit tree code, we'll get a > small bump in performance when all of the masking logic just > disappears. 16 bits is my goal, 9 bits is today's fix. > Cheers, > Doug We've been considering two solutions, the 9 bit codes vs the subcode alternative. The 9 bit solution is considered simpler and without any memory penalty but slows down the compiler and doesn't increase the number of codes very much. The subcodes solution increases memory usage (and possibly also slows down the compiler) and is more complex and changes are more pervasive. A third solution may be to just go to 16 bit tree codes now. Yes there's a memory hit. However if the subcodes solution is preferred by some, but has a memory hit and has added complexity, we may as well just increase the tree code size to 16 bits and take the memory hit there but retain compiler speed and simplicity. We also then remove any worry about the number of tree codes for much longer than the 9 bit solution. Would you please consider testing the 16 bit tree code as you did for 8 vs 9 bits? Perhaps you could also measure memory usage for all three solutions? I think that would give us a complete picture to make an informed decision. Thanks, --Kaveh -- Kaveh R. Ghazi [EMAIL PROTECTED]
Re: We're out of tree codes; now what?
On Tue, Mar 20, 2007 at 08:56:10AM -0400, Kaveh R. GHAZI wrote: > We've been considering two solutions, the 9 bit codes vs the subcode > alternative. > > The 9 bit solution is considered simpler and without any memory penalty > but slows down the compiler and doesn't increase the number of codes very > much. The subcodes solution increases memory usage (and possibly also > slows down the compiler) and is more complex and changes are more > pervasive. But the subcodes approach would be only applied to the less often used codes and ideally within the frontends only. So the memory hit shouldn't be as big as e.g. going to 16 bit tree codes if that means increasing the size of most of the trees the compiler uses. Jakub
Re: We're out of tree codes; now what?
On 3/20/07, Jakub Jelinek <[EMAIL PROTECTED]> wrote: On Tue, Mar 20, 2007 at 08:56:10AM -0400, Kaveh R. GHAZI wrote: > We've been considering two solutions, the 9 bit codes vs the subcode > alternative. > > The 9 bit solution is considered simpler and without any memory penalty > but slows down the compiler and doesn't increase the number of codes very > much. The subcodes solution increases memory usage (and possibly also > slows down the compiler) and is more complex and changes are more > pervasive. But the subcodes approach would be only applied to the less often used codes and ideally within the frontends only. Even if we only use subcodes for the less often used codes, I think we still take the performance hit. The problem is that it's very messy to deal with a two-level code structure inside, e.g., the C++ front end. I did a little experiment with a very rarely used tree code (TYPEOF_TYPE), and the results weren't promising: http://gcc.gnu.org/ml/gcc/2007-03/msg00493.html My conclusion was that, for maintainability reasons, we would need to make the subcode approach look like there are no subcodes, by making a LANG_TREE_CODE used in the front-ends that turns an 8-bit code and optional 8-bit subcode into a 16-bit code. It's doable, but it's going to have a non-trivial cost, certainly. And sooner or later, all of the language-specific nodes will use subcodes, as the middle-end gets a bigger and bigger share of the 256 codes we have. So the memory hit shouldn't be as big as e.g. going to 16 bit tree codes if that means increasing the size of most of the trees the compiler uses. Yes, this is true. Cheers, Doug
Re: We're out of tree codes; now what?
On 3/20/07, Doug Gregor <[EMAIL PROTECTED]> wrote: > So the memory hit shouldn't be > as big as e.g. going to 16 bit tree codes if that means increasing the size > of most of the trees the compiler uses. Yes, this is true. But this could be solved if all LANG_TREE_x bits could move to language specific trees, could it? Gr. Steven
Re: We're out of tree codes; now what?
On 3/20/07, Steven Bosscher <[EMAIL PROTECTED]> wrote: On 3/20/07, Doug Gregor <[EMAIL PROTECTED]> wrote: > > So the memory hit shouldn't be > > as big as e.g. going to 16 bit tree codes if that means increasing the size > > of most of the trees the compiler uses. > > Yes, this is true. But this could be solved if all LANG_TREE_x bits could move to language specific trees, could it? Yes, absolutely. Cheers, Doug
Re: We're out of tree codes; now what?
On 3/20/07, Kaveh R. GHAZI <[EMAIL PROTECTED]> wrote: Would you please consider testing the 16 bit tree code as you did for 8 vs 9 bits? Perhaps you could also measure memory usage for all three solutions? I've measured the 8 vs. 9-bit solutions: they have identical memory footprints. I think that would give us a complete picture to make an informed decision. Sorry, I thought I'd reported these numbers already. Here's a quick summary for tramp3d: 8-bit codes: Total162M100M 1732k 16-bit codes: Total164M108M 1732k Results of -fmem-report on i686-pc-linux-gnu follow. Cheers, Doug 8-bit tree codes (same with 9-bit tree codes): Memory still allocated at the end of the compilation process Size AllocatedUsedOverhead 8 1780k487k 41k 16 2368k705k 37k 64 3384k 2168k 33k 128 1580k180k 13k 256 700k224k 5600 512 364k243k 2912 1024 52k 32k416 2048 116k104k928 4096 36k 36k288 8192 32k 32k128 16384 16k 16k 32 32768480k480k480 65536320k320k160 131072128k128k 32 262144512k512k 64 5227M 10M273k 44 720k194k 7200 104 31M 29M280k 92 1564k899k 13k 8015M 15M141k 88 10196k 5014k 89k 2419M 10M248k 48 1100k480k 10k 284 2676k 2203k 20k 72 1824k980k 16k 28 9504k 2516k111k 112 7664k 7444k 67k 32 8944k 5904k104k 12 7616k571k133k 40 7084k 3039k 76k Total162M100M 1732k String pool entries 153082 identifiers 153082 (100.00%) slots 262144 bytes 3817k (222k overhead) table size 1024k coll/search 0.9452 ins/search 0.2494 avg. entry 25.53 bytes (+/- 51.64) longest entry 493 ??? tree nodes created (No per-node statistics) Type hash: size 65521, 35719 elements, 1.118019 collisions DECL_DEBUG_EXPR hash: size 1021, 0 elements, 1.307168 collisions DECL_VALUE_EXPR hash: size 1021, 0 elements, 0.00 collisions no search statistics [EMAIL PROTECTED] Desktop]$ total: 432961 kB 16-bit tree codes: Memory still allocated at the end of the compilation process Size AllocatedUsedOverhead 8 1748k487k 40k 16 2440k705k 38k 3213M 6664k167k 6422M 15M227k 128 1496k175k 13k 256 708k229k 5664 512 368k237k 2944 1024 48k 31k384 2048 112k104k896 4096 32k 32k256 8192 32k 32k128 16384 16k 16k 32 32768480k480k480 65536320k320k160 131072128k128k 32 262144512k512k 64 44 1936k741k 18k 108 33M 30M297k 96 1644k941k 14k 8418M 16M169k 92 10032k 4540k 88k 52 1888k743k 18k 284 2632k 2197k 20k 72 1748k988k 15k 2822M 12M273k 116 7948k 7711k 69k 36 5896k 2337k 63k 12 7256k571k127k 40 5400k 2375k 58k Total164M108M 1732k String pool entries 153082 identifiers 153082 (100.00%) slots 262144 bytes 3817k (222k overhead) table size 1024k coll/search 0.9452 ins/search 0.2494 avg. entry 25.53 bytes (+/- 51.64) longest entry 493 ??? tree nodes created (No per-node statistics) Type hash: size 65521, 35719 elements, 1.112485 collisions DECL_DEBUG_EXPR hash: size 251, 0 elements, 1.259857 collisions DECL_VALUE_EXPR hash: size 1021, 0 elements, 0.00 collisions no search statistics total: 452701 kB
-fdump-translation-unit output and GPL
Hi, If I make a program that calls by command line the gcc executable with -fdump-translation-unit option and parses the dump output file, does it have to adhere to the GPL license ? If it doesn't have to adhere to the GPL license, how about if my program gets the dump output by a pipe or a socket ? Thanks in advance for your answers, Nick Rolins
Re: -fdump-translation-unit output and GPL
"Nick Rolins" <[EMAIL PROTECTED]> writes: > If I make a program that calls by command line the gcc executable with > -fdump-translation-unit option and parses the dump output file, > does it have to adhere to the GPL license ? > > If it doesn't have to adhere to the GPL license, how about if my > program gets the dump output by a pipe or a socket ? Different people will give you different answers about different situations. There is no clear answer. This mailing list is unfortunately not the right place to ask GPL licensing questions. I would suggest the gnu.misc.discuss newsgroup. Or asking the Free Software Foundation directly. Ian
Re: We're out of tree codes; now what?
On Tue, Mar 20, 2007 at 09:37:38AM -0400, Doug Gregor wrote: > Even if we only use subcodes for the less often used codes, I think we > still take the performance hit. The problem is that it's very messy to I'm sure smaller hit than when going to 9 bit tree code, and on i386/x86_64 maybe even than 16 bit tree code (if I remember well, 8-bit and 32-bit accesses are usually faster than 16-bit ones). > deal with a two-level code structure inside, e.g., the C++ front end. > I did a little experiment with a very rarely used tree code > (TYPEOF_TYPE), and the results weren't promising: > > http://gcc.gnu.org/ml/gcc/2007-03/msg00493.html If you use what has been suggested, i.e.: #define LANG_TREE_CODE(NODE) (TREE_CODE (NODE) == LANG_CODE ? ((tree_with_subcode *)(NODE))->subcode : TREE_CODE (NODE)) then it shouldn't be so big. Everywhere where you don't need >= 256 codes you'd just keep using TREE_CODE, only if e.g. some switch contains >= 256 FE specific subcodes you'd use LANG_TREE_CODE instead of TREE_CODE. GCC would warn you if you forget to use LANG_TREE_CODE even when it is needed, at least in switches, you'd get warning: case label value exceeds maximum value for type Jakub
Re: SoC Project: Incremental Parsing (of C++)
"Simon Brenner" <[EMAIL PROTECTED]> writes: > I propose to implement incremental parsing in C++ (through hand-waving, C++ > has > been decided to be the language most in need of incremental parsing), similar > to > the approach in article [1]. Basically, a diff algorithm is run on the > character > or token stream, producing a list of insertions, modifications, and deletions, > and this list of changed characters/tokens is compared to the previous parse > tree to decide what parts of the tree need reparsing and recompilation. > > In this project, I wouldn't even try to attack incremental code generation, > but > just run the entire middle/back end on an updated tree. A future extension > would be to use the information about which trees have changed to perform > minimal code generation. This approach obviously limits the improvement in > compile time, and an important initial part of the project would be to measure > the time spent in lexing, parsing and everything after parsing to see what the > potential gain would be. Another approach I've considered is to skip parsing functions until they are needed. Since the parser dominates the -O0 compilation time, and since large C++ projects have hundreds of inline functions which are never needed by any particular compilation, I think there could be a big -O0 benefit from only parsing functions as needed. My main comment on your approach is that storing the tree representation in an object file is nontrivial. However, you may be able to take advantage of the partially implemented LTO work. Either way it sounds like an interesting and useful project. Ian
Re: We're out of tree codes; now what?
On Mon, Mar 19, 2007 at 08:16:42PM -0700, Mark Mitchell wrote: > Nicholas Nethercote wrote: > > > As for what is best to do, I don't know. But I do know that complexity > > is bad, and that GCC is very complex. You are absolutely right about > > there being hard limits. There are trade-offs required. Whether the > > current and ongoing trade-offs are the right ones is an open question. > > I do think compilation speed -- and memory use -- is important. > However, I do also think that it's reasonable to measure compilation > speed against workstation speed. Compiling GCC takes me a lot less time > than it did even a few years ago because I have much faster computers. But the problem is that those days are over. Before 2003, there was a magic number, alpha, that you could vary and it would tell you how to make a new version of your chip from three years ago that would be better in all respects: faster, smaller, lower-power, cheaper. Around 2003, the curves all shifted, because the traditional CMOS scaling formula can no longer be used: atoms don't scale. Once the gate oxide layers get down to a few atoms thick, they leak, and power soars enormously, even when the gate is not switching. Chip designers and EDA companies have gone to heroic extremes to compensate for these effects, and Moore's Law is still alive and kicking. But everything has changed. Processor vendors are compensating for this by giving up on increasing the clock frequency. Instead, they've gone for dual core, then four cores, and the roadmaps show plans for dozens of cores, but the clock frequency isn't going to be higher than it is now. But programmers that have grown up with the way things have been for the last 30 years have gotten spoiled. If your program is bloated and inefficient, no matter; wait a year, and it will get faster all on its own. If you want to be a working programmer in ten years, you need to start thinking about parallel programming. For necessarily-serial programs, there is less room than ever to be sloppy, because you won't recover any speed that you lose.
Re: We're out of tree codes; now what?
Joe Buck wrote: > If you want to be a working programmer in ten years, you need to start > thinking about parallel programming. Yes, I'm well aware of the technology roadmaps for CPUs. But, I don't think that's got a big impact here; the parallelism is also going to apply to the software build process, whether via "make -j" parallelism, threading in the compiler, etc. (I fully expect that -- without change -- the traditional GCC build process, using parallel make, will become bound mostly by the serial nature of the configure scripts, rather by the actual compilation of the compiler and runtime libraries.) So, I still believe that I'll be able to build GCC 5.0 (on hardware available at that point) in less time than it took to build GCC 3.4 (on hardware available at that point). -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: We're out of tree codes; now what?
Jakub Jelinek wrote: On Tue, Mar 20, 2007 at 09:37:38AM -0400, Doug Gregor wrote: Even if we only use subcodes for the less often used codes, I think we still take the performance hit. The problem is that it's very messy to I'm sure smaller hit than when going to 9 bit tree code, and on i386/x86_64 maybe even than 16 bit tree code (if I remember well, 8-bit and 32-bit accesses are usually faster than 16-bit ones). deal with a two-level code structure inside, e.g., the C++ front end. I did a little experiment with a very rarely used tree code (TYPEOF_TYPE), and the results weren't promising: http://gcc.gnu.org/ml/gcc/2007-03/msg00493.html If you use what has been suggested, i.e.: #define LANG_TREE_CODE(NODE) (TREE_CODE (NODE) == LANG_CODE ? ((tree_with_subcode *)(NODE))->subcode : TREE_CODE (NODE)) This subcode idea feels like a bug attractor to me. For example: #defines have enough problems with side effects, and this references NODE twice, so what happens when NODE is a function of some kind, or has other side effects? (Someone is going to try to be clever) then it shouldn't be so big. Everywhere where you don't need >= 256 codes you'd just keep using TREE_CODE, only if e.g. some Wouldn't this require extra effort to know when you should use one method of retrieving the code, verses the other. Seems like a lot of remembering would be necessary, which would be a good source of bugs. And having two different methods of getting the "same thing" would make searching the source code for patterns that much harder. switch contains >= 256 FE specific subcodes you'd use LANG_TREE_CODE instead of TREE_CODE. GCC would warn you if you forget to use LANG_TREE_CODE even when it is needed, at least in switches, you'd get warning: case label value exceeds maximum value for type I'd expect that the TREE_CODE would be referenced more often in comparisons, than in switch statements. These probably wouldn't generate the warning.
Re: -fdump-translation-unit output and GPL
> Different people will give you different answers about different > situations. There is no clear answer. This mailing list is > unfortunately not the right place to ask GPL licensing questions. > > I would suggest the gnu.misc.discuss newsgroup. Or asking the Free > Software Foundation directly. My understanding is that the FSF does not answer such questions, basically saying "do it and we'll see what we think and if we think it infringes our copyright, we'll let you know". The bottom line on legal issues such as this is that if somebody wants legal advise, they should consult an attorney, not a mailing list or newsgroup. Patent law as it relates to computer programs can be very complicated and not intuitive.
Re: We're out of tree codes; now what?
On Tue, Mar 20, 2007 at 11:04:16AM -0600, Kevin Handy wrote:
> >#define LANG_TREE_CODE(NODE) (TREE_CODE (NODE) == LANG_CODE ?
> >((tree_with_subcode *)(NODE))->subcode : TREE_CODE (NODE))
> >
> This subcode idea feels like a bug attractor to me.
>
> For example: #defines have enough problems with
> side effects, and this references NODE twice, so
> what happens when NODE is a function of some
> kind, or has other side effects?
Just look quickly at tree.h, there are plenty of other macros already
that evaluate their arguments multiple times.
> >switch contains >= 256 FE specific subcodes you'd use LANG_TREE_CODE
> >instead of TREE_CODE. GCC would warn you if you forget to use
> >LANG_TREE_CODE even when it is needed, at least in switches, you'd get
> >warning: case label value exceeds maximum value for type
> >
> I'd expect that the TREE_CODE would be referenced
> more often in comparisons, than in switch statements.
> These probably wouldn't generate the warning.
That warns too, see (-Wall):
enum foo
{
A=0,
B=1,
C=2,
X=254,
Y=255
};
struct tree
{
enum foo code : 8;
};
extern void bar (void);
void foo (struct tree *t)
{
switch (t->code)
{
case C:
break;
case 512:
bar ();
break;
case 1081:
break;
}
if (t->code == 1024)
bar ();
if (t->code != 1035)
bar ();
}
Jakub
Re: Listing file-scope variables inside a pass
On 3/20/07, Dave Korn <[EMAIL PROTECTED]> wrote: On 19 March 2007 22:16, Karthikeyan M wrote: > What should I do if I want a list of all file-scope variables inside > my own pass ? > > The file_scope variable is local to c-decl.c . Is there a reason why > the scope holding variables are local to c-decl.c ? Because we want to keep front-, mid- and back- ends of the compiler as modular and non-interdependent as possible, perhaps? If you need a routine to dump that data, why not write it in c-decl.c and just expose the prototype in a suitable header file (c-tree.h)? He already can get the file-scope variables by going through the cgraph variable nodes.
Re: We're out of tree codes; now what?
On 20/03/07, Jakub Jelinek <[EMAIL PROTECTED]> wrote: On Tue, Mar 20, 2007 at 11:04:16AM -0600, Kevin Handy wrote: > >#define LANG_TREE_CODE(NODE) (TREE_CODE (NODE) == LANG_CODE ? > >((tree_with_subcode *)(NODE))->subcode : TREE_CODE (NODE)) > > > This subcode idea feels like a bug attractor to me. > > For example: #defines have enough problems with > side effects, and this references NODE twice, so > what happens when NODE is a function of some > kind, or has other side effects? Just look quickly at tree.h, there are plenty of other macros already that evaluate their arguments multiple times. > >switch contains >= 256 FE specific subcodes you'd use LANG_TREE_CODE > >instead of TREE_CODE. GCC would warn you if you forget to use > >LANG_TREE_CODE even when it is needed, at least in switches, you'd get > >warning: case label value exceeds maximum value for type > > > I'd expect that the TREE_CODE would be referenced > more often in comparisons, than in switch statements. > These probably wouldn't generate the warning. That warns too, see (-Wall): Just to be precise, that warning is not in Wall, it is enabled by default and there have been continous requests to assign it a switch (so it can be disabled) and move it to -Wextra. Unreviewed patch available here: http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00207.html Cheers, Manuel.
Re: We're out of tree codes; now what?
"Doug Gregor" <[EMAIL PROTECTED]> writes: > On 3/20/07, Kaveh R. GHAZI <[EMAIL PROTECTED]> wrote: > > Would you please consider testing the 16 bit tree code as you did for 8 vs > > 9 bits? Perhaps you could also measure memory usage for all three > > solutions? > > I've measured the 8 vs. 9-bit solutions: they have identical memory footprints. > > > I think that would give us a complete picture to make an > > informed decision. > > Sorry, I thought I'd reported these numbers already. Here's a quick > summary for tramp3d: > > 8-bit codes: Total162M100M 1732k > 16-bit codes: Total164M108M 1732k Unfortunately these stats do not reflect the actual memory use, this is the memory that is still in use when the compilation process is done. What you want is to compile gcc with --enable-gather-detailed-mem-stats and then -fmem-report will give you memory usage for all tree types. > Results of -fmem-report on i686-pc-linux-gnu follow. > > Cheers, > Doug > > 8-bit tree codes (same with 9-bit tree codes): > > Memory still allocated at the end of the compilation process ^^ I think we should add an extra line of text here that states that for detailed memory used info --enable-gather-detailed-mem-stats needs to be used. Should I send a patch?
Re: We're out of tree codes; now what?
On 3/20/07, Dan Nicolaescu <[EMAIL PROTECTED]> wrote: "Doug Gregor" <[EMAIL PROTECTED]> writes: > On 3/20/07, Kaveh R. GHAZI <[EMAIL PROTECTED]> wrote: > > Would you please consider testing the 16 bit tree code as you did for 8 vs > > 9 bits? Perhaps you could also measure memory usage for all three > > solutions? > > I've measured the 8 vs. 9-bit solutions: they have identical memory footprints. > > > I think that would give us a complete picture to make an > > informed decision. > > Sorry, I thought I'd reported these numbers already. Here's a quick > summary for tramp3d: > > 8-bit codes: Total162M100M 1732k > 16-bit codes: Total164M108M 1732k Unfortunately these stats do not reflect the actual memory use, this is the memory that is still in use when the compilation process is done. What you want is to compile gcc with --enable-gather-detailed-mem-stats and then -fmem-report will give you memory usage for all tree types. I don't have time to do this right now, but as part of these tests I used the little tool on the tramp3d page to determine the maximum total virtual memory usage. It's not the complete information we want, but it shows us a little more of the picture: 8-bit codes: total: 432961 kB 16-bit codes: total: 452701 kB Cheers, Doug
Re: Listing file-scope variables inside a pass
Thanks. Where exactly should I be looking? Will the cgraph nodes also have global declarations that are never used inside any function . On 3/20/07, Daniel Berlin <[EMAIL PROTECTED]> wrote: On 3/20/07, Dave Korn <[EMAIL PROTECTED]> wrote: > On 19 March 2007 22:16, Karthikeyan M wrote: > > > What should I do if I want a list of all file-scope variables inside > > my own pass ? > > > > The file_scope variable is local to c-decl.c . Is there a reason why > > the scope holding variables are local to c-decl.c ? > > Because we want to keep front-, mid- and back- ends of the compiler as > modular and non-interdependent as possible, perhaps? > > If you need a routine to dump that data, why not write it in c-decl.c and > just expose the prototype in a suitable header file (c-tree.h)? > He already can get the file-scope variables by going through the cgraph variable nodes. -- Karthik To laugh often and love much; to win the respect of intelligent persons and the affection of children; to earn the approbation of honest critics; to appreciate beauty; to give of one's self; to leave the world a bit better, whether by a healthy child, a garden patch or a redeemed social condition; to have played and laughed with enthusiasm and sung with exultation; to know even one life has breathed easier because you have lived--that is to have succeeded. --Ralph Waldo Emerson
Re: SoC Project: Incremental Parsing (of C++)
Ian Lance Taylor <[EMAIL PROTECTED]> writes: | "Simon Brenner" <[EMAIL PROTECTED]> writes: | | > I propose to implement incremental parsing in C++ (through hand-waving, C++ has | > been decided to be the language most in need of incremental parsing), similar to | > the approach in article [1]. Basically, a diff algorithm is run on the character | > or token stream, producing a list of insertions, modifications, and deletions, | > and this list of changed characters/tokens is compared to the previous parse | > tree to decide what parts of the tree need reparsing and recompilation. | > | > In this project, I wouldn't even try to attack incremental code generation, but | > just run the entire middle/back end on an updated tree. A future extension | > would be to use the information about which trees have changed to perform | > minimal code generation. This approach obviously limits the improvement in | > compile time, and an important initial part of the project would be to measure | > the time spent in lexing, parsing and everything after parsing to see what the | > potential gain would be. | | Another approach I've considered is to skip parsing functions until | they are needed. Since the parser dominates the -O0 compilation time, | and since large C++ projects have hundreds of inline functions which | are never needed by any particular compilation, I think there could be | a big -O0 benefit from only parsing functions as needed. That defered parsing might work with C (I don't really know), but it certainly is problematic with C++ because there are bindings that need to be in overload sets, and you cannot accurately capture those if you don't parse the function bodies. Sadly. Of course, if you know in advance that your programs don't fall in that category (run the compiler twice), then you can use the deferred parsing strategy. -- Gaby
Re: SoC Project: Incremental Parsing (of C++)
Gabriel Dos Reis <[EMAIL PROTECTED]> writes: > | Another approach I've considered is to skip parsing functions until > | they are needed. Since the parser dominates the -O0 compilation time, > | and since large C++ projects have hundreds of inline functions which > | are never needed by any particular compilation, I think there could be > | a big -O0 benefit from only parsing functions as needed. > > That defered parsing might work with C (I don't really know), but it > certainly is problematic with C++ because there are bindings that > need to be in overload sets, and you cannot accurately capture those if > you don't parse the function bodies. Sadly. You do clearly need to parse the function declarations--the name and the parameters--but do you really need to parse the function bodies themselves? If so, then my idea would certainly fail. Ian
Re: SoC Project: Incremental Parsing (of C++)
On 20 Mar 2007 17:04:56 -0500, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote: That defered parsing might work with C (I don't really know), but it certainly is problematic with C++ because there are bindings that need to be in overload sets, and you cannot accurately capture those if you don't parse the function bodies. Sadly. What if you were able to "roll back" name lookup, so that it was able to resolve names as if it were at an earlier point in the translation unit? If one were to, say, annotate declarations with their position in the translation unit (line and column number, in the trivial case), and then modify name lookup so that we could say, "find the name foo as if we were looking from line number 50, column 3," it might be possible to parse function bodies later on. It seems feasible in principle; making it work is an entirely different matter. Cheers, Doug
Re: SoC Project: Incremental Parsing (of C++)
"Doug Gregor" <[EMAIL PROTECTED]> writes: > On 20 Mar 2007 17:04:56 -0500, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote: > > That defered parsing might work with C (I don't really know), but it > > certainly is problematic with C++ because there are bindings that > > need to be in overload sets, and you cannot accurately capture those if > > you don't parse the function bodies. Sadly. > > What if you were able to "roll back" name lookup, so that it was able > to resolve names as if it were at an earlier point in the translation > unit? If one were to, say, annotate declarations with their position > in the translation unit (line and column number, in the trivial case), > and then modify name lookup so that we could say, "find the name foo > as if we were looking from line number 50, column 3," it might be > possible to parse function bodies later on. OK, now I get it. I believe that would be a desirable feature anyhow, because I believe it would make name lookups more efficient (and thus perhaps obviate the whole issue). But it is clearly nontrivial. Ian
GCC priorities [Was Re: We're out of tree codes; now what?]
On Tue, 20 Mar 2007, Nicholas Nethercote wrote: GCC is a very ambitious compiler: - it supports a lot of platforms - it supports a lot of languages However, most users do not use most of those combinations. The problem is that supporting all these combinations hurts the specific combinations. Nobody responded to this particular point, which surprised me. I looked up the GCC mission statement (http://gcc.gnu.org/gccmission.html). It has the following "Design and Development Goals" * New languages * New optimizations * New targets * Improved runtime libraries * Faster debug cycle * Various other infrastructure improvements I think they're terrible: - "New languages" -- why? Just because you can? In theory, adding a new language can be free, but in practice it never is. - "New optimizations?" I assume this means "optimization passes". Users don't care about optimization passes. Users care about performance. Optimizations happen to be the main way to achieve that, but substituting the mechanism for the end goal in a mission statement sends the wrong message. - "New targets" -- this one is better, but some qualification would help. I understand that the goal is for GCC to be the universally available compiler, but it could be clarified that it's targets that are desired by users. - They're vague -- "improved runtime libraries"? "various other infrastructure improvements"? These phrases are meaningless. Why not just write "a really awesome compiler"? - There's no notion that you can't have everything. For something to be a high priority, you have to make something else a lower priority. This list is just "faster! better! more!" In particular, to return to the original point of this thread, the "faster debug cycle" has been suffering horribly (due to compile-time performance regressions). - They haven't been updated since 1999-04-22. Here are some suggestions for more suitable priorities. They're all characteristics, rather than features. They're far from perfect, but I think they're better than the goals above. I haven't put them in any particular order. - Correctness w.r.t. language definitions (ie. accept correct code, reject incorrect code) - Correctness of the compiler (ie. no compiler crashes) - Correctness of generated code (ie. compiled code should do the right thing) - Performance of the compiler (time and memory) - Performance of generated code (time and memory) - Performance of building the compiler (time and memory) - Support of existing language extensions - Addition of new language extensions - Support of existing languages: C, C++, Objective C, Fortran, Ada, Java (and any others I've missed) - Support of new languages - Support of existing platforms (a.k.a. portability) - Support of new platforms (a.k.a. portability) - Design and code complexity - Maintainability - Debugging support (eg. generating correct debugging info) - Profiling support - Quality of error messages (eg. uninitialized variables) - Support for other extensions (eg. mudflap) You can split these up or qualify them more, eg. for "performance of the compiler" you might distinguish between -O0 and -O2. The key idea is that you can't have all of these. For example, supporting many languages and platforms increases complexity, adds more code (which slows down build times), and can hurt performance (as the tree codes example has shown). It also takes resources that then are not used for improving other aspects. Another example: there was a suggested SoC project yesterday for an incremental C++ parser. That could speed up compile-time performance in some cases, but at the cost of increased design and code complexity. This idea is simple, and I'm sure many of you understand it individually. But it appears to me, as an observer of GCC development, that GCC developers as a group don't understand this. On Mon, 19 Mar 2007, Doug Gregor wrote: We have hit a hard limit in the design of GCC. We need to either use more memory, use more compilation time, re-architect non-trivial portions of GCC, remove functionality, or come up with something very, very clever. Pick one, but if the pick the last one, you have to specify what "something very, very clever" is, because we seem to be running short on ideas. Doug was talking about the tree code issue, but this paragraph sums up the whole situation perfectly. Sometimes it's a good idea to stand back and look at the bigger picture, rather than just running on the "gotta fix another bug, gotta add another feature" treadmill. Nick
Re: Listing file-scope variables inside a pass
On 3/20/07, Karthikeyan M <[EMAIL PROTECTED]> wrote: Thanks. Where exactly should I be looking? cgraph.c, cgraphunit.c, cgraph.h see cgraph_varpool_nodes, FOR_EACH_STATIC_VARIABLE (static here means having scope greater than a single function, it does not mean "all variables declared static in C") Will the cgraph nodes also have global declarations that are never used inside any function . If you ask for all of them, it will give you all of them If you ask for only the needed ones, it will give you all of the needed ones (see FOR_EACH_STATIC_VARIABLE) On 3/20/07, Daniel Berlin <[EMAIL PROTECTED]> wrote: > On 3/20/07, Dave Korn <[EMAIL PROTECTED]> wrote: > > On 19 March 2007 22:16, Karthikeyan M wrote: > > > > > What should I do if I want a list of all file-scope variables inside > > > my own pass ? > > > > > > The file_scope variable is local to c-decl.c . Is there a reason why > > > the scope holding variables are local to c-decl.c ? > > > > Because we want to keep front-, mid- and back- ends of the compiler as > > modular and non-interdependent as possible, perhaps? > > > > If you need a routine to dump that data, why not write it in c-decl.c and > > just expose the prototype in a suitable header file (c-tree.h)? > > > He already can get the file-scope variables by going through the > cgraph variable nodes. > -- Karthik To laugh often and love much; to win the respect of intelligent persons and the affection of children; to earn the approbation of honest critics; to appreciate beauty; to give of one's self; to leave the world a bit better, whether by a healthy child, a garden patch or a redeemed social condition; to have played and laughed with enthusiasm and sung with exultation; to know even one life has breathed easier because you have lived--that is to have succeeded. --Ralph Waldo Emerson
Re: Listing file-scope variables inside a pass
Are these macros not a part of 4.1.2 ? I just picked up the tarball of the 4.1.2-core source. Which release has this code ? Thanks a lot. On 3/20/07, Daniel Berlin <[EMAIL PROTECTED]> wrote: On 3/20/07, Karthikeyan M <[EMAIL PROTECTED]> wrote: > Thanks. > Where exactly should I be looking? cgraph.c, cgraphunit.c, cgraph.h see cgraph_varpool_nodes, FOR_EACH_STATIC_VARIABLE (static here means having scope greater than a single function, it does not mean "all variables declared static in C") > Will the cgraph nodes also have global declarations that are never > used inside any > function . If you ask for all of them, it will give you all of them If you ask for only the needed ones, it will give you all of the needed ones (see FOR_EACH_STATIC_VARIABLE) > > On 3/20/07, Daniel Berlin <[EMAIL PROTECTED]> wrote: > > On 3/20/07, Dave Korn <[EMAIL PROTECTED]> wrote: > > > On 19 March 2007 22:16, Karthikeyan M wrote: > > > > > > > What should I do if I want a list of all file-scope variables inside > > > > my own pass ? > > > > > > > > The file_scope variable is local to c-decl.c . Is there a reason why > > > > the scope holding variables are local to c-decl.c ? > > > > > > Because we want to keep front-, mid- and back- ends of the compiler as > > > modular and non-interdependent as possible, perhaps? > > > > > > If you need a routine to dump that data, why not write it in c-decl.c and > > > just expose the prototype in a suitable header file (c-tree.h)? > > > > > He already can get the file-scope variables by going through the > > cgraph variable nodes. > > > > > -- > > Karthik > > > To laugh often and love much; to win the respect of intelligent > persons and the affection of children; to earn the approbation of > honest critics; to appreciate beauty; to give of one's self; to leave > the world a bit better, whether by a healthy child, a garden patch or > a redeemed social condition; to have played and laughed with > enthusiasm and sung with exultation; to know even one life has > breathed easier because you have lived--that is to have succeeded. > --Ralph Waldo Emerson > > -- Karthik To laugh often and love much; to win the respect of intelligent persons and the affection of children; to earn the approbation of honest critics; to appreciate beauty; to give of one's self; to leave the world a bit better, whether by a healthy child, a garden patch or a redeemed social condition; to have played and laughed with enthusiasm and sung with exultation; to know even one life has breathed easier because you have lived--that is to have succeeded. --Ralph Waldo Emerson
Re: SoC Project: Incremental Parsing (of C++)
On Mar 20, 2007, at 1:07 AM, Simon Brenner wrote: I propose to implement incremental parsing in C++ Sounds like a multi-person, multi-year project. We did something like this a while ago, called the compile server. The idea was to be able to advance through unchanged portions of code and replay the changes to compile state so as to reduce compilation time for code in which we've already seen before, either because we're compiling mostly the same source, or using a header file more than once. It included fine grained dependancy tracking for things like macros and declarations. It could also replay state for fragments across translation units as well. You can view it at branches/compile-server-branch. Basically, a diff algorithm is run on the character or token stream, We ran it at the character level. producing a list of insertions, modifications, and deletions, We only had two states, unchanged or changed region. Unchanged replayed the state, changed meant compile just that region as normal. The idea was that people usually only edit a small number of regions. A region was defined as the lines between # lines in the cpp output. In this project, I wouldn't even try to attack incremental code generation, but just run the entire middle/back end on an updated tree. We were able to do incremental code-gen as well. A future extension would be to use the information about which trees have changed to perform minimal code generation. This approach obviously limits the improvement in compile time, and an important initial part of the project would be to measure the time spent in lexing, parsing and everything after parsing to see what the potential gain would be. We saw a 41% speed-up for SimpleText, a 110x peak speedup for and (cstdlib). A C++ Carbon hello world was 91x faster, peak. C hello world was the same speed. Peak speedups for C 2x, for C++ 142x. My implementation would store the tree representation and the token stream from a source file in the object file We kept everything in core. For starters, I would only consider top-level constructs (i.e. if any token in a function, type or global-scope variable has changed, the entire declaration/ definition would be reparsed), We handled this case by gluing together regions until the start and end of a region was at the toplevel. A number of changes in source affect more than the tree of the construct itself (inline functions, function default values, templates etc.. see Problems below). In these cases, the initial implementation would just identify the dangerousness of the changes, abort, and initiate a complete recompilation of the file. We validated state on a fine grained basis. Such checking can be expensive, as odd as that sounds. Would it be feasible to construct a dependency map of the tree, to handle these cases with minimal recompilation? How large would such a dependency map have to be? We never progressed the project far enough to scale into the, push 1000 projects through the server stage, so we never had to worry about page faulting and running out of ram, though, there was a concern that in an already tight 32-bit vm space, the server could run out of ram and/or vm. To work well, one would have to check every unique identifier used to ensure that it was not #defined. I wanted a language extension to make the guarantee for me so that I would not have to check them all. For checking, the initial implementation should also provide for a way to compare the result of the incremental reparse against a complete recompilation. We handled this case by comparing the .s files compiled with the server against one without. Some of the information that is saved and updated in the aux file or object file is probably the same as what is saved in a GCH file. :-) We selected an in core database so avoid all the issues associated. Would incremental update of GCH files be possible/interesting? Nice question. In software almost anything is possible. Harder to know if it is useful. Should this all be integrated into the precompiled header framework? Nice question. * Changing a declaration (function arguments, default values), also affects all uses of the same declaration. We did this by the fine grained dependancy tracking. * Adding and removing a template specialization changes all uses of the template after the declaration. I don't think we handled this case. * If code inside an inlined function body is changed, all (inlined) uses of the function also change. We did this by the fine grained dependancy tracking. * What other cases like these have not yet been considered? There are about 1000 more cases like that. I can begin listing them if you want. :-) Overload sets, RTX constant pools, debugging information, exception tables, deprecation and NODE_POISONED, IDENTIFIER_TYPENAME_P
Re: Listing file-scope variables inside a pass
On Mar 20, 2007, at 4:39 PM, Karthikeyan M wrote: Are these macros not a part of 4.1.2 ? 4.1.2, what's that?! :-) I just picked up the tarball of the 4.1.2-core source. Pick something that says 2007 and 4.3... :-) In general, new work is best done against the top of the tree, that is the context in which we want to help you.
Re: SoC Project: Incremental Parsing (of C++)
Wow, lots of comments there, Mike ;-) We saw a 41% speed-up for SimpleText, a 110x peak speedup for and (cstdlib). A C++ Carbon hello world was 91x faster, peak. C hello world was the same speed. Peak speedups for C 2x, for C++ 142x. Cool! After some measurements (-ftime-report, tee, grep, cut and perl) on a C++ codebase (about 200kloc, ~341 files), it seems that about 50% of compilation time is spent in the parser, which limits the possible speed-up of my approach to about 2x. Which wouldn't be small, but still nothing compared to those numbers. Additionally, about 17% is spent in "name lookup" (I'm not sure here what kinds of name lookups are actually measured, and how much of it that would be eliminated by parsing incrementally), and 13% in preprocessing (this time wouldn't change at all). > A number of changes in source affect more than the tree of the > construct itself > (inline functions, function default values, templates etc.. see > Problems below). > In these cases, the initial implementation would just identify the > dangerousness > of the changes, abort, and initiate a complete recompilation of the > file. We validated state on a fine grained basis. Such checking can be expensive, as odd as that sounds. My idea was to initially just check for any not obviously safe changes, and later in the project try to determine the most important kind of changes to handle intelligently. That is, a change would be considered dangerous until proven safe. But I guess I might find that almost nothing at all can be done without that fine-grained checking. Would it be possible to calculate the dependencies from the tree of a function? If so, the parser could go through all unchanged trees in their file order and check for a Changed flag in the declarations referred to, recompiling the tree and marking it as changed if any of its dependents were changed. This wouldn't properly handle all cases though... A reference to a function could be annotated with the overload set and any function added/deleted/changed could mark its overload set as changed, but that is probably only one of a load of cases. (More research certainly needed.) We never progressed the project far enough to scale into the, push 1000 projects through the server stage, so we never had to worry about page faulting and running out of ram, though, there was a concern that in an already tight 32-bit vm space, the server could run out of ram and/or vm. Hmm.. Well, this would only be within one compilation unit, but still I guess you could have a pathological file with 2^16 templates, all interdependent, in which case you'd have 2^32 dependency links, and quickly overflow most limits. Before letting this thing loose on users, there should be code to detect such a case and restart a normal compilation. But my priority would be to get the internal stuff working, not being nice to users. In the worst case, you'd just keep on going naively, crash, and let the build script retry a non-incremental compile. To work well, one would have to check every unique identifier used to ensure that it was not #defined. I wanted a language extension to make the guarantee for me so that I would not have to check them all. That specific problem would be taken care of by working on already preprocessed data. But the problem is similar to that of overloaded functions which would need to be considered. > For checking, the initial implementation should also provide for a > way to > compare the result of the incremental reparse against a complete > recompilation. We handled this case by comparing the .s files compiled with the server against one without. Nice and simple! No need to compare trees then. There are about 1000 more cases like that. I can begin listing them if you want. :-) Overload sets, RTX constant pools, debugging information, exception tables, deprecation and NODE_POISONED, IDENTIFIER_TYPENAME_P... Which of these are only of importance when doing code generation? > * How much space does a serialized token stream take? gcc -E *.c | wc -c will tell you an approximate number. You then just * by a constant. I wouldn't worry about it. > * How much time is actually spent in the parser? Seems like if you do a good job, you should be able to get a 100-200x speedup, though, you're gonna have to do code-gen to get it. > * Future: Incremental code generation I didn't find this part very hard to do. Harder was going to get perfect fidelity across all the language features and get enough people interested in the project to get it into mainline. How good did you manage to get the compile server in terms of fidelity? I'm happy to forego the extra gains (although significant) for now, in exchange for fidelity, i.e. start with "100%" correct code generation without incrementality and then try to add more incrementality while keeping it "100%" correct, where "100%" is where the rest of the compiler is at. Trying to do all these
Adding Profiling support - GCC 4.1.1
Hi all, I need to implement profiling support for my backend (GCC 4.1.1). There is only limited information in GCC Internals to define the following macros (FUNCTION_PROFILER, PROFILE_HOOK ,NO_PROFILE_COUNTERS & PROFILE_BEFORE_PROLOGUE) to add profiling support. I need to know the following details: 1. The function mcount: While building with native gcc, the mcount function is defined in glibc. Is the same mcount function available in newlib? or is it that we have to define it in our back-end as SPARC does (gmon-sol2.c). 2. Is it possible to reuse the existing mcount definition or is it customized for every backend? 3. Any other existing back-ends that support profiling. Thanks in advance. Regards, Rohit
Re: -fdump-translation-unit output and GPL
On Mar 20, 2007, [EMAIL PROTECTED] (Richard Kenner) wrote: > infringes our copyright > Patent law Please be careful to not spread the confusion that already exists between these unrelated laws. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}
Re: We're out of tree codes; now what?
On Mar 20, 2007, Mark Mitchell <[EMAIL PROTECTED]> wrote: > (I fully expect that -- without change -- the traditional GCC build > process, using parallel make, will become bound mostly by the serial > nature of the configure scripts, rather by the actual compilation of the > compiler and runtime libraries.) /me mumbles something about LTO and threads. As for configure scripts... autoconf -j is long overdue ;-) -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}
register reload problem in global register allocation
I have some problems in global register allocation phase. I have described some simple architecture using machine description and target macro file. I use gnu GCC version 4.1.1. But, "can't combine" message is printed out in *.c.37.greg file in global register allocation phase. After i have traced the error message, i have found out the message reload_as_needed. But, I do not recognize the reason about this problem. I really can't know the relationship between register reload and my description.
