Re: {gSoc}application : Automatic parallelization in Graphite
On Thu, 2009-03-26 at 10:36 +0800, Li Feng wrote: > Hi all, > > Below is the proposal of this gSoc project. I'd really like you review and > comment on this and then I can plan this project better. Hi Li, this looks nice. Thanks for your work on this. Tobias > > Thanks, > Li Feng > > #title Automatic parallelization in Graphite > > * Synopsis > > With the integration of Graphite to GCC4.4, a strong loop nest > analysis and transformation engine was introduced. But now it > does only non-parallel loop generation. My work is to detect > synchronization free parallel loops and generate parallel code > for them, which will mainly enables programs to run faster. > [..] > * Road-map > > 1. Since data dependency analysis is not available, I will firstly > integrate autopar's code generation to Graphite. This work will > be done step by step.(Mid June) > - Introduce a flag -fgraphite-parallelize that forces auto-parallelization > for all loops. > - Make sure the loops Graphite creates can be handled by the autopar's > code generation. > - Call autopar for every loop.(The loops that can not be paralleled will > just fail/crash.) I think on this point we should discuss with Razya and the others where your work ends. Just adapting autopar to handle all graphite loops is a project on its own. So I do not think it can be done by you in two weeks. > 2. Write test cases for the loops that can be parallelized. This will take a > few discussions with Graphite developers to see which kind > of loops we will should detect and can be auto-parallelized.(End June) > 3. Write code for parallel code detection. This part of job will based on > SCoP detection and data dependency, and at this time, data dependency > analysis should have been done. This part of work will take most of > the time.(First week of August) How much time this point takes depends how exact you want to solve it. I think a correct but conservative implementation might be written in a week. If you want to detect all loops it will take you more time. > 4. Code cleaning and write documents.(Second week of August) I think it is useful to define the limits of your work a little bit stricter. For me there are two options: 1. You stay more on the autopar/gimple side (Step 1) and adapt autopar for graphite. This is very necessary for graphite, but it might need some time to get up to speed in autopar. 2. You stay more on the graphite/polyhedral side. You work on all these steps, but we limit step 1 to the graphite internal parts. This means you connect autopar to graphite and try to generate parallel loop nests. If autopar can not handle a loop nest you analyse it and write a bug report. Someone else will extend autopar. As Razya already has some knowlege about autopar and she is also interested in working on parallelization maybe she is able to support you with the autopar stuff? So you might be able to actually focus more on the polyhedral part. > * Profit for GCC > > - When the auto-parallelization has been done in Graphite, developer >can mostly take their effort to loop transformations. Graphite will be >in charge of optimizations(generate parallelism) and the autopar >code in Graphite will just detect and generate code for them. Tobias
[cond-optab] update after first round of testing (results for all targets)
I've finished the first round of testing on all targets and will be sending patches soon. Overall, I think the results are quite satisfying. For the current bunch of files, I get the same code on the following targets: m32c crx mmix xstormy16 fr30 v850 m32r iq2000 picochip mcore spu ia64 m68hc11 alpha frv e500* arm * I'm treating e500 as a different target than powerpc I get the same code except for unordered comparisons, which are improved, on the following targets: mips sparc I get the same code except for small scheduling changes with some option combinations on the following targets: m68k i386 rs6000 I get the same code with small improvements in instruction selection or delay slot scheduling on the following targets: vax avr cris h8300 I get slightly better code because of better optimization (especially if conversion) on the following targets: arc xtensa mn10300 score bfin I get large improvements on the following target: pdp11 I get overall a slight decrease in code quality, which is however offset by patches to expand that I've already posted, on the following targets: pa s390 I have not yet converted sh. I'll do so today. Next step is simulator testing for targets that, well, have a simulator. I'll be posting the target conversion patches soon. Indications about the options that I tested will be found there. The intention is to merge early in stage1 either as a series of commits or just one or anything in the middle. As usual, if people want me to switch to a public branch, just tell me. Paolo
Re: {gSoc}application : Automatic parallelization in Graphite
Hi Tobi, On Thu, Mar 26, 2009 at 3:17 PM, Tobias Grosser wrote: > On Thu, 2009-03-26 at 10:36 +0800, Li Feng wrote: >> Hi all, >> >> Below is the proposal of this gSoc project. I'd really like you review and >> comment on this and then I can plan this project better. > > Hi Li, > > this looks nice. Thanks for your work on this. > > Tobias > >> >> Thanks, >> Li Feng >> >> #title Automatic parallelization in Graphite >> >> * Synopsis >> >> With the integration of Graphite to GCC4.4, a strong loop nest >> analysis and transformation engine was introduced. But now it >> does only non-parallel loop generation. My work is to detect >> synchronization free parallel loops and generate parallel code >> for them, which will mainly enables programs to run faster. >> > [..] > >> * Road-map >> >> 1. Since data dependency analysis is not available, I will firstly >> integrate autopar's code generation to Graphite. This work will >> be done step by step.(Mid June) >> - Introduce a flag -fgraphite-parallelize that forces >> auto-parallelization >> for all loops. >> - Make sure the loops Graphite creates can be handled by the autopar's >> code generation. >> - Call autopar for every loop.(The loops that can not be paralleled will >> just fail/crash.) > > I think on this point we should discuss with Razya and the others where > your work ends. Just adapting autopar to handle all graphite loops is a > project on its own. So I do not think it can be done by you in two > weeks. > >> 2. Write test cases for the loops that can be parallelized. This will take a >> few discussions with Graphite developers to see which kind >> of loops we will should detect and can be auto-parallelized.(End June) >> 3. Write code for parallel code detection. This part of job will based on >> SCoP detection and data dependency, and at this time, data dependency >> analysis should have been done. This part of work will take most of >> the time.(First week of August) > > How much time this point takes depends how exact you want to solve it. I > think a correct but conservative implementation might be written in a > week. If you want to detect all loops it will take you more time. > >> 4. Code cleaning and write documents.(Second week of August) > > I think it is useful to define the limits of your work a little bit > stricter. For me there are two options: > > 1. You stay more on the autopar/gimple side (Step 1) and adapt autopar > for graphite. This is very necessary for graphite, but it might need > some time to get up to speed in autopar. > > 2. You stay more on the graphite/polyhedral side. You work on all these > steps, but we limit step 1 to the graphite internal parts. This means > you connect autopar to graphite and try to generate parallel loop nests. > If autopar can not handle a loop nest you analyse it and write a bug > report. Someone else will extend autopar. > > As Razya already has some knowlege about autopar and she is also > interested in working on parallelization maybe she is able to support > you with the autopar stuff? So you might be able to actually focus more > on the polyhedral part. It's good that Razya do the autopar related job, then I can focus mostly on the polyhedral part. So I think my work will be: 1. detect loops that can be parallel(based on SCoP detection and data dependency test). 2. connect Graphite with autopar part(by Razya) And thanks for your comment :) >> * Profit for GCC >> >> - When the auto-parallelization has been done in Graphite, developer >> can mostly take their effort to loop transformations. Graphite will > > be > >> in charge of optimizations(generate parallelism) and the autopar >> code in Graphite will just detect and generate code for them. > > > > Tobias > > Li Feng
Re: {gSoc}application : Automatic parallelization in Graphite
Hi. I wrote to gcc mail list some time ago about my work on new RPC system. So it has auto-parallelization for functions and uses GCC wrapper compiler to do this job. May be you will find it interesting in repect with your job. Project site is - crpc.sf.net Andrey.
Re: Successfull build of gcc-4.4.0 [trunk revision 145008] on i686-pc-cygwin
Eric Botcazou wrote: >> I have these patches against 4.3.2/4.3.3 that should help with this. >> (Sorry Eric, I've been too busy with the cygwin gcc distro releases to >> start feeding these upstream yet, but they need to wait for 4.5 anyway. >> They're not all in entirely suitable shape yet either.) > > Thanks for stepping in. I thought GNAT could at least be built on cygwin, > but > apparently it cannot anymore. I think that we should try to make it build > again for 4.4 by merging just enough of your changes. > Of the stuff in the previous email, I would reckon that the necessary parts are probably: -ifeq ($(strip $(filter-out cygwin32% mingw32% pe,$(osys))),) +ifeq ($(strip $(filter-out cygwin% mingw% pe,$(osys))),) .. that change to ensure the windows-specific target-pair overrides, and the gsocket.h patch. The sysdep.c changes might also turn out to be required to prevent the build failing at a slightly later stage. Most of the other changes are not suitable for 4.4. (The ADA_CFLAGS->ALL_ADA_CFLAGS and T_ADA_CFLAGS changes are probably entirely superfluous, they were parts of earlier attempts to resolve EH issues which I believe were in fact fixed in their entirety when I figured out to change ZCX_By_Default, but I haven't had time to re-test with them removed yet.) cheers, DaveK
Minimum GMP/MPFR version bumps for GCC-4.5
Hi, I'd like to open the issue of minimum GMP/MPFR versions for gcc-4.5. We currently require gmp-4.1 and mpfr-2.3.0 to build GCC. Part of my motivation is that MPC requires more recent versions of these packages. But also older GMP/MPFR have known bugs and I'd like to encourage upgrading to less ancient versions. E.g. on x86_64-unknown-linux-gnu, you can't even build gmp-4.1.1, it gets some kids of assembler error midway through. So I'd like to bump the minimum required GMP version to 4.2. According to the datestamps in http://ftp.gnu.org/gnu/gmp/ the 4.2.0 package has been out since at least March 2006. It usually takes a year to release GCC so by the time gcc-4.5 is out, gmp-4.2.x will have been available for four years. I'd like to bump MPFR from 2.3.0 to 2.3.1. There are several bugs in the 2.3.0 release that are exposed by the way MPC uses MPFR. Upgrading to version 2.3.1 fixes these issues. MPFR 2.3.0 was released in sept 2007, the 2.3.1 release was available 5 months later in Jan 2008. So by the time gcc-4.5 is out, it will have been released for at least two years. If there are no objections, I'll create a patch. Thanks, --Kaveh -- Kaveh R. Ghazi
Re: Minimum GMP/MPFR version bumps for GCC-4.5
On Thu, Mar 26, 2009 at 10:39 PM, Kaveh R. Ghazi wrote: > If there are no objections, I'll create a patch. P... for those of us who just install the latest-and-greatest fedora/suse/ubuntu/... once and don't change installations for two or three years (stable machine, etc.) it becomes increasingly harder to install all required libraries to build GCC... Is this really necessary? Do those bugs you speak about actually cause trouble for GCC if you make it use MPC (which I'm also not too happy about, fwiw)? Ciao! Steven
Re: Minimum GMP/MPFR version bumps for GCC-4.5
From: "Steven Bosscher" On Thu, Mar 26, 2009 at 10:39 PM, Kaveh R. Ghazi wrote: If there are no objections, I'll create a patch. P... for those of us who just install the latest-and-greatest fedora/suse/ubuntu/... once and don't change installations for two or three years (stable machine, etc.) it becomes increasingly harder to install all required libraries to build GCC... Since GMP-4.2 is three years old, I had hoped it wouldn't be controversial. I can see more of a case for mpfr-2.3.1 being too recent, but it's really just a micro version bump over what we require now. I just checked and ubuntu (v8.10) seems to offer gmp-4.2.2 and mpfr-2.3.2 through it's package manager. What versions of GMP/MPFR do you get on your typical development box and how old are your distros? Is this really necessary? Do those bugs you speak about actually cause trouble for GCC if you make it use MPC (which I'm also not too happy about, fwiw)? I don't know if you can expose these particular bugs through GCC. The issue is that you can definitely see them in MPC through MPC testsuite failures if you e.g. build MPC with mpfr-2.3.0. So MPC has a minimum MPFR version requirement that it checks for during it's own configure time. I don't think it's fair to ask MPC to lower its configure checks for building if real bugs show up in their testsuite. We could keep lower GMP/MPFR version requirements in GCC, but if we hard-require MPC then it's kind of moot cause you'd have to get/build MPC somehow. I'm still open to making MPC optional for a transition period. But others have argued for making it hard-required. There are certainly valid reasons both ways IMHO. But I think that's something for another thread. My hope is that these version upgrades are reasonably simple. --Kaveh
gcc-4.3-20090326 is now available
Snapshot gcc-4.3-20090326 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20090326/ 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/branches/gcc-4_3-branch revision 145096 You'll find: gcc-4.3-20090326.tar.bz2 Complete GCC (includes all of below) gcc-core-4.3-20090326.tar.bz2 C front end and core compiler gcc-ada-4.3-20090326.tar.bz2 Ada front end and runtime gcc-fortran-4.3-20090326.tar.bz2 Fortran front end and runtime gcc-g++-4.3-20090326.tar.bz2 C++ front end and runtime gcc-java-4.3-20090326.tar.bz2 Java front end and runtime gcc-objc-4.3-20090326.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.3-20090326.tar.bz2The GCC testsuite Diffs from 4.3-20090319 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.
Re: Minimum GMP/MPFR version bumps for GCC-4.5
Kaveh R. Ghazi wrote: > What versions of GMP/MPFR do you get on > your typical development box and how old are your distros? > OpenSuSE 10.3 (originally released Oct. 07): gmp-devel-4.2.1-58 gmp-devel-32bit-4.2.1-58 mpfr-2.2.1-45
Re: Minimum GMP/MPFR version bumps for GCC-4.5
Tim Prince wrote: Kaveh R. Ghazi wrote: What versions of GMP/MPFR do you get on your typical development box and how old are your distros? For the RTEMS Project machines we try to stay on fairly recent Fedora versions. All our internal GCC test machines are Fedora 9 or 10 and 10 has this: gmp-devel-4.2.2-8.fc10.i386 gmp-4.2.2-8.fc10.i386 mpfr-2.3.2-1.fc10.i386 Fedora 9 has: gmp-devel-4.2.2-7.fc9.x86_64 gmp-4.2.2-7.fc9.x86_64 mpfr-2.3.1-1.fc9.x86_64 Fedora 9 was released in May 2008. --joel
Re: Minimum GMP/MPFR version bumps for GCC-4.5
On Thu, Mar 26, 2009 at 05:11:04PM -0700, Joel Sherrill wrote: > Tim Prince wrote: > > Kaveh R. Ghazi wrote: > > > > > >> What versions of GMP/MPFR do you get on > >> your typical development box and how old are your distros? > >> > >> > For the RTEMS Project machines we try to stay > on fairly recent Fedora versions. All our internal GCC > test machines are Fedora 9 or 10 and 10 has this: > > gmp-devel-4.2.2-8.fc10.i386 > gmp-4.2.2-8.fc10.i386 > mpfr-2.3.2-1.fc10.i386 > > Fedora 9 has: > gmp-devel-4.2.2-7.fc9.x86_64 > gmp-4.2.2-7.fc9.x86_64 > mpfr-2.3.1-1.fc9.x86_64 > > Fedora 9 was released in May 2008. Debian stable, and Ubuntu Hardy (most recent LTS release) have 2.3.1. Same with OpenSUSE 11.0. So I think 2.3.1 is typical of current stable releases; Fedora tends to be bleeding edge and not typical. I still have to deal with older distros (e.g. RHEL 4), but it's already necessary to use newer gmp and gas versions, as well as a newer mpfr version, in that case. I do see that FreeBSD Ports has mpfr 2.4.1. How advanced of them.
Re: Minimum GMP/MPFR version bumps for GCC-4.5
Joe Buck wrote: On Thu, Mar 26, 2009 at 05:11:04PM -0700, Joel Sherrill wrote: Tim Prince wrote: Kaveh R. Ghazi wrote: What versions of GMP/MPFR do you get on your typical development box and how old are your distros? For the RTEMS Project machines we try to stay on fairly recent Fedora versions. I still have to deal with older distros (e.g. RHEL 4), but it's already necessary to use newer gmp and gas versions, as well as a newer mpfr version, in that case. For the RTEMS's toolchain packages on such "stagnating OSes", we resort to bundling "sufficiently recent enough" mpfr/gmp-source tarballs with the GCC-sources and building them "in-GCC-source-tree" instead of using the host provided system-libs. One ends up with GCC being statically linked against these libmpfr/gmp's on such OSes. I do see that FreeBSD Ports has mpfr 2.4.1. How advanced of them. Amazing :-() Ralf
