Re: Calculation of RTX Costs
Ian Lance Taylor writes: > pocma...@gmail.com (Paulo J. Matos) writes: > >> Moreover, is there a reason for the existence of COST_N_INSNS(x) and why >> this multiplies x by 4? Is 4 just a special number? Any reason on why I >> should be using COST_N_INSNS instead of just assigning *total (of >> target_rtx_costs) to a simple integer? > > COSTS_N_INSNS is relevant because a bunch of machine independent code > uses it to compare the cost of some expression to the cost of a > register-to-register move. All such uses are somewhat dubious and > should probably be eliminated in favor of delegating all cost questions > to the backend. However, since they exist at present, you don't have to > use COSTS_N_INSNS, but you do have to be aware of it. There is nothing > special about the number 4, it's just chosen to give backends a bit of > leeway in setting the costs of operations which are not quite as > expensive as a full instruction, so that, e.g., they can assign > different costs to different addressing modes. So, from what I understand, it seems that if there is machine independent code using COSTS_N_INSNS, I should be using it otherwise relative comparisons just don't make sense. However, from what I can see we have cost hooks for: - register move - memory move - branches - rtx - address only the last two refer to the use of COSTS_N_INSNS. How do the value for a register move (which defaults to 2), will compare to an rtx cost? Should we always use COSTS_N_INSNS for all the returned values, or for the first 3, COSTS_N_INSNS is applied on the return value? This seems to be certainly relevant for when optimising for code size. If I set a specific cost for a register move and a cost for a multiplication rtx how are they related? -- PMatos
Clarification on who can approve Objective-C/Objective-C++ parser patches
Most of the Objective-C/Objective-C++ parser code is in files shared with the C/C++ frontend, hence I'm confused about who approves what. For example, if I post a patch that changes a piece of code in gcc/c-parser.c which is only ever used if (c_dialect_objc ()), then I assume that it is part of the Objective-C front-end, and the Objective-C/Objective-C++ maintainers are in charge of approving it. Once they approve it, I can commit. Is that correct ? Do I need to wait for approval from the C/C++ frontend maintainers as well even if the execution path is only ever used when parsing Objective-C/Objective-C++ ? Thanks PS: Obviously I'm very happy to address any concerns anyone may have with any patch, and I won't commit any patch where there is any objection (certainly not from a C/C++ frontend maintainer), but my question is mostly about what I am supposed to do if the Objective-C/Objective-C++ maintainer approves my patch and nobody else says anything.
gengtype indentation issues
Hello All, References http://gcc.gnu.org/ml/gcc-patches/2010-09/msg01739.html http://gcc.gnu.org/ml/gcc-patches/2010-09/msg01740.html http://gcc.gnu.org/ml/gcc-patches/2010-09/msg01742.html http://gcc.gnu.org/ml/gcc-patches/2010-09/msg01743.html http://gcc.gnu.org/ml/gcc-patches/2010-09/msg01743.html http://gcc.gnu.org/ml/gcc-patches/2010-09/msg01744.html Overall context: gengtype (files gcc/gengtype*.[chl] of the trunk rev. 164550 to be specific) is a generator program used internally within GCC to handle GTY-ed types and generate GGC marking routines & PCH persisting routines, in relation with the Ggc garbage collector -usually called between GCC passes- and the precompiler header infrastructures). See http://gcc.gnu.org/onlinedocs/gccint/Type-Information.html for more. Gengtype generates files named gt-*.h and gtype*.[ch] in GCC build directory by reading many source files in GCC source directory (and some of these XXX.c source files have a #include "gt-XXX.h" line near the end). In my not so humble opinion, gengtype is not very well written (its code is much worse than the average GCC pass code), perhaps because it has been committed long time ago (2002?) without an extensive and deep peer review. It is only a C code generator. It is used internally when building GCC, and may be used or needed when building GCC plugins (the few plugins using GTY). The code generated by gengtype is used within GCC (the actual program installed by GCC users). So if gengtype don't change its generating code behavior -that is don't change the generated C files it is writing, it cannot possibly alter the behavior of GCC (because gengtype's own code does not appear inside GCC programs like gcc or cc1 or cc1plus etc; the only & important effect of gengtype on GCC programs is by the C code generated by gengtype. So w.r.t. GCC, gengtype is a metaprogramming utility.). Currently (and in GCC 4.5) to use gengtype for building any GCC plugin having its own GTY-ed types, you need both the entire GCC build tree and the entire GCC source tree. This is unfortunate, but it is documented (end of http://gcc.gnu.org/onlinedocs/gccint/Plugins.html page) as "Plugins needing to use gengtype require a GCC build directory for the same version of GCC that they will be linked against.". This is against the packaging practices of most Linux distributions and is hurting many good software engineering rules Diego Novillo told once (IIRC) that it is a dirty kludge With Jeremie Salvucci, I worked hard on improving gengtype. We did clean up minimally & superficially gengtype source code (which, even with our patches, remain dirty, but a bit less dirty than before), and most importantly, we painfully coded a persistence mechanism. qWith our gengtype patches, gengtype generates the same code as before (so cannot alter GCC behevior) and writes its entire state in a textual file gtype.state. For plugins using GTY, our patched gengtype can read that gtype.state file, parse the plugin source code, and generate the gt-*.h Notice that gengtype is not very well written, and it is *not* (in its current form from trunk rev. 164550) indented according to GNU & GCC standards. Much more on this below! However, the patches we (Jeremie & Basile) have sent still have indentation issues. And I am not able, even after having tried more than once, to cope with them without constrctive and practical help (e.g. a tool, a precise procedure to make patches [including .emacs configuration etc...]), and I did try several times to work on these indentation issues without success, since most of the comments I've got so far on the patches I have sent are on indentation. Dealing with the non-indentation issues of my patches seem feasible to me. However my time budget on gengtype patches is very negative already (I will already have hard time to justify w.r.t. the funding agencies for my GCC work having spent too much time on gengtype). I really did spent much too much time on gengtype, and I begin to think that it is not worth much more efforts. After all, these gengtype efforts are only useful for plugin developers, and there are few of them, plugins are disliked by most of the community. In particular, this gengtype effort is only profitable for plugins using GTY. And there are very few such plugins (perhaps only MELT and possibly DraggonEgg). For MELT, I can and do already deal without the gengtype feature introduced by my patches: I just keep in the contrib/gt-melt-runtime-plugin-4.5.h file of the MELT branch the gengtype generated file corresponding to gcc/melt-runtime.[ch] so that in practice MELT can be built as a plugin without gengtype. So I can continue to develop MELT without strictly needing an improved gengtype (even if that would be very convenient). In other words, my gengtype work is to help the community, and I don't need it much myself (I can cope without) within MELT. Regarding the indentation aspects of our work: Jeremie did
Re: End of GCC 4.6 Stage 1: October 27, 2010
On Tue, Sep 21, 2010 at 9:26 AM, Dave Korn wrote: > On 21/09/2010 02:51, NightStrike wrote: > >> The toolchain is broken once again here: >> >> x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H -I. >> -I../../../build/mingw/mingw-w64-crt >> -m32 -I../../../build/mingw/mingw-w64-crt/include -D_CRTBLD >> -I/tmp/build/root/x >> 86_64-w64-mingw32/include -pipe -std=gnu99 -Wall -Wextra -Wformat >> -Wstrict-ali >> asing -Wshadow -Wpacked -Winline -Wimplicit-function-declaration >> -Wmissing-noret >> urn -Wmissing-prototypes -g -O2 -MT math/lib32_libmingwex_a-sf_erf.o -MD -MP >> -MF >> math/.deps/lib32_libmingwex_a-sf_erf.Tpo -c -o >> math/lib32_libmingwex_a-sf_erf.o >> `test -f 'math/sf_erf.c' || echo >> '../../../build/mingw/mingw-w64-crt/'`math/sf_ >> erf.c >> ../../../build/mingw/mingw-w64-crt/math/sf_erf.c: In function >> `__trunc_float_wor >> d.isra.0': >> ../../../build/mingw/mingw-w64-crt/math/sf_erf.c:268:1: internal compiler >> error: >> tree check: expected var_decl, have debug_expr_decl in const_value_known_p, >> at >> varpool.c:375 > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45738 > > cheers, > DaveK > Thanks. Hope it gets fixed fast. I will post a new testsuite once that bug is closed.
Re: gengtype indentation issues
I'd suggest sending one initial patch fixing indentation issues and then sending your functional changes on top of the first patch. Diego.
Bootstrap failure on i386-pc-solaris2.10
Hi. This morning's build on my x86 Solaris build failed in stage2 like so: /home/ahaas/gnu/gcc.git/gcc/lto/lto-lang.c: In function 'lto_type_for_mode': /home/ahaas/gnu/gcc.git/gcc/lto/lto-lang.c:928:1: internal compiler error: in dwarf2out_frame_debug_adjust_cfa, at dwarf2out.c:1881 Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. make[3]: *** [lto/lto-lang.o] Error 1 make[3]: *** Waiting for unfinished jobs... My build yesterday succeeded: $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/export/home/arth/local/libexec/gcc/i386-pc-solaris2.10/4.6.0/lto-wrapper Target: i386-pc-solaris2.10 Configured with: /home/ahaas/gnu/gcc.git/configure --prefix=/export/home/arth/local --enable-languages=c,c++,objc,fortran --disable-nls --with-gmp=/export/home/arth/local --with-mpfr=/export/home/arth/local --enable-checking=release --enable-threads=posix --with-gnu-as --with-as=/export/home/arth/local/bin/as --with-gnu-ld --with-ld=/export/home/arth/local/bin/ld --enable-libstdcxx-pch=no --enable-objc-gc --build=i386-pc-solaris2.10 Thread model: posix gcc version 4.6.0 20100922 (experimental) (GCC) $ This morning's build on sparc-sun-solaris2.10 succeeded: $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/export/home/arth/local/libexec/gcc/sparc-sun-solaris2.10/4.6.0/lto-wrapper Target: sparc-sun-solaris2.10 Configured with: /export/home/arth/src/gcc.git/configure --prefix=/export/home/arth/local --enable-languages=c,c++,objc --disable-nls --with-gmp=/export/home/arth/local --with-mpfr=/export/home/arth/local --with-mpc=/export/home/arth/local --enable-checking=release --enable-threads --with-gnu-as --with-as=/export/home/arth/local/bin/as --with-gnu-ld --with-ld=/export/home/arth/local/bin/ld --enable-libstdcxx-pch=no --with-cpu=ultrasparc3 --with-tune=ultrasparc3 Thread model: posix gcc version 4.6.0 20100923 (experimental) (GCC) $ Thanks. Art Haas
Re: Clarification on who can approve Objective-C/Objective-C++ parser patches
On Thu, 23 Sep 2010, Nicola Pero wrote: > For example, if I post a patch that changes a piece of code in > gcc/c-parser.c which is only ever used if (c_dialect_objc ()), then I > assume that it is part of the Objective-C front-end, and the > Objective-C/Objective-C++ maintainers are in charge of approving it. > Once they approve it, I can commit. > > Is that correct ? Yes. I generally expect ObjC maintainers to review changes to those parts of c-parser.c. -- Joseph S. Myers jos...@codesourcery.com
Re: Where are the new GCC releases?
> Sure. Thanks, done after bootstrap/regtesting on x86_64-suse-linux. -- Eric Botcazou
plugin headers no longer installed?
Is the following issue appearing on any other targets? On x86_64-apple-darwin10, sometime after r164502 but by r164564, the installation of plugin headers was lost. At r164502, we still had the previous behavior on darwin where plugin headers were installed in... /sw/lib/gcc4.6/lib/gcc/x86_64-apple-darwin10.5.0/4.6.0/plugin/include when FSF gcc was built with --prefix=/sw/lib/gcc4.6. At r164564, this directory is no longer being installed. This will prevent the use of gcc trunk for building the dragon-egg plugin with the installed headers. Jack
Re: Autoconf tests, libtool symlist files, undefined behavior, and LTO
Hello t7, * t66...@gmail.com wrote on Thu, Sep 23, 2010 at 03:01:31AM CEST: > I don't know if my problem suites this description. No, it doesn't. > Currently installed libtool on this system is, > ltmain.sh (GNU libtool) 2.2.6b > > I recently tested the LTO feature of GCC (targeting windows) and I > found it was unable to link due to the presence of duplicating lines > of *crt* without compiling with -flto there were not such issues. > > It seems that libtool is emitting dllcrt2, crtbegin, crtend all over > again after the first crtend. In the following line. > g++ lib64/dllcrt2.o lib64/crtbegin.o ... > _alot_of_other_link_arguments_ ... lib64/crtend.o lib64/dllcrt2.o > lib64/crtbegin.o lib64/crtend.o > These last three duplicating .o arguments are causing errors. > lib64/dllcrt2.o:crtdll.c:(.text+0x50): multiple definition of `_CRT_INIT' > lib64/dllcrt2.o:crtdll.c:(.text+0x50): first defined here > Is this a know issue? You may have found a bug, or not, I cannot tell from the sparse description you've given. Please write to the bug-libtool at gnu.org mailing list (no subscription required) with full details about which GCC and Libtool versions you are using, after updating Libtool to 2.4 if you are trying to use LTO with it, write how you configured the software that fails to link, and please post the complete 'libtool --mode=link' command that fails, including all of its output. Then we will see further. On the odd chance of turning up a new GCC bug, we'll report back to the GCC bugzilla then. But until then there is no need to cross-post this to the GCC development mailing list. Thank you. Cheers, Ralf
Re: Clarification on who can approve Objective-C/Objective-C++ parser patches
>> For example, if I post a patch that changes a piece of code in >> gcc/c-parser.c which is only ever used if (c_dialect_objc ()), then I >> assume that it is part of the Objective-C front-end, and the >> Objective-C/Objective-C++ maintainers are in charge of approving it. >> Once they approve it, I can commit. >> >> Is that correct ? > Yes. I generally expect ObjC maintainers to review changes to those parts > of c-parser.c. Thanks Joseph that clarifies it. :-) Thanks
Re: gengtype indentation issues
Diego Novillo writes: > I'd suggest sending one initial patch fixing indentation issues and > then sending your functional changes on top of the first patch. Yes. Basile, I'm sorry you have to struggle with some poor existing indentation in gengtype.c, but the GNU style indentation is not all that hard. It is documented here: http://www.gnu.org/prep/standards/html_node/Formatting.html http://gcc.gnu.org/codingconventions.html Ian
Re: Calculation of RTX Costs
pocma...@gmail.com (Paulo J. Matos) writes: > So, from what I understand, it seems that if there is machine > independent code using COSTS_N_INSNS, I should be using it otherwise > relative comparisons just don't make sense. > > However, from what I can see we have cost hooks for: > - register move > - memory move > - branches > - rtx > - address > > only the last two refer to the use of COSTS_N_INSNS. How do the > value for a register move (which defaults to 2), will compare to an rtx > cost? You should be defining your rtx costs with the knowledge that the cost of a simple register to register move is 2. > Should we always use COSTS_N_INSNS for all the returned values, or for > the first 3, COSTS_N_INSNS is applied on the return value? You should only use COSTS_N_INSNS for RTL patterns that correspond to complete instructions on your machine. > This seems to be certainly relevant for when optimising for code size. > If I set a specific cost for a register move and a cost for a > multiplication rtx how are they related? When optimizing for performance, if your machine can do multiplication as part of an address calculation, and that multiplication is cheap, then you would want to make it as cheap as a register to register move. E.g., on x86, multiplication by 2 or 4 can be cheap. But in general one would expect that multiplication would cost more than a register to register move. The ratio between the costs should approximate the ratio of the clock cycles of the relevant instructions, inasmuch as that can be determined. When optimizing for size, the cost should normally be the number of instruction bytes required to implement the operation. For most processors it's not important to get all costs exactly correct. The compiler uses the costs in a relatively brute force manner. If there is only one way to do some operation, then its cost is irrelevant. Costs are mainly important on processors like x86 which have several different ways to implement the same operation. Ian
Interprocedural points-to analysis
Hi All, Has the interprocedural points-to analysis(pass-ipa-pta) been put into practice, i.e. using the ipa points-to set to aid optimizations? Thanks, Hongtao
Re: Interprocedural points-to analysis
On Thu, Sep 23, 2010 at 11:31 PM, Hongtao wrote: > Hi All, > > Has the interprocedural points-to analysis(pass-ipa-pta) been put into > practice, i.e. using the ipa points-to set to aid optimizations? Yes, it improves alias-analysis. The interface to optimizers is the same as local points-to analysis. In addition to that it computes IPA mod-ref information and stores it at call sites. That information is used by the alias-oracle as well. There are testcases in gcc.dg/ipa/ipa-pta-*.c (they are mostly correctness testcases but also a few optimization ones). Richard. > Thanks, > Hongtao >
gcc-4.5-20100923 is now available
Snapshot gcc-4.5-20100923 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20100923/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_5-branch revision 164573 You'll find: gcc-4.5-20100923.tar.bz2 Complete GCC (includes all of below) MD5=5291e4bb2e0710b87aa1b3ed42358d54 SHA1=2f417e8a1157f429a3918029d4e18352fa4099fb gcc-core-4.5-20100923.tar.bz2C front end and core compiler MD5=94045befb43247581434ac4d40113915 SHA1=23e168d6f7fea5fed36b585880bbef6a9c0d7b75 gcc-ada-4.5-20100923.tar.bz2 Ada front end and runtime MD5=c86ff42ce19879afdf8488726f09a27f SHA1=21b2b56f4ec4f04e269db8640661c49ce9e74986 gcc-fortran-4.5-20100923.tar.bz2 Fortran front end and runtime MD5=a8c2d3efaaa78001c7ff5c3389f24a87 SHA1=2a8a22c7d7fc6a51a1ef0005a6c01fe50de12a01 gcc-g++-4.5-20100923.tar.bz2 C++ front end and runtime MD5=b7a8214420d7fe85ac756333ac8a2d85 SHA1=36f8bb3d51f2a0eb11c7b167253dff68c21e5ca2 gcc-java-4.5-20100923.tar.bz2Java front end and runtime MD5=8413e65884574fd5cb6158da45f145bf SHA1=f04eead7ce9ea23337d2cf0ec27159b4fefa11f3 gcc-objc-4.5-20100923.tar.bz2Objective-C front end and runtime MD5=81907aaca3c00184063afff3c26668e1 SHA1=81691e54b766ff8b1940b3e51e5c81946cf01147 gcc-testsuite-4.5-20100923.tar.bz2 The GCC testsuite MD5=decd54f4737779c2216dab50bcbd460f SHA1=6de6d5870ddcd650843fd686c710b3b9a8e8cc1b Diffs from 4.5-20100916 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.5 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.
