Re: *_ALIGN_MAX_SKIP macros
DJ Delorie writes: > JUMP_ALIGN_MAX_SKIP > LABEL_ALIGN_AFTER_BARRIER_MAX_SKIP > LOOP_ALIGN_MAX_SKIP > LABEL_ALIGN_MAX_SKIP > > None of these macros take any parameters, but for optimal performance > on RX, it's key to match the max_skip with the size of the following > opcode - there's a penalty only if you branch to an opcode which spans > fetch groups, but it's the same penalty as running a NOP opcode, so > you don't want to add nops if you don't have to. > > Can we extend those macros to take the label as a parameter? From > that, the backend could find the next actual insn. Seems fine to me. Looks like none of the existing targets define them directly anyhow. If you do this, though, turn them into target hooks. They are currently fields in target_flag_state. Ian
Re: Improvement of vectorization on loops generated by Graphite
On Tue, Jul 27, 2010 at 21:09, Jack Howarth wrote: > When do you think we may start to see the vectorizations in > Gr1 exceed those from Gr0? I know at least of one case http://gcc.gnu.org/PR43423 that is still not vectorized and that would benefit of the -fgraphite-identity (that does iteration domain splitting). I am also working on a techniques for aggressive if-conversion of nested loops using Graphite. On all these cases, I have to make sure that the code produced by Graphite can be vectorized. > Will that required upgrading to the newer cloog? Not necessarily. At one point in time I would like to stop maintaining the CLooG-PPL branch and switch completely to CLooG.org. That will probably happen in the 4.7 timeline, if we can show that CLooG.org is stable and produces better code by then. > Jack > ps If the vectorizations using -fgraphite-identity eventually reaches > parity with those without that option, would -fgraphite-identity > become defaulted on for gcc builds with graphite support > (assuming minimal compile time increases)? We'll have to show the benefits of turning that flag on. Sebastian
Re: Improvement of vectorization on loops generated by Graphite
On Tue, Jul 27, 2010 at 06:47:53PM -0500, Sebastian Pop wrote: > Hi, > > I ran the following script to gather data with trunk (from 20100615) > and Graphite branch (today). > > for i in `ls -1 *.f90`; do > echo -n $i > $FC $OPT -c ./$i &> out > grep "LOOP VECTORIZED" out | wc > done > > The following columns correspond to the number of lines reported by wc. > > Trunk0: OPT="-ftree-vectorizer-verbose=2 -O3 -ffast-math" > Trunk1: OPT="-ftree-vectorizer-verbose=2 -O3 -ffast-math -fgraphite-identity" > Gr0: OPT="-ftree-vectorizer-verbose=2 -O3 -ffast-math" > Gr1: OPT="-ftree-vectorizer-verbose=2 -O3 -ffast-math > -fgraphite-identity -fno-loop-strip-mine -fno-loop-interchange > -fno-loop-block" > > Trunk0 Trunk1 Gr0 Gr1 > ac.f9030 30 29 29 > aermod.f90151 110 147 147 > air.f90 4 3 4 4 > capacita.f90 17 11 13 13 > channel.f90 15 14 14 14 > doduc.f90 155 146 155 155 > fatigue.f90 15 15 15 15 > gas_dyn.f90 44 42 41 41 > induct.f909 5 5 5 > linpk.f90 14 3 14 14 > mdbx.f90 12 8 12 12 > nf.f9051 34 50 50 > protein.f90 31 31 31 31 > rnflow.f9087 75 85 85 > test_fpu.f90 80 65 78 78 > tfft.f90 4 3 4 4 > > Overall, with the recent changes that I pushed to the Graphite branch > and that should be stable by now, we improved the vectorization of > loops generated by Graphite. > > The improvements in today's Graphite branch Gr1 with respect to > Trunk1, that is trunk with -fgraphite-identity are the difference > between Gr1 and Trunk1 (higher is more loops vectorized by Gr1): > > ac.f90-1 > aermod.f9037 > air.f90 1 > capacita.f90 2 > channel.f90 0 > doduc.f90 9 > fatigue.f90 0 > gas_dyn.f90 -1 > induct.f900 > linpk.f90 11 > mdbx.f90 4 > nf.f9016 > protein.f90 0 > rnflow.f9010 > test_fpu.f90 13 > tfft.f90 1 > > There still are some missed vectorization cases, see the difference > between Trunk0 and Gr0: > > ac.f901 > aermod.f904 > air.f90 0 > capacita.f90 4 > channel.f90 1 > doduc.f90 0 > fatigue.f90 0 > gas_dyn.f90 3 > induct.f904 > linpk.f90 0 > mdbx.f90 0 > nf.f901 > protein.f90 0 > rnflow.f902 > test_fpu.f90 2 > tfft.f90 0 > Sebastian, When do you think we may start to see the vectorizations in Gr1 exceed those from Gr0? Will that required upgrading to the newer cloog? Jack ps If the vectorizations using -fgraphite-identity eventually reaches parity with those without that option, would -fgraphite-identity become defaulted on for gcc builds with graphite support (assuming minimal compile time increases)? > After these changes are merged to trunk, we should revisit the > following PRs: > > http://gcc.gnu.org/PR38846: 35% slower using -floop* than without graphite > http://gcc.gnu.org/PR40979: induct benchmark 60% slower when compiled > with -fgraphite > http://gcc.gnu.org/PR43359: gas_dyn benchmark exhibits missed > vectorization with graphite > > Sebastian Pop > -- > AMD / Open Source Compiler Engineering / GNU Tools
GCC RM Q&A: August 5th
Joseph Myers, Richard Guenther, and I will be hosting the second GCC Release Manager Q&A on Thursday, August 5th at 9:00 AM Pacific Daylight Time. (Jakub Jelinek is unfortunately unable to attend.) As before, feel free to put questions that you would like to ask on this Wiki page: if you will be unable to attend, and we will try to address those questions during the Q&A session. We very much appreciated everyone's participation during the previous session, and look forward to doing it again! Gerald, would you please update the web site as you see fit (if at all)? Thanks, -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Improvement of vectorization on loops generated by Graphite
Hi, I ran the following script to gather data with trunk (from 20100615) and Graphite branch (today). for i in `ls -1 *.f90`; do echo -n $i $FC $OPT -c ./$i &> out grep "LOOP VECTORIZED" out | wc done The following columns correspond to the number of lines reported by wc. Trunk0: OPT="-ftree-vectorizer-verbose=2 -O3 -ffast-math" Trunk1: OPT="-ftree-vectorizer-verbose=2 -O3 -ffast-math -fgraphite-identity" Gr0: OPT="-ftree-vectorizer-verbose=2 -O3 -ffast-math" Gr1: OPT="-ftree-vectorizer-verbose=2 -O3 -ffast-math -fgraphite-identity -fno-loop-strip-mine -fno-loop-interchange -fno-loop-block" Trunk0 Trunk1 Gr0 Gr1 ac.f90 30 30 29 29 aermod.f90 151 110 147 147 air.f90 4 3 4 4 capacita.f9017 11 13 13 channel.f90 15 14 14 14 doduc.f90 155 146 155 155 fatigue.f90 15 15 15 15 gas_dyn.f90 44 42 41 41 induct.f90 9 5 5 5 linpk.f90 14 3 14 14 mdbx.f9012 8 12 12 nf.f90 51 34 50 50 protein.f90 31 31 31 31 rnflow.f90 87 75 85 85 test_fpu.f9080 65 78 78 tfft.f904 3 4 4 Overall, with the recent changes that I pushed to the Graphite branch and that should be stable by now, we improved the vectorization of loops generated by Graphite. The improvements in today's Graphite branch Gr1 with respect to Trunk1, that is trunk with -fgraphite-identity are the difference between Gr1 and Trunk1 (higher is more loops vectorized by Gr1): ac.f90 -1 aermod.f90 37 air.f90 1 capacita.f902 channel.f90 0 doduc.f90 9 fatigue.f90 0 gas_dyn.f90 -1 induct.f90 0 linpk.f90 11 mdbx.f904 nf.f90 16 protein.f90 0 rnflow.f90 10 test_fpu.f9013 tfft.f901 There still are some missed vectorization cases, see the difference between Trunk0 and Gr0: ac.f90 1 aermod.f90 4 air.f90 0 capacita.f904 channel.f90 1 doduc.f90 0 fatigue.f90 0 gas_dyn.f90 3 induct.f90 4 linpk.f90 0 mdbx.f900 nf.f90 1 protein.f90 0 rnflow.f90 2 test_fpu.f902 tfft.f900 After these changes are merged to trunk, we should revisit the following PRs: http://gcc.gnu.org/PR38846: 35% slower using -floop* than without graphite http://gcc.gnu.org/PR40979: induct benchmark 60% slower when compiled with -fgraphite http://gcc.gnu.org/PR43359: gas_dyn benchmark exhibits missed vectorization with graphite Sebastian Pop -- AMD / Open Source Compiler Engineering / GNU Tools
gcc-4.4-20100727 is now available
Snapshot gcc-4.4-20100727 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20100727/ 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 162610 You'll find: gcc-4.4-20100727.tar.bz2 Complete GCC (includes all of below) gcc-core-4.4-20100727.tar.bz2 C front end and core compiler gcc-ada-4.4-20100727.tar.bz2 Ada front end and runtime gcc-fortran-4.4-20100727.tar.bz2 Fortran front end and runtime gcc-g++-4.4-20100727.tar.bz2 C++ front end and runtime gcc-java-4.4-20100727.tar.bz2 Java front end and runtime gcc-objc-4.4-20100727.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.4-20100727.tar.bz2The GCC testsuite Diffs from 4.4-20100720 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: GFDL/GPL issues
Richard Guenther wrote: > Why not just ignore RMS and the license issues and simply do what we > think suits us and the project. Let the FSF deal with the legal consequences, > they put us in this messy situation, they deal with it. We should not distribute things in violation of their licenses; that would be both unethical and legally actionable. And, worse yet, we should not induce third parties to take that kind of legal risk. At this point, the manuals are GFDL and the code is GPL; we can't mix them. I suppose we could ask contributors to expressly permit their GPL'd contributions to be licensed under the GFDL, but that's not terribly useful unless we can get some dispensation for the existing code. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: GFDL/GPL issues
On Tue, 27 Jul 2010, Benjamin Kosnik wrote: > Please, members of the SC, make this case. Done. I, too, find the removal of freedoms that the incompatible GNU licenses (GPLv2 vs GPLv3, GPL vs GFDL,...) create rather unacceptable. Gerald
Re: GFDL/GPL issues
On Tue, Jul 27, 2010 at 8:09 PM, Mark Mitchell wrote: > Joe Buck wrote: > >> We might need to go in the other direction (less radical, but enough to >> solve the immediate problem). What if only constraints files are >> dual-licensed (GPL3+ or GFDL) for now? Then documentation can be >> generated from them and we've at least solved that problem. If RMS agrees >> to that and sees that the world doesn't end, maybe he'll be open later on >> to opening this door wider. > > It would be a bit frustrating to have to do this piecemeal, but half a > loaf is better than nothing. It's certainly fine with me if you want to > suggest that on the SC list -- not that you need my permission! Why not just ignore RMS and the license issues and simply do what we think suits us and the project. Let the FSF deal with the legal consequences, they put us in this messy situation, they deal with it. Richard.
*_ALIGN_MAX_SKIP macros
JUMP_ALIGN_MAX_SKIP LABEL_ALIGN_AFTER_BARRIER_MAX_SKIP LOOP_ALIGN_MAX_SKIP LABEL_ALIGN_MAX_SKIP None of these macros take any parameters, but for optimal performance on RX, it's key to match the max_skip with the size of the following opcode - there's a penalty only if you branch to an opcode which spans fetch groups, but it's the same penalty as running a NOP opcode, so you don't want to add nops if you don't have to. Can we extend those macros to take the label as a parameter? From that, the backend could find the next actual insn.
Re: GFDL/GPL issues
Joe Buck wrote: > We might need to go in the other direction (less radical, but enough to > solve the immediate problem). What if only constraints files are > dual-licensed (GPL3+ or GFDL) for now? Then documentation can be > generated from them and we've at least solved that problem. If RMS agrees > to that and sees that the world doesn't end, maybe he'll be open later on > to opening this door wider. It would be a bit frustrating to have to do this piecemeal, but half a loaf is better than nothing. It's certainly fine with me if you want to suggest that on the SC list -- not that you need my permission! -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: GFDL/GPL issues
On Tue, Jul 27, 2010 at 08:53:48AM -0700, Mark Mitchell wrote: > I believe that the right fix (short of simply abandoning the GFDL, which > would be fine with me, but is presumably not going to pass muster with > RMS) is a revision to the GPL that explicitly permits relicensing GPL'd > content under the GFDL, by anyone. Movement in that direction should > not be of concern to the FSF; the point of the GFDL was to prevent > people removing the FSF's philosophical statements in its manuals, not > to prevent GPL'd content from being used in manuals. RMS already rejected the idea of dual-licensing just GCC (GPL/GFDL) to deal with this problem, now you're asking to effectively dual-license all GCC (v3.1?) code that way. Even if he would be willing to consider it (which I doubt), he'd want to have attorneys examine all the legal consequences so another year will go by. We might need to go in the other direction (less radical, but enough to solve the immediate problem). What if only constraints files are dual-licensed (GPL3+ or GFDL) for now? Then documentation can be generated from them and we've at least solved that problem. If RMS agrees to that and sees that the world doesn't end, maybe he'll be open later on to opening this door wider.
Re: GFDL/GPL issues
Benjamin Kosnik wrote: >> I believe that the right fix (short of simply abandoning the GFDL, >> which would be fine with me, but is presumably not going to pass >> muster with RMS) is a revision to the GPL that explicitly permits >> relicensing GPL'd content under the GFDL, by anyone. > I like the sound of this proposed solution and agree fully with your > intent to get back to a more workable state for documentation > production and creation. I've made the case on the SC list. RMS has thus far not responded directly to this suggestion, but thus far has not seemed terribly concerned about the inability to move things between code and documentation. A few of the other SC members have weighed in, but it would certainly be helpful if more would do so. Thanks, -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: GFDL/GPL issues
> I believe that the right fix (short of simply abandoning the GFDL, > which would be fine with me, but is presumably not going to pass > muster with RMS) is a revision to the GPL that explicitly permits > relicensing GPL'd content under the GFDL, by anyone. Movement in > that direction should not be of concern to the FSF; the point of the > GFDL was to prevent people removing the FSF's philosophical > statements in its manuals, not to prevent GPL'd content from being > used in manuals. I like the sound of this proposed solution and agree fully with your intent to get back to a more workable state for documentation production and creation. The simple plan as outlined above is frankly much easier to explain and understand than these autogen GPL-index + GFDL content machinations. That is unworkable IMHO. Please, members of the SC, make this case. -benjamin
Re: onlinedocs/libstdc++ appears stale
> gcc.gnu.org will be preferrable, I think. That allows a number of us > to help out if neede, re-running scripts, etc. Right. The Makefiles are set up for this now. > For the time being I suggest to apply the patch below, though. What > we have in place as of today simply is broken (and has been for > quarters, at a minimum). > > Objections? OK -benjamin
Re: GFDL/GPL issues
Robert Dewar wrote: >> I'm disappointed that a license "improvement" (changing GPL to GFDL on >> manuals) has made it impossible to do something that we, as developers, >> used to be able to do (when documentation was under the GPL we could >> move things back and forth between code and documentation at will), and >> which benefited users (by making it easier for us to generate better >> documentation). > > I agree that it is essential to be able to do this kind of movement > backwards and forwards. Would you like to contact RMS about this? He doesn't seem to think that it's important, let alone essential. His suggestion is that we do this in the FSF repository (where we can explicitly make such license changes), but of course that denies that same freedom to third parties. RMS has proposed a script that regenerates GFDL'd documentation from GPL'd code. But, that is not sufficient because I can regenerate the GFDL'd manual after I change GPL'd code (my changes can be licensed as I see fit), but I cannot regenerate the GFDL'd manual after *you* change GPL'd code if you have not regenerated the GFDL'd manual. I believe that the right fix (short of simply abandoning the GFDL, which would be fine with me, but is presumably not going to pass muster with RMS) is a revision to the GPL that explicitly permits relicensing GPL'd content under the GFDL, by anyone. Movement in that direction should not be of concern to the FSF; the point of the GFDL was to prevent people removing the FSF's philosophical statements in its manuals, not to prevent GPL'd content from being used in manuals. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
