Re: [bug] undefined symbols with -Woverloaded-virtual and -fprofile-arcs -ftest-coverage
Lothar Werzinger wrote: Joe Buck wrote: Sounds like it. I suggest that you file a bug report, with a complete testcase, so that it can be fixed. AFAIK the proposed way to file a bug is to preprocess the file that fails and to attach the preprocessed file to the bug. That's the usual way in most circumstances, yes. The general principle is to simplify the testcase by removing any unnecessary complications; usually, a specific instance of that principle is to remove the preprocessing step as an unnecessary complication. As described earlier the bug vanishes if I do that. Thus I have no idea how to provide you gcc folks with a testcase. I'd appreciate any input how to create such a testcase. In your case, that specific instance of the general principle does not apply, so you would include the include the non-preprocessed source. The trick, of course, is including _all_ of the relevant source, including all the included header files. First thing I'd do is try chopping the source file down into smaller and smaller bits, by iterating "if I remove this half, does the problem stay or go away?" until you've got the smallest file you can get that still exhibits the problem. Then repeat with the included files; try to remove as many of those as you can. After that, put the remaining ones in the same directory, and repeat the process on those. Ideally, the end result will be a small pile of files that you can zip up and attach to the bug report. If that sounds like too much work, an alternative is arranging things in the same directory such that you've got a large self-contained pile of files that exhibit the problem, and posting a bug report with just the information you posted here and a short description of the files, and asking for a volunteer that you can send the files to who'll do the reduction. People have been willing to do that in the past, for complicated bugs like this. At least, that would be my advice; others may have differing advice, or suggestions more specific to this particular situation. Hope this helps, - Brooks
Re: [bug] undefined symbols with -Woverloaded-virtual and -fprofile-arcs -ftest-coverage
Joe Buck wrote: > On Wed, Jun 06, 2007 at 11:13:16AM -0700, Lothar Werzinger wrote: >> when I build a coverage build of my software I get some undefined symbols >> like global constructors keyed to src_utility_Tree.cpp_90B986A5_564B8955 >> >> I did some investigation and as you can see in the below test it only >> occurs if I specify -Woverloaded-virtual. >> >> What is strange, too is that if I save the preprocessed file (created >> with the -E flag) the undefined symbol does NOT show up even if I >> use -Woverloaded-virtual >> >> I think this is a bug in g++ > > Sounds like it. I suggest that you file a bug report, with a complete > testcase, so that it can be fixed. AFAIK the proposed way to file a bug is to preprocess the file that fails and to attach the preprocessed file to the bug. As described earlier the bug vanishes if I do that. Thus I have no idea how to provide you gcc folks with a testcase. I'd appreciate any input how to create such a testcase. Lothar
Re: Fixed-point branch?
Fu, Chao-Ying wrote: > Right now, the fixed-point support is a configure-time option. > Each target can decide to support it or not. I think there is no > harm to enable for every target. But, each target needs to modify > tm.h tm.c tm-modes.def to set or change some target macros. I would suggest making it a configure-time option, and eliminating the target hook. Then, people can turn it on when they want. If they try to turn it on for a target that doesn't have the necessary support, the compiler will break, and they can fix it. > It's hard to pick up a name. Maybe we will change it to > the following as Nigel suggested. > > /* Conversions involving fractional fixed point types without >saturation, including: > fractional to fractional (of different precision), > signed integer to fractional, > fractional to signed integer, > floating point to fractional, > fractional to floating point. */ > DEF_RTL_EXPR(FRACT_CONVERT, "fract_convert", "e", RTX_UNARY) Yes, I think that's better. Thanks! -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.3.0 Status Report (2007-06-07)
On 6/7/07, Mark Mitchell <[EMAIL PROTECTED]> wrote: * PTR_PLUS branch. I believe that this branch should be included in GCC 4.3. Andrew, would you please update me as to its status? Yes, the summary is the branch has two autovector regressions in the testsuite, not directly related to the IR change. Forwprop is able to transform the code now to be using array references which confuses data reference. I have a patch for one of these regressions but I have not had time to submit it as I was submitting it for the trunk since it is not really related to the branch. (PR 32075 and PR 31996) I noticed also iv-opts is messing up in one or two spots but part of the problem is also reproduciable on the trunk; IV-opts sometimes uses non pointer types for the induction variable of a pointer type. I have a fix for this issue but it is too big I think to go in while doing the merge (I would like to be able to add this after the merge). In particular, are there any regressions on primary or secondary targets at this point? Here is what is known about the branch on each of the primary/secondary targets: * arm-eabi arm-elf builds and tests C without any regression (arm-eabi was not tested) * i386-unknown-freebsd unkown, don't have access * i686-pc-linux-gnu two vector regressions (see above) * i686-apple-darwin Likewise. * mipsisa64-elf mipsel-linux and mips64-elf have no regressions (mipsisa64-elf was not tested) [1] * powerpc64-unknown-linux-gnu same as i686-linux-gnu * sparc-sun-solaris2.10 Mr. Spark ran the branch on sparc and had no regressions * x86_64-unknown-linux-gnu same as i686-linux-gnu * hppa2.0w-hp-hpux11.11 unkown, I don't have access (but I did test a simple varible arguments testcase here) * powerpc-ibm-aix5.2.0.0 unknow (but I can assume it is like powerpc-darwin and powerpc64-linux-gnu) * powerpc-apple-darwin same as i686-linux-gnu * i686-pc-cygwin unkown, don't have an environment setup * i686-mingw32 unkown, don't have an environment setup * ia64-unknown-linux-gnu unkown, don't have access (but I did test a simple varible arguments testcase here) * s390-linux-gnu unkown, don't have access (but I did test a simple varible arguments testcase here) other targets: * spu-elf same regressions as i686-linux-gnu * sh4-unknown-linux-gnu no regressions A disclamer, I will be in Japan from the 18th to 22nd so I will be slow at fixing the bugs associated after the merge during that time. Thanks, Andrew Pinski [1] http://gcc.gnu.org/ml/gcc/2007-06/msg00232.html (even though that shows a couple of regressions the build was done before I fixed those generic regressions on the branch)
Re: machine learning for loop unrolling
Hello, > The number of floating point ops. in loop body. > The number of memory ops. in loop body. > The number of operands in loop body. > The number of implicit instructions in loop body. > The number of unique predicates in loop body. > The number of indirect references in loop body. > The number of uses in the loop.h > The number of defs. in the loop. you have to scan insns in loop body, and check what they do for this. > The number of parallel "computations" in loop. > The estimated latency of the critical path of loop. > The estimated cycle length of loop body. > The max. dependence height of computations. > The max. height of memory dependencies of computations. > The max. height of control dependencies of computations. > The average dependence height of computations. > The min. memory-to-memory loop-carried dependence. > The number of memory-to-memory dependencies. This is a bit more difficult; I guess you could persuade scheduler to give you this information, but I have no idea how exactly. See modulo-sched.c, it considers similar kind of information. > The language (C or Fortran). You may check name in langhooks. > The tripcount of the loop (-1 if unknown). See find_simple_exit and related functions in loop-iv.c. > Here is how I'm thinking of conducting the experiment: > > - for each innermost loop: >- compile with the loop unrolled 1x, 2x, 4x, 8x, 16x, 32x and > measure the time the benchmark takes >- write down the loop features and the best unroll factor > - apply some machine learning technique to the above data to determine > the correlations between loop features and best unroll factor > - integrate the result into gcc and measure the benchmarks again > > Do you think it is ok to only consider inner-most loops? We do not unroll non-innermost loops at the moment, so if you want to test non-innermost loops, you would probably have to extend some loop manipulation functions (loop unrolling was written to work for non-innermost loops as well, but it was not well tested and thus it is very likely buggy). > What about > the unroll factors? Should I consider bigger unroll factors? I think unroll factors over 32 should not give you much more gain, but you will see what results you will get. > Do you think the above setup is ok? I am somewhat skeptical; I would expect the results to be quite target-dependent, and also to differ from program to program. Thus, it may be somewhat hard to derive a useful general heuristics from them. But I would be very happy to be proven wrong :-) Zdenek
MIPS results on the pointer_plus branch.
Andrew, I tested mipsel-linux and mips64-elf on the pointer_plus branch for c, and c++. For r125291 mips64-elf the only regressions are those that would be expected (I think): -PASS: gcc.dg/matrix/matrix-1.c scan-ipa-dump-times Flattened 3 dimensions 1 +FAIL: gcc.dg/matrix/matrix-1.c scan-ipa-dump-times Flattened 3 dimensions 1 -PASS: gcc.dg/matrix/matrix-2.c scan-ipa-dump-times Flattened 2 dimensions 1 +FAIL: gcc.dg/matrix/matrix-2.c scan-ipa-dump-times Flattened 2 dimensions 1 -PASS: gcc.dg/matrix/matrix-3.c scan-ipa-dump-times Flattened 2 dimensions 1 +FAIL: gcc.dg/matrix/matrix-3.c scan-ipa-dump-times Flattened 2 dimensions 1 -PASS: gcc.dg/matrix/matrix-6.c scan-ipa-dump-times Flattened 2 dimensions 1 +FAIL: gcc.dg/matrix/matrix-6.c scan-ipa-dump-times Flattened 2 dimensions 1 -PASS: gcc.dg/tree-ssa/forwprop-2.c scan-tree-dump t\[i.*\] = 1; +FAIL: gcc.dg/tree-ssa/forwprop-2.c scan-tree-dump t\[i.*\] = 1; And for mipsel-linux: -PASS: gcc.dg/matrix/matrix-1.c scan-ipa-dump-times Flattened 3 dimensions 1 +FAIL: gcc.dg/matrix/matrix-1.c scan-ipa-dump-times Flattened 3 dimensions 1 -PASS: gcc.dg/matrix/matrix-2.c scan-ipa-dump-times Flattened 2 dimensions 1 +FAIL: gcc.dg/matrix/matrix-2.c scan-ipa-dump-times Flattened 2 dimensions 1 -PASS: gcc.dg/matrix/matrix-3.c scan-ipa-dump-times Flattened 2 dimensions 1 +FAIL: gcc.dg/matrix/matrix-3.c scan-ipa-dump-times Flattened 2 dimensions 1 -PASS: gcc.dg/matrix/matrix-6.c scan-ipa-dump-times Flattened 2 dimensions 1 +FAIL: gcc.dg/matrix/matrix-6.c scan-ipa-dump-times Flattened 2 dimensions 1 -PASS: gcc.dg/matrix/transpose-1.c scan-ipa-dump-times Flattened 3 dimensions 1 -PASS: gcc.dg/matrix/transpose-1.c scan-ipa-dump-times Transposed 3 +FAIL: gcc.dg/matrix/transpose-1.c scan-ipa-dump-times Flattened 3 dimensions 1 +FAIL: gcc.dg/matrix/transpose-1.c scan-ipa-dump-times Transposed 3 -PASS: gcc.dg/matrix/transpose-2.c scan-ipa-dump-times Flattened 3 dimensions 1 +FAIL: gcc.dg/matrix/transpose-2.c scan-ipa-dump-times Flattened 3 dimensions 1 -PASS: gcc.dg/matrix/transpose-3.c scan-ipa-dump-times Flattened 2 dimensions 1 -PASS: gcc.dg/matrix/transpose-3.c scan-ipa-dump-times Transposed 2 +FAIL: gcc.dg/matrix/transpose-3.c scan-ipa-dump-times Flattened 2 dimensions 1 +FAIL: gcc.dg/matrix/transpose-3.c scan-ipa-dump-times Transposed 2 -PASS: gcc.dg/matrix/transpose-4.c scan-ipa-dump-times Flattened 3 dimensions 1 -PASS: gcc.dg/matrix/transpose-4.c scan-ipa-dump-times Transposed 2 +FAIL: gcc.dg/matrix/transpose-4.c scan-ipa-dump-times Flattened 3 dimensions 1 +FAIL: gcc.dg/matrix/transpose-4.c scan-ipa-dump-times Transposed 2 -PASS: gcc.dg/matrix/transpose-5.c scan-ipa-dump-times Flattened 3 dimensions 1 +FAIL: gcc.dg/matrix/transpose-5.c scan-ipa-dump-times Flattened 3 dimensions 1 -PASS: gcc.dg/matrix/transpose-6.c scan-ipa-dump-times Flattened 3 dimensions 1 +FAIL: gcc.dg/matrix/transpose-6.c scan-ipa-dump-times Flattened 3 dimensions 1 -PASS: gcc.dg/tree-ssa/forwprop-2.c scan-tree-dump t\[i.*\] = 1; +FAIL: gcc.dg/tree-ssa/forwprop-2.c scan-tree-dump t\[i.*\] = 1; David Daney
gcc-4.3-20070608 is now available
Snapshot gcc-4.3-20070608 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20070608/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.3 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 125581 You'll find: gcc-4.3-20070608.tar.bz2 Complete GCC (includes all of below) gcc-core-4.3-20070608.tar.bz2 C front end and core compiler gcc-ada-4.3-20070608.tar.bz2 Ada front end and runtime gcc-fortran-4.3-20070608.tar.bz2 Fortran front end and runtime gcc-g++-4.3-20070608.tar.bz2 C++ front end and runtime gcc-java-4.3-20070608.tar.bz2 Java front end and runtime gcc-objc-4.3-20070608.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.3-20070608.tar.bz2The GCC testsuite Diffs from 4.3-20070601 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.3 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.
[fixed-point] A diff file for all changes
Hi, For those who are interested in looking at all changes for the fixed-point branch, I created a diff file of 147 files. This diff file doesn't have changes requested by Mark. Because the diff file is large, I compressed it and posted it to the GCC wiki page (20070608gcc.diff.gz). http://gcc.gnu.org/wiki/FixedPointArithmetic?action=AttachFile To make the merging process manageable, we will have a plan to merge changes steps by steps to ensure that everything still works after every step. Thanks a lot! Regards, Chao-ying 1. Fixed-point testing: Running /home/fu/dev/gcc4xfp/combined/gcc/testsuite/gcc.dg/fixed-point/fixed-point.exp ... === gcc Summary === # of expected passes997 /home/fu/dev/gcc4xfp/build64/gcc/xgcc version 4.3.0 20070608 (experimental) make[1]: Leaving directory `/home/fu/dev/gcc4xfp/build64/gcc' Running /home/fu/dev/gcc4xfp/combined/gcc/testsuite/gcc.dg/fixed-point/fixed-point.exp ... === gcc Summary === # of expected passes997 /home/fu/dev/gcc4xfp/build32r2/gcc/xgcc version 4.3.0 20070608 (experimental) make[1]: Leaving directory `/home/fu/dev/gcc4xfp/build32r2/gcc' 2. (147 Files) Index: libcpp/include/cpplib.h Index: libcpp/expr.c Index: libgcc/Makefile.in Index: gcc/Makefile.in Index: gcc/ginclude/stdfix.h Index: gcc/alias.c Index: gcc/c-common.c Index: gcc/c-common.h Index: gcc/c-convert.c Index: gcc/c-cppbuiltin.c Index: gcc/c-decl.c Index: gcc/c-lex.c Index: gcc/c-parser.c Index: gcc/c-pretty-print.c Index: gcc/c-tree.h Index: gcc/c-typeck.c Index: gcc/config.in Index: gcc/configure Index: gcc/convert.c Index: gcc/convert.h Index: gcc/configure.ac Index: gcc/cse.c Index: gcc/cselib.c Index: gcc/defaults.h Index: gcc/df-scan.c Index: gcc/double-int.c Index: gcc/doc/c-tree.texi Index: gcc/doc/extend.texi Index: gcc/doc/install.texi Index: gcc/doc/md.texi Index: gcc/doc/rtl.texi Index: gcc/doc/tm.texi Index: gcc/dwarf2out.c Index: gcc/emit-rtl.c Index: gcc/expmed.c Index: gcc/expr.c Index: gcc/flow.c Index: gcc/final.c Index: gcc/fixed-value.c Index: gcc/fixed-value.h Index: gcc/fold-const.c Index: gcc/gcse.c Index: gcc/genemit.c Index: gcc/gengenrtl.c Index: gcc/gengtype.c Index: gcc/genmodes.c Index: gcc/genopinit.c Index: gcc/gimplify.c Index: gcc/ipa-prop.c Index: gcc/ipa-type-escape.c Index: gcc/local-alloc.c Index: gcc/loop-invariant.c Index: gcc/machmode.def Index: gcc/machmode.h Index: gcc/mode-classes.def Index: gcc/optabs.c Index: gcc/optabs.h Index: gcc/postreload-gcse.c Index: gcc/print-tree.c Index: gcc/regclass.c Index: gcc/recog.c Index: gcc/regrename.c Index: gcc/reload.c Index: gcc/reload1.c Index: gcc/resource.c Index: gcc/rtl.c Index: gcc/rtl.def Index: gcc/rtl.h Index: gcc/rtlanal.c Index: gcc/target-def.h Index: gcc/sched-deps.c Index: gcc/sched-vis.c Index: gcc/simplify-rtx.c Index: gcc/stor-layout.c Index: gcc/target.h Index: gcc/targhooks.c Index: gcc/targhooks.h Index: gcc/tree.c Index: gcc/tree.def Index: gcc/tree.h Index: gcc/tree-browser.c Index: gcc/tree-complex.c Index: gcc/tree-dump.c Index: gcc/tree-gimple.c Index: gcc/tree-inline.c Index: gcc/tree-pretty-print.c Index: gcc/tree-scalar-evolution.c Index: gcc/tree-ssa-loop-im.c Index: gcc/tree-ssa-pre.c Index: gcc/tree-ssa-reassoc.c Index: gcc/tree-vect-generic.c Index: gcc/tree-vect-transform.c Index: gcc/treestruct.def Index: gcc/varasm.c Index: gcc/config/fixed-bit.c Index: gcc/config/fixed-bit.h Index: gcc/config/mips/mips.c Index: gcc/config/mips/mips.h Index: gcc/config/mips/mips.md Index: gcc/config/mips/mips-modes.def Index: gcc/config/mips/mips-fixed.md Index: gcc/testsuite/lib/target-supports.exp Index: gcc/testsuite/gcc.dg/fixed-point/fixed-point.exp Index: gcc/testsuite/gcc.dg/fixed-point/addsub.c Index: gcc/testsuite/gcc.dg/fixed-point/allconv.c Index: gcc/testsuite/gcc.dg/fixed-point/allop.c Index: gcc/testsuite/gcc.dg/fixed-point/allop-const.c Index: gcc/testsuite/gcc.dg/fixed-point/call-by-value.c Index: gcc/testsuite/gcc.dg/fixed-point/cast-bad.c Index: gcc/testsuite/gcc.dg/fixed-point/composite-type.c Index: gcc/testsuite/gcc.dg/fixed-point/const-1.c Index: gcc/testsuite/gcc.dg/fixed-point/constant.c Index: gcc/testsuite/gcc.dg/fixed-point/constants-pedantic.c Index: gcc/testsuite/gcc.dg/fixed-point/convert.c Index: gcc/testsuite/gcc.dg/fixed-point/define.c Index: gcc/testsuite/gcc.dg/fixed-point/keywords-c89.c Index: gcc/testsuite/gcc.dg/fixed-point/keywords-c99.c Index: gcc/testsuite/gcc.dg/fixed-point/keywords-ignored-c99.c Index: gcc/testsuite/gcc.dg/fixed-point/keywords-pedantic.c Index: gcc/testsuite/gcc.dg/fixed-point/keywords-reserved.c Index: gcc/testsuite/gcc.dg/fixed-point/modes.c Index: gcc/testsuite/gcc.dg/fixed-point/noassoc.c Index: gcc/testsuite/gcc.dg/fixed-point/types.c Index: gcc/testsuite/gcc.dg/fixed-point/typespec.c Index: gcc/testsuite/gcc.dg/fixed-point/unary.c Index: gcc/testsuite/gcc.dg/fixed-point/binary.c Index: gcc/testsuite/gcc.target/mips/dpaq_sa_l_w.c Index
Re: GCC 4.3.0 Status Report (2007-06-07)
Mark Mitchell wrote: Brooks Moses wrote: Several members of the GFortran team (primarily Chris Rickett and Steve Kargl) have been working on a project to add the BIND(C) functionality from the Fortran 2003 standard. This provides for a standard means of linking Fortran code with code that uses standard C linkage conventions, as well as adding some other useful features. Thanks for making me aware of this project. As with the Objective-C changes, I think that the Fortran team can decide to merge this in Stage 2, so long as its understood that any problems will be theirs to solve. Ok. So, if I'm understanding you correctly, it should either go in before the June 15th cutoff for the end of Stage 1, or it should wait until the end of the intermediate lockdown when Stage 2 opens? When were you expecting to end the lockdown and open Stage 2? IMO, for the Fortran front end, "regressions-only" is an inappropriate criterion for this sort of mode, given that the front end does not have a long history for the wrong-code and ICE-on-valid bugs to be regressions against. I think that's less true than it used to be. It's true that gfortran is new-ish, and I've given the Fortran team a lot of flexibility in past release cycles. But, congratulations are in order: gfortran is now a real Fortran compiler and people really are using it! But, "regressions, wrong-code, and ICEs" isn't a bad criteria for this intermediate lockdown. Thanks! It's less true than it used to be, but at present Fortran has only five regressions filed against 4.3. Three of them are against a single patch that's been reverted, one of the remaining ones is a regression from g77 and is (practically speaking) really a matter of adding new functionality, and that leaves one -- which happens to be a particularly messy tangle. So I'm glad we agree on criteria for the lockdown. :) I do expect Fortran to honor the regressions-only rule once the 4.3 release branch has been made. I definitely agree with that. I only realized how much effort we had been putting into backporting non-regression Fortran fixes to old release branches once we (largely) stopped doing it towards the end of the 4.2 release cycle. - Brooks
RE: Fixed-point branch?
Mark Mitchell wrote: > > I attached a diff file for 14 files of the new structures > > and documents. You and other maintainers are welcome to > > check it. Thanks a lot! > > Thank you for posting this. > > Things about which I am clueless: > > What is the difference between a _Fract type and an _Accum type? I'm > gathering that _Fract types have no integer part, i.e., they always > represent a number between (-1,1), whereas _Accum types > contain both an > integer and a fractional part. Is there any other difference? No other differences. For _Fract and _Accum, there are signed and unsigned types. The unsigned _Fract and _Accum types are always >= 0. > > Substantive issues: > > + unsigned saturating_flag : 1; /* FIXME. This new flag > increases the > size of > +tree_common by a full word. */ > > We need to fix that, if it's true. Grab a bit out of > tree_base::spare, > if need be. Yes. Will get one spare bit for saturating_flag. > > + /* Fixed-point types. */ > + if (targetm.fixed_point_supported_p ()) > > I thought there was an emulation library for fixed-point operations? > So, why would this be supported only on some targets? Is there a harm > in supporting it everywhere? If there is, should it be enabled > per-target, or via a configure-time option? Right now, the fixed-point support is a configure-time option. Each target can decide to support it or not. I think there is no harm to enable for every target. But, each target needs to modify tm.h tm.c tm-modes.def to set or change some target macros. > > I don't see any constant-folding code for fixed-point; is > there no need > for that? Is it somewhere else in the codebase? I will post a diff file that has everything including constant-folding code soon. > > Stylistic points: > > Every function needs a comment saying what it does, what > every argument > is, and what the return value is. You have some new > functions that are > missing comments. Ok. Will fix it. > > + fixed-point <- real, > > Please write as "real to fixed point" to avoid ambiguity with > the errors. Ok. Will fix it. > > +DEF_RTL_EXPR(FIXED_ALL, "fixed_all", "e", RTX_UNARY) > > Why FIXED_ALL? That doesn't seem mnemonic. It's hard to pick up a name. Maybe we will change it to the following as Nigel suggested. /* Conversions involving fractional fixed point types without saturation, including: fractional to fractional (of different precision), signed integer to fractional, fractional to signed integer, floating point to fractional, fractional to floating point. */ DEF_RTL_EXPR(FRACT_CONVERT, "fract_convert", "e", RTX_UNARY) > > > + sat_short_fract_type_node = > make_sat_signed_fract_type (SHORT_FRACT_TYPE_SIZE); > > + sat_fract_type_node = make_sat_signed_fract_type > (FRACT_TYPE_SIZE); > > + sat_long_fract_type_node = > make_sat_signed_fract_type (LONG_FRACT_TYPE_SIZE); > > + sat_long_long_fract_type_node = > make_sat_signed_fract_type (LONG_LONG_FRACT_TYPE_SIZE); > > Can we macroize some of this goo? There are several places > in the patch > where you have very long sequences of types, modes, etc. I would hope > that by naming things consistently, we might be able to compact this a > lot, and reduce the chance that we've got something wrong in just one > place. Like: > > #define MAKE_FIXED_TYPE_NODE(KIND, WIDTH, SAT) \ > set_##WIDTH_##KIND_type_node = make_##SAT_... > > and then: > > #define MAKE_FIXED_TYPE_NODE_FAMILY(KIND) \ > MAKE_FIXED_TYPE_NODE(_short, KIND); \ > MAKE_FIXED_TYPE_NODE(_, KIND); \ > MAKE_FIXED_TYPE_NODE(_long, KIND); \ > MAKE_FIXED_TYPE_NODE(_long_long, KIND); > > and then: > > MAKE_FIXED_TYPE_NODE_FAMILY(sat, fract); > MAKE_FIXED_TYPE_NODE_FAMILY(sat, accum); > > etc. > > That's not right, but you get the idea. :-) Ok. We will try to shorten C code. Thanks! Regards, Chao-ying
Re: GCC 4.3.0 Status Report (2007-06-07)
Brooks Moses wrote: > Several members of the GFortran team (primarily Chris Rickett and Steve > Kargl) have been working on a project to add the BIND(C) functionality > from the Fortran 2003 standard. This provides for a standard means of > linking Fortran code with code that uses standard C linkage conventions, > as well as adding some other useful features. Thanks for making me aware of this project. As with the Objective-C changes, I think that the Fortran team can decide to merge this in Stage 2, so long as its understood that any problems will be theirs to solve. This is one way in which its advantageous to be a "secondary" language; because we can be more flexible about releasing the compiler with some quality issues for such languages, we can also be more flexible. > IMO, for the Fortran front end, "regressions-only" is an inappropriate > criterion for this sort of mode, given that the front end does not have > a long history for the wrong-code and ICE-on-valid bugs to be > regressions against. I think that's less true than it used to be. It's true that gfortran is new-ish, and I've given the Fortran team a lot of flexibility in past release cycles. But, congratulations are in order: gfortran is now a real Fortran compiler and people really are using it! But, "regressions, wrong-code, and ICEs" isn't a bad criteria for this intermediate lockdown. I do expect Fortran to honor the regressions-only rule once the 4.3 release branch has been made. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.3.0 Status Report (2007-06-07)
Joseph S. Myers wrote: > On Thu, 7 Jun 2007, Mark Mitchell wrote: > >> I am aware of three remaining projects which are or might be appropriate >> for Stage 1: > > Do we at this point believe that the people who were working on updating > the TYPE_ARG_TYPES changes (from the old LTO branch) for trunk are not now > going to have them ready in time? I don't see any evidence that those changes will be ready. I haven't heard of any progress from the volunteer at AMD who was working on that. However, I also think that those changes could go in during Stage 2, if they are ready by then. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: note_stores vs. PRE_DEC, POST_INC and so on
Rask Ingemann Lambertsen <[EMAIL PROTECTED]> writes: >The comment for note_stores() (in rtlanal.c) says: > > /* Call FUN on each register or MEM that is stored into or clobbered by X. >(X would be the pattern of an insn). > >But this doesn't happen when a register is modified by e.g. a PRE_DEC > expression. Is this an oversight or intentional? If intentional, the comment > should say so and perhaps also why. The note_stores interface doesn't really provide a way to handle PRE_DEC or other such expressions. We could change that by redefining the interface, but we would need to audit all the calls to note_stores. That would be a good idea in any case since it is certainly possible, even likely, that some of them should be handle autoincrement expressions but aren't. Ian
Generating DWARF CIE info
I'm working with a target that has a call instruction similar to SPARC: the address of the calling instruction is saved in a link register (lr). The actual return address is, like SPARC, lr+8. It seemed to me that the right thing would be to have the initial value of the "return address" column in the CIE contain the location expression for lr+8. When I tried this, the offset was ignored and only the register number was generated. I came across this comment in dwarf2out.c: case PLUS: /* The return address is at some offset from any value we can actually load. For instance, on the SPARC it is in %i7+8. Just ignore the offset for now; it doesn't matter for unwinding frames. */ When I looked at what sparc-gcc was generating for the return address column, I discovered that it didn't generate anything. Instead, sparc-gdb ignores it and computes %i7+8. It seems to me that the offset is necessary to unwind a frame correctly (at least, if you use the CIE info). Is there any reason to discard it? -- Michael Eager[EMAIL PROTECTED] 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: GCC 4.3.0 Status Report (2007-06-07)
On Jun 8, 2007, at 12:50 PM, Mark Mitchell wrote: That's OK with me, but with two caveats: We are in the final stages of releasing this, so most development and testing has been done as well as ensuring that C and C++ are unaffected. This should help us meet the safeness goals. Thanks for the feedback.
Re: GCC 4.3.0 Status Report (2007-06-07)
Mike Stump wrote: > On Jun 7, 2007, at 10:33 PM, Mark Mitchell wrote: >> I am aware of three remaining projects which are or might be appropriate >> for Stage 1: > > I wasn't sure of the Objective-C 2.0 timing until recently... I'd like > to contribute it during stage 2. That's OK with me, but with two caveats: 1. We will not make any efforts to hold up the release for Objective-C issues that may result from this change. You will be on your own to make sure that everything is in good shape. 2. If the patches make changes to non-Objective-C parts of the compiler, the relevant maintainers have veto authority; they can decide the changes are too dangerous. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
note_stores vs. PRE_DEC, POST_INC and so on
The comment for note_stores() (in rtlanal.c) says: /* Call FUN on each register or MEM that is stored into or clobbered by X. (X would be the pattern of an insn). But this doesn't happen when a register is modified by e.g. a PRE_DEC expression. Is this an oversight or intentional? If intentional, the comment should say so and perhaps also why. -- Rask Ingemann Lambertsen
Re: machine learning for loop unrolling
On 08 Jun 2007, at 16:31, Stefan Ciobaca wrote: Hello everyone, For my bachelor thesis I'm modifying gcc to use machine learning to predict the optimal unroll factor for different loops (inspired from this paper: http://www.lcs.mit.edu/publications/pubs/pdf/MIT-LCS- TR-938.pdf). Interesting. I'm using evolutionary algorithms for similar purposes in my current research... Of course, not all of these are relevant to gcc. I'm looking at ways to compute some of these features, hopefully the most relevant ones. If there is already some work done that I could use in order to compute some of these features, I'd be glad if you could tell me about it. Also, if anyone can think of some useful features, related to the target architecture or the loops structure, I'd be glad to hear about them. I'm afraid I can't help here, I'm not familiar at all with GCCs internals. Also, I'm interested in some benchmarks. Many of the research papers that describe compiler optimizations use the SPEC* benchmarks, but these are not free, so I'm looking for alternatives. Currently I'm looking into: - OpenBench - Botan - CSiBE - Polyhedron (thanks to richi of #gcc for the last 3) Do you know any other one that would be better? But I can help here. Polyhedron is Fortran-only, but are well-suited for timing experiments (i.e. they run long enough to have reasonable running times, but aren't too long either). CSiBE is more targetted to code size, I believe the runtimes are ridicously small. I'm not familiar with the other two. Some other possibilities: * MiDataSets (also fairly small when run only once, but the suite allows you to adjust the outer loop iteration count to increase runtimes) [http://sourceforge.net/projects/midatasets] * MediaBench / MediaBench II: multimedia workloads, which typically iterate over frames for example [http://euler.slu.edu/~fritts/ mediabench/] * BioMetricsWorkload [http://www.ideal.ece.ufl.edu/main.php?action=bmw] * BioPerf: gene sequence analysis, ... [http://www.bioperf.org/] * some other benchmarks commonly used when testing GCC [http:// www.suse.de/~gcctest] I've been using the above with GCC and most work pretty well (on x86). Here is how I'm thinking of conducting the experiment: - for each innermost loop: - compile with the loop unrolled 1x, 2x, 4x, 8x, 16x, 32x and measure the time the benchmark takes - write down the loop features and the best unroll factor - apply some machine learning technique to the above data to determine the correlations between loop features and best unroll factor Any idea which? There's a huge number of different techniques out there, choosing an appropiate one is critical to success. - integrate the result into gcc and measure the benchmarks again When using machine learning techniques to build some kind of model, a common technique is crossvalidation. Say you have 20 benchmarks, no matter which ones. You use the larger part of those (for example 15) to build the model (i.e. determine the correlations between loop features and best unroll factor), and then test performance of that on the other ones. The important thing is not to use the benchmarks you test with when using the machine learning technique. That way, you can (hopefully) show that the stuff you've learned should work for other programs too. Do you think it is ok to only consider inner-most loops? What about the unroll factors? Should I consider bigger unroll factors? Do you think the above setup is ok? I'd say: don't be afraid to try too much. Try insane unroll factors too, just for testing purposes. You don't want to limit yourself to 32x when the optimal could be 64x for example. I welcome any feedback on this. Who is your advisor on this? Where are you doing your bachelors thesis? greetings, Kenneth -- Computer Science is no more about computers than astronomy is about telescopes. (E. W. Dijkstra) Kenneth Hoste ELIS - Ghent University email: [EMAIL PROTECTED] blog: http://www.elis.ugent.be/~kehoste/blog website: http://www.elis.ugent.be/~kehoste
Re: PATCH COMMITTED: Don't break tests for enum in range
> With Java the middle end should never see an uninitialized variable. > Uninitialized variables are precluded by the language definition, or > the bytecode verifier. Then if there's no other way in the language to create an undefined value, Java should certainly use the "undefined" choice, like C.
Re: PATCH COMMITTED: Don't break tests for enum in range
> "Richard" == Richard Kenner <[EMAIL PROTECTED]> writes: Richard> The simplest example of that is an uninitialized variable. Richard> I think the best approach is to use flags set by the front Richard> end to indicate which of these is to be the case. For C, I Richard> believe (1) is always the proper meaning. I don't know what Richard> it is for C++, Fortran, and Java. With Java the middle end should never see an uninitialized variable. Uninitialized variables are precluded by the language definition, or the bytecode verifier. Tom
ada, gcc 4.3 and darwin?
I recall there were supposed to be some unresolved issues with creating shared libraries for ada on darwin in the past. Have those been resolved or will they be addressed for the gcc 4.3.0 release? I ask because I am considering adding ada to the set of languages built for a future fink gcc43 package. Thanks in advance for any clarifications. Jack
room for GCC Summit
All, I have booked a 2 bedroom suite at Les Suites for 07/17 checkin and 07/21 checkout. If someone would like to take the second bedroom (or the living room & daybed) we can split costs. -All 4 nights please -Everyone's name will be added to the reservation to avoid checkin problems. If you're interested, please send me mail off list. Jim. -- James Lemke [EMAIL PROTECTED]
RE: GCC 4.3.0 Status Report (2007-06-07)
H.J., Yes, that is possible Marius -Original Message- From: H. J. Lu [mailto:[EMAIL PROTECTED] Sent: Friday, June 08, 2007 6:07 AM To: Mark Mitchell Cc: GCC; Kenneth Zadeck; Andrew Pinski; Cornea, Marius Subject: Re: GCC 4.3.0 Status Report (2007-06-07) On Thu, Jun 07, 2007 at 10:33:26PM -0700, Mark Mitchell wrote: > I am aware of three remaining projects which are or might be appropriate > for Stage 1: > > In the interests of moving forwards, I therefore plan to close this > exceptionally long Stage 1 as of next Friday, June 15th. The projects > named above may be merged, even though we will be in Stage 2 -- but no > other functionality of Stage 1 scope may be included after this point. > Intel is planning to contribute Intel BID runtime library before July 1. Marius, can we make it before June 15th? H.J.
machine learning for loop unrolling
Hello everyone, For my bachelor thesis I'm modifying gcc to use machine learning to predict the optimal unroll factor for different loops (inspired from this paper: http://www.lcs.mit.edu/publications/pubs/pdf/MIT-LCS-TR-938.pdf). I've compiled gcc 4.1.2 on my machine and I've located the loop-unroll.c file, where the unrolling is actually done (Richard Guenther also suggested that I loop in tree-ssa-loop*.c, because some unrolling is done at that level. From what I can tell, only complete unrolling is done there, which is not interesting from a machine learning point of view). To learn the best unroll factor, I need several features for each loop. I've already figured out how to compute some of them: - number of operations (num_loop_insns) - number of branches (num_loop_branches) - loop nest level (can be easily computed by walking struct loops *) but there are a lot of other features suggested by the authors of the paper, for which I couldn't locate a convenient function: The number of floating point ops. in loop body. The number of memory ops. in loop body. The number of operands in loop body. The number of implicit instructions in loop body. The number of unique predicates in loop body. The estimated latency of the critical path of loop. The estimated cycle length of loop body. The language (C or Fortran). The number of parallel "computations" in loop. The max. dependence height of computations. The max. height of memory dependencies of computations. The max. height of control dependencies of computations. The average dependence height of computations. The number of indirect references in loop body. The min. memory-to-memory loop-carried dependence. The number of memory-to-memory dependencies. The tripcount of the loop (-1 if unknown). The number of uses in the loop.h The number of defs. in the loop. Of course, not all of these are relevant to gcc. I'm looking at ways to compute some of these features, hopefully the most relevant ones. If there is already some work done that I could use in order to compute some of these features, I'd be glad if you could tell me about it. Also, if anyone can think of some useful features, related to the target architecture or the loops structure, I'd be glad to hear about them. Also, I'm interested in some benchmarks. Many of the research papers that describe compiler optimizations use the SPEC* benchmarks, but these are not free, so I'm looking for alternatives. Currently I'm looking into: - OpenBench - Botan - CSiBE - Polyhedron (thanks to richi of #gcc for the last 3) Do you know any other one that would be better? Here is how I'm thinking of conducting the experiment: - for each innermost loop: - compile with the loop unrolled 1x, 2x, 4x, 8x, 16x, 32x and measure the time the benchmark takes - write down the loop features and the best unroll factor - apply some machine learning technique to the above data to determine the correlations between loop features and best unroll factor - integrate the result into gcc and measure the benchmarks again Do you think it is ok to only consider inner-most loops? What about the unroll factors? Should I consider bigger unroll factors? Do you think the above setup is ok? I welcome any feedback on this. Thank you, Stefan Ciobaca
Re: GCC 4.3.0 Status Report (2007-06-07)
On 6/8/07, Brooks Moses <[EMAIL PROTECTED]> wrote: Mark Mitchell wrote: > In the interests of moving forwards, I therefore plan to close this > exceptionally long Stage 1 as of next Friday, June 15th. The projects > named above may be merged, even though we will be in Stage 2 -- but no > other functionality of Stage 1 scope may be included after this point. An additional project, which is not on your list and perhaps should be: [snip ISO_C_BINDING stuff] In any case, I very strongly believe that this should be included in 4.3, and would hope that if the review process takes a couple of weeks that it can still be merged in. I agree. This is definitely a major feature for gfortran, and it seems that it's really close to being ready for merging. It would be a shame to let this slip for another year. Now, to my actual point. I'd like to propose another project worthy of inclusion, or actually a number of smaller projects. As of 4.3 the gfortran runtime library will have versioned symbols. This means that if we're going to provide some semblance of ABI stability to our users, we have until 4.3 to do any ABI fixes we feel necessary or useful. After that we're stuck with supporting the old ABI for the foreseeable future. Now, of course one of the benefits of versioned symbols is that we can keep supporting the old ABI as we add improved functionality to newer ABI versions, but the less cruft we have to drag along, the better for us from a maintenance perspective. Most of these ABI cleanup patches would be pretty small and mostly mechanical, so I don't think there's a large risk that we'll introduce regressions. For a recent example, see e.g. http://gcc.gnu.org/ml/gcc-patches/2007-06/msg00479.html Daniel Franke recently committed some infrastructure to enable the frontend to typecast intent(out) intrinsic arguments. This allows us to fix some ABI issues for intrinsics, where we have a lot of unnecessarily duplicated functions in the library, and also helps us avoid a combinatorial explotion that would result in supporting all type kinds for many arguments to some intrinsics. Of course, for some performance sensitive intrinsics we still want the library to have specific versions for different type kinds. -- Janne Blomqvist
machine learning for loop unrolling
Hello everyone, For my bachelor thesis I'm modifying gcc to use machine learning to predict the optimal unroll factor for different loops (inspired from this paper: http://www.lcs.mit.edu/publications/pubs/pdf/MIT-LCS-TR-938.pdf). I've compiled gcc 4.1.2 on my machine and I've located the loop-unroll.c file, where the unrolling is actually done (Richard Guenther also suggested that I loop in tree-ssa-loop*.c, because some unrolling is done at that level. From what I can tell, only complete unrolling is done there, which is not interesting from a machine learning point of view). To learn the best unroll factor, I need several features for each loop. I've already figured out how to compute some of them: - number of operations (num_loop_insns) - number of branches (num_loop_branches) - loop nest level (can be easily computed by walking struct loops *) but there are a lot of other features suggested by the authors of the paper, for which I couldn't locate a convenient function: The number of floating point ops. in loop body. The number of memory ops. in loop body. The number of operands in loop body. The number of implicit instructions in loop body. The number of unique predicates in loop body. The estimated latency of the critical path of loop. The estimated cycle length of loop body. The language (C or Fortran). The number of parallel "computations" in loop. The max. dependence height of computations. The max. height of memory dependencies of computations. The max. height of control dependencies of computations. The average dependence height of computations. The number of indirect references in loop body. The min. memory-to-memory loop-carried dependence. The number of memory-to-memory dependencies. The tripcount of the loop (-1 if unknown). The number of uses in the loop.h The number of defs. in the loop. Of course, not all of these are relevant to gcc. I'm looking at ways to compute some of these features, hopefully the most relevant ones. If there is already some work done that I could use in order to compute some of these features, I'd be glad if you could tell me about it. Also, if anyone can think of some useful features, related to the target architecture or the loops structure, I'd be glad to hear about them. Also, I'm interested in some benchmarks. Many of the research papers that describe compiler optimizations use the SPEC* benchmarks, but these are not free, so I'm looking for alternatives. Currently I'm looking into: - OpenBench - Botan - CSiBE - Polyhedron (thanks to richi of #gcc for the last 3) Do you know any other one that would be better? Here is how I'm thinking of conducting the experiment: - for each innermost loop: - compile with the loop unrolled 1x, 2x, 4x, 8x, 16x, 32x and measure the time the benchmark takes - write down the loop features and the best unroll factor - apply some machine learning technique to the above data to determine the correlations between loop features and best unroll factor - integrate the result into gcc and measure the benchmarks again Do you think it is ok to only consider inner-most loops? What about the unroll factors? Should I consider bigger unroll factors? Do you think the above setup is ok? I welcome any feedback on this. Thank you, Stefan Ciobaca
Re: GCC 4.3.0 Status Report (2007-06-07)
On Thu, Jun 07, 2007 at 10:33:26PM -0700, Mark Mitchell wrote: > I am aware of three remaining projects which are or might be appropriate > for Stage 1: > > In the interests of moving forwards, I therefore plan to close this > exceptionally long Stage 1 as of next Friday, June 15th. The projects > named above may be merged, even though we will be in Stage 2 -- but no > other functionality of Stage 1 scope may be included after this point. > Intel is planning to contribute Intel BID runtime library before July 1. Marius, can we make it before June 15th? H.J.
Re: When was decimal floating point added to gcc?
On Thu, Jun 07, 2007 at 08:40:14AM +1000, Ben Elliston wrote: > On Wed, 2007-06-06 at 16:46 +0200, Gerald Pfeifer wrote: > > > In that case it's probably not that good of a idea to promote it (unless > > the maintainers are in favor, of course ;-). > > I'm happy to leave things as they are for now. > Shouldn't it be mentioned in 4.3 changes? H.J.
Re: GCC 4.3.0 Status Report (2007-06-07)
On Thu, 7 Jun 2007, Mark Mitchell wrote: > I am aware of three remaining projects which are or might be appropriate > for Stage 1: Do we at this point believe that the people who were working on updating the TYPE_ARG_TYPES changes (from the old LTO branch) for trunk are not now going to have them ready in time? (There were many other smaller tree representation changes there of Kazu's that I think are suitable for merging in Stage 2 - in fact many of them were preapproved for 4.3.) -- Joseph S. Myers [EMAIL PROTECTED]
Re: [rfc] Moving bbs back to pools
Hello, > > The problem is, that it does not give any speedups (it is almost > > completely compile-time neutral for compilation of preprocessed > > gcc sources). I will check whether moving also edges to pools > > changes anything, but so far it does not seem very promising :-( > > Well, the benefits of these things are always very dificult to predict > :(. We later tweaked ggc-page to put basic blocks into > extra_order_size_table that ight've improved locality and get back some > part of the original 1% slowdown. > > I would expect edges to be more interesting since they are smaller and > there are more of them but I might be mistaken. at least for the preprocessed gcc sources, this turns out not to be the case. I guess there are two other reasons why we do not see the expected gains: 1) previously we kept only one cfg at a time (so using pool meant that the same memory was reused for each function), while now we keep cfgs for all functions alive at the same time. 2) garbage collection now needs to traverse basic blocks and edges (through the dynamic roots), while previously it did not see them at all. Zdenek
Re: GCC 4.3.0 Status Report (2007-06-07)
Brooks Moses wrote (on the Fortran BIND(C) project): I don't believe this project has been documented very well (if at all) on the standard Wiki page for Stage-1 projects, but I haven't looked at it in a while. I am also not entirely certain whether this qualifies as a Stage 1 or a Stage 2 project, since it produces fairly pervasive changes but only within the Fortran front end (and libgfortran library); however, the assumption on the Fortran list has been that it ought be merged during the Stage 1 period. As a followup to that: This project does have a Wiki page [1], but it was not linked on the "4.3 Release Planning" page at all. I have placed it in the "Uncategorized Projects" section, and have added short sketches of the appropriate data (as per SampleProjectTemplate) at the top of it for release planning purposes. - Brooks [1] http://gcc.gnu.org/wiki/Fortran2003Bind_C
Re: GCC 4.3.0 Status Report (2007-06-07)
On Jun 7, 2007, at 10:33 PM, Mark Mitchell wrote: I am aware of three remaining projects which are or might be appropriate for Stage 1: I wasn't sure of the Objective-C 2.0 timing until recently... I'd like to contribute it during stage 2.
Re: [OT] Re: Git repository with full GCC history
On 6/7/07, Bernardo Innocenti <[EMAIL PROTECTED]> wrote: Harvey Harrison wrote: > The final results of a repository holding a clone of trunk: With or without branches? (shouldn't matter that much, just for the record) Just trunk. > Size of git packs: > pack + index - 286344kB > git svn metadata - nearly 13MB, allows incremental updates as more > commits made in svn. That's great, but... could you tell us how you did it? git repack -a -d -f --window=100 --depth=100 (I know the depth is a bit much, depth=50 produces about 420MB pack). Be prepared to wait a long time to finish. But hopefully I'll have it up somewhere soon for others. Cheers, Harvey
Re: [rfc] Moving bbs back to pools
> Zdenek Dvorak <[EMAIL PROTECTED]> writes: > > > The problem is, that it does not give any speedups (it is almost > > completely compile-time neutral for compilation of preprocessed > > gcc sources). I will check whether moving also edges to pools > > changes anything, but so far it does not seem very promising :-( > > Does it make any difference for gcc.c-torture/compile/20001226-1.c? > And of course it won't make any difference if you have enough memory > that you never need to garbage collect without your patch. > > I would like to see us implement this general GC approach even if we > don't wind up moving the basic blocks into it today. But we'll have > to figure out what to do for PCH. I guess the general approach would > be to provide an optional swizzling routine as well as the marking Well, rather than swizzling routines I think it is better to simply avoid dumping the middle end datastructures to PCH when there are no good reasons for that (that is definitly not the case of BBs) Honza > routine. Then abort if gt_pch_save finds an object with a marking > routine but no swizzling routine. The swizzling routine would do > something involving gt_pch_note_object and/or relocate_ptrs. Or maybe > we would need two routines, one to note and one to relocate. > > Ian
Re: [rfc] Moving bbs back to pools
> Hello, > > as discussed in http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01133.html, > it might be a good idea to try moving cfg to alloc pools. The patch > below does that for basic blocks (each function has a separate pool > from that its basic blocks are allocated). At the moment, the patch > breaks precompiled headers, but otherwise bootstraps and passes > regtesting. Since precompiled headers are C++ only that is unit-at-a-time, I think we can arrange things in cgraph so the functions are not lowered yet at PCH point. I tried this plan once and abadoned it because of some dificulties I forgot but I can try again. > > The problem is, that it does not give any speedups (it is almost > completely compile-time neutral for compilation of preprocessed > gcc sources). I will check whether moving also edges to pools > changes anything, but so far it does not seem very promising :-( Well, the benefits of these things are always very dificult to predict :(. We later tweaked ggc-page to put basic blocks into extra_order_size_table that ight've improved locality and get back some part of the original 1% slowdown. I would expect edges to be more interesting since they are smaller and there are more of them but I might be mistaken. This approach might be also very interesting for GIMPLE tuples once they arrive I woudl say so I like it in general. Honza
