Re: GCC 4.5.0 Released
On 20 April 2010 03:03, Dave Korn wrote: > precis. So if there's a discussion to be had here, it's about how GCC should > be "marketed", and the extent to which a release announcement should be part > of that effort. Is there any one against advertising GCC to the fullest extent? The problem, as always, is who will do this job. But I don't think nobody will be against if you create a GCC blog/tweeter/youtube channel and start writing nice articles for various magazines/journals/newspapers. People may criticize what you say if it is untrue or inaccurate, but per-se more (positive) visibility of GCC is good. Cheers, Manuel.
Re: Plan for gc-improv merge
On Mon, Apr 19, 2010 at 4:43 PM, Laurynas Biveinis wrote: > Hi, > > Now that GCC is in the stage1 and gc-improv branch work is finished as > I see it, I propose to merge it to mainline. > > The goal of the branch is to make the type of GC-allocated objects > known to GC at allocation time, by changing the allocation interface > from > foo *x = (foo *)ggc_alloc (sizeof (x)); > to > foo *x = ggc_alloc_foo (); > > Having this enables further work on GC. Note that it has been prototyped > before: > http://gcc.gnu.org/ml/gcc/2004-01/msg01081.html > > It should not cause any changes in the compiler behavior whatsoever > (except some ggc-zone fixes, see below), except perhaps that > GC-to-obstack changes might improve data locality by a tiny epsilon. > > It comes with a few free extras: > 1) Completes the ggc_alloc* to GGC_NEW* interface transition by moving > away from both. > 2) Partly fixes zone allocator, especially in the presence of PCH. I > am content with "partly" here as I didn't break it and apparently > nobody uses it anyway. > 2) It shakes out a few places where GC shouldn't have been used in the > first place, replaced with obstack allocation. > 3) A few ggc.h and gengtype cleanups. > > A few points of note: > 1) For some types (tree, rtx) it is required to specify allocation > size explicitly. I have introduced a new GTY attribute variable_size > for that. > 2) To handle param_is options, libiberty needs to know how to allocate > using GC interface. Thus I have extended a few libiberty functions to > accept additional memory allocator callback parameters. > > So, if this work is accepted in principle, I will submit to mainline as > follows: > > First the independent parts, which are beneficial without the rest > merged. I will submit them shortly. > > 1) In the loop optimizer, move from GC to obstrack the types struct > lambda_loop_s, lambda_body_vector, lambda_matrix, lambda_trans_matrix. > Needs loop maintainer review. > 2) In the C parser, use obstack for braced initializer list parsing, > moving structs constructor_range_stack, init_node out of GC. Needs C > frontend maintainer review.. > 3) Debugging dump of the structures that gengtype builds and some > minor gengtype cleanups. Right now it is a debugging aid, later it > could be used to do gengtype dump/load that Basile wants for plugins. > Needs global maintainer review. > > And the merge itself. None of the following makes sense without the rest. > > 1) New API in libiberty for creating of hash tables and splay trees > with user-specified callbacks for allocation. Needs libiberty > maintainer review. > 2) Make gengtype accept variable_size GTY option and output typed GC > allocators to gtype-desc.h. Needs global maintainer review. > 3) Split ggc.h into ggc.h and ggc-internal.h, introduce internal > interface for gengtype output to use, fix MEM_STAT accounting, partly > fix zone allocator, partly fix zone allocator interaction with PCH, > and related minor ggc-*.c and stringpool.c changes. It is basically a > ggc.h rewrite from scratch. Needs global, or, I dunno, middle-end > maintainer review. > 4) Annotate several types with variable_size option. Needs all the > front-end maintainers' and middle-end maintainer review, or, maybe > easier, global maintainer review together with the next patch. > 5) Change all the allocation sites. Touches all the frontends, > significant parts of middle ends, and probably all the backends too. > The changes here are mechanical, so it would be easiest to get a > global approval from a global maintainer instead of specific area > maintainers. > 6) GTY documentation update in GCC internals manual. > > Comments? Thanks. Sounds good to me. With a typed interface we should know the alignment requirements of allocations and so can pack objects tighter - do your patches already do that? Basically we pad any object larger than 8 bytes to multiples of 8 bytes even for say objects of size 12 bytes which wastes 50% of the storage as we do not know whether 4 byte alignment is enough. Thanks, Richard. > -- > Laurynas >
Re: Plan for gc-improv merge
2010/4/20 Richard Guenther : > On Mon, Apr 19, 2010 at 4:43 PM, Laurynas Biveinis [...] >> from >> foo *x = (foo *)ggc_alloc (sizeof (x)); >> to >> foo *x = ggc_alloc_foo (); [...] > Sounds good to me. With a typed interface we should know > the alignment requirements of allocations and so can pack > objects tighter - do your patches already do that? No, they don't currently. My goal was to get the API conversion right, then proceed with the further changes. > Basically > we pad any object larger than 8 bytes to multiples of 8 bytes > even for say objects of size 12 bytes which wastes 50% > of the storage as we do not know whether 4 byte alignment > is enough. This should be one of the low hanging fruits once the branch is merged. Thanks, -- Laurynas
RE: branch probabilities on multiway branches
Hi Steven, > There is a transformation implemented in GCC's > value profiling to put the most-frequently taken case-label of a > switch-expr at the top of the switch Could you point me to the bit of code that does this? I'm exploring the idea of implementing source hints much like __builtin_expect which would assign a probability to a case range in a switch construct. I will have to tweak the case expansion phase to implement a similar transformation to the one you mentioned earlier. Cheers, Rahul
Re: GCC 4.5.0 Released
On Mon, Apr 19, 2010 at 09:35:44AM -0400, Jack Howarth wrote: >The annoucement should probably note that targets which lack > objdump currently can't build plugins. I've had about as much > luck getting the patch to fix this... > > http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00610.html > > ...reviewed as you are likely to get this feature announced. > From the responses in the "dragonegg in FSF gcc?" thread, it > is clear that the plugin feature is viewed more as a necessary > evil than a clear win for FSF gcc in some quarters. Perhaps you should ping the original patch, with a CC to the build maintainers in case they missed the patch, or are/were on vacation, or whatever. A simple ping on the original thread would do more good than sniping in an unrelated thread. Speaking only for myself, I also think it's unfortunate that the above impression is the impression that you took away from the "dragonegg in FSF gcc?" thread; I don't think that's a proper reading of the thread at all. -Nathan
gcc-4.4-20100420 is now available
Snapshot gcc-4.4-20100420 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20100420/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.4 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_4-branch revision 158579 You'll find: gcc-4.4-20100420.tar.bz2 Complete GCC (includes all of below) gcc-core-4.4-20100420.tar.bz2 C front end and core compiler gcc-ada-4.4-20100420.tar.bz2 Ada front end and runtime gcc-fortran-4.4-20100420.tar.bz2 Fortran front end and runtime gcc-g++-4.4-20100420.tar.bz2 C++ front end and runtime gcc-java-4.4-20100420.tar.bz2 Java front end and runtime gcc-objc-4.4-20100420.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.4-20100420.tar.bz2The GCC testsuite Diffs from 4.4-20100413 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.4 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: GCC 4.5.0 Released
On 19/04/2010 14:35, Jack Howarth wrote: >The annoucement should probably note that targets which lack > objdump currently can't build plugins. Hey, and non-ELF targets also probably can't, I think. In the absence of a sudden miraculous flood of volunteers, however, it's just going to be up to you and me to fix our favourite platforms. > I've had about as much > luck getting the patch to fix this... > > http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00610.html > > ...reviewed Wait, which patch? > Date: Mon, 12 Apr 2010 21:42:47 -0400 although, to be fair, that's a revision of the one you posted on > Date: Sun, 11 Apr 2010 23:28:19 -0400 So that was right between the release candidate (06/04) and the final release itself (14/04). You can't really hope to get a patch in at that stage, it's just not practical (and come on, you have to accept that goes doubly so for a patch that you had to revise three times in the course of 24 hours to get it right; if that's not the definition of "risky", what is?); we could carry on improving the compiler for ever and never release a new version, but somewhere you've just got to draw a line and ship something sooner or later. That's why it's not just a single release, it's a branch, and that's why there will be a 4.5.1 and that's how we should go about fixing these problems. It's a straightforward-enough release procedure, and I hate it as much as anyone when I miss a deadline and have to stand there on shore with the barrier down watching the boat pull away, but you gotta accept your limitations as a single finite human being and we can't always expect everyone to wait for us minority platforms to catch up. cheers, DaveK
Re: GCC 4.5.0 Released
On Tue, Apr 20, 2010 at 4:52 PM, Dave Korn wrote: > On 19/04/2010 14:35, Jack Howarth wrote: > >> The annoucement should probably note that targets which lack >> objdump currently can't build plugins. > > Hey, and non-ELF targets also probably can't, I think. Actually non-elf targets work with plugins since it is a host feature. Now non elf hosts don't work with plugins :). That currently includes mingw, cygwin and Mac OS X as a host (I think HPUX works though but I have no evidence that it works). That means if I do a cross compiler from GNU/Linux to mingw, plugins work :). Thanks, Andrew Pinski
Re: GCC 4.5.0 Released
On 21/04/2010 00:43, Andrew Pinski wrote: > On Tue, Apr 20, 2010 at 4:52 PM, Dave Korn > wrote: >> On 19/04/2010 14:35, Jack Howarth wrote: >> >>>The annoucement should probably note that targets which lack >>> objdump currently can't build plugins. >> Hey, and non-ELF targets also probably can't, I think. > > Actually non-elf targets work with plugins since it is a host feature. > Now non elf hosts don't work with plugins :). Bah, ya got me! Of course I meant hosts :) cheers, DaveK
Re: Combine or peephole?
On Mon, Apr 19, 2010 at 5:54 PM, Jeff Law wrote: > > combine requires a data dependency, so for this situation, combine isn't > going to help. The easy solution is to create a peephole. You can also > create a machine dependent reorg pass to detect more of these opportunities. > Jeff > Hi Jeff, et al, Thank you for your reply. Two more questions: 1. Is it possible to add a machine dependent reorg pass at backend level without changing the standard infrastructure? If so, can you please point me such example? If no, may the new plugin architecture help here? 2. A peephole for such case just repeats instruction definition pattern. As all information already available for such peephole, wouldn’t it be useful to implement the pass to be a part of the standard infrastructure? Thank you, Frank
