Re: GCC & OpenCL ?
> I am just starting to think about adding OpenCL support into future versions > of > GCC, as it looks like a useful way of programming highly parallel type > systems, > particularly with hetrogeneous processors. At this point, I am wondering what > kind of interest people have in working together on OpenCL in the GCC > compiler? I might be working on parallelization (though in LLVM) for the next one or two years. If I have some free time to put into GCC, I'd love to port my work to it and to collaborate with people already working on OpenCL. > Off hand, I think the first stage is to get OpenCL to work in a homogeneous > multi-core system before diving into the hetrogeneous systems. Yes, also because for example we have no access to the GPUs' instruction set. These papers details an experience in porting CUDA (the predecessor to OpenCL) to multicore systems: http://www.gigascale.org/pubs/1278.html http://www.gigascale.org/pubs/1417.html http://impact.crhc.illinois.edu/mcuda.php Paolo
GCC 4.3.3 Released
The GNU Compiler Collection version 4.3.3 has been released. GCC 4.3.3 is a bug-fix release containing fixes for regressions and serious bugs in GCC 4.3.2. This release is available from the FTP servers listed at: http://www.gnu.org/order/ftp.html Please do not contact me directly regarding questions or comments about this release. Instead, use the resources available from http://gcc.gnu.org. As always, a vast number of people contributed to this GCC release -- far too many to thank individually! -- Richard Guenther Novell / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 - GF: Markus Rex
Troika'09::BOTS-AI Programming Challenge
Hello everyone, The wait is finally over! The problem statement of BOTS: AI programming challenge event of Troika'09 - The annual technical fest organised by IEEE, Delhi College of Engineering (DCE) has been released. Register yourself for the event and download the Problem Statement from: www.troika.dcetech.com The competition requires you to program your code to play a game against an opponent code according to the rules defined. Hope you have fun participating. Organisers, BOTS'09 b...@dcetech.com -- View this message in context: http://www.nabble.com/Troika%2709%3A%3ABOTS-AI-Programming-Challenge-tp21774289p21774289.html Sent from the gcc - Dev mailing list archive at Nabble.com.
GCC for mipsel-unknown-linux-gnu state on 4.3 and 4.4?
Hi, On the C side there's a bunch of gcc.dg/pch failures on mipsel-unknown-linux-gnu on trunk 143818: http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg00069.html FAIL: gcc.dg/pch/common-1.c -O0 -g -I. (test for excess errors) FAIL: gcc.dg/pch/common-1.c -O0 -g assembly comparison FAIL: gcc.dg/pch/common-1.c -O0 -I. (test for excess errors) ... Executing on host: /n/pc2/guerby/build-143818/gcc/xgcc -B/n/pc2/guerby/build-143818/gcc/ ./common-1.h -O0 -g -o common-1.h.gch (timeout = 300) PASS: ./common-1.h -O0 -g (test for excess errors) Executing on host: /n/pc2/guerby/build-143818/gcc/xgcc -B/n/pc2/guerby/build-143818/gcc/ /home/guerby/work/trunk/gcc/testsuite/gcc.dg/pch/common-1.c -O0 -g -I. -S -o common-1.s(timeout = 300) xgcc: Internal error: Segmentation fault (program cc1) Please submit a full bug report. Pasting the command is not enough so I'm unable to provide a backtrace. Advice welcome, I'll then open a PR. Before my testresult I could find only trunk 140564 in september 2008 with a patch by David Daney then no more testresults: http://gcc.gnu.org/ml/gcc-testresults/2008-09/msg02009.html I could'nt find any 4.3 result on mipsel posted on gcc-testresults (?). GCC 4.2.4 doesn't seem to have those pch FAIL: http://gcc.gnu.org/ml/gcc-testresults/2009-01/msg01914.html Same for 4.1.3: http://gcc.gnu.org/ml/gcc-testresults/2009-01/msg01913.html And 3.4.6: http://gcc.gnu.org/ml/gcc-testresults/2008-10/msg02151.html Any idea? Thanks in advance, Laurent
Re: GCC & OpenCL ?
Paolo Bonzini wrote: I am just starting to think about adding OpenCL support into future versions of GCC, as it looks like a useful way of programming highly parallel type systems, particularly with hetrogeneous processors. At this point, I am wondering what kind of interest people have in working together on OpenCL in the GCC compiler? I might be working on parallelization (though in LLVM) for the next one or two years. If I have some free time to put into GCC, I'd love to port my work to it and to collaborate with people already working on OpenCL. Although the OpenCL infrastructure doesn't confine itself to it, this compute-on-the-graphic-processor type of parallellism mostly concerns itself with "let's do the FFT (or DGEMM) really fast on this processor and then return to the user". That works if the performance of your program is dominated by the performance of the FFTs (DGEMMs) inside it. If it isn't (surely not for us meteorology types) this approach is of limited use. -- Toon Moene - e-mail: t...@moene.org (*NEW*) - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/ Progress of GNU Fortran: http://gcc.gnu.org/gcc-4.4/changes.html
Re: GCC for mipsel-unknown-linux-gnu state on 4.3 and 4.4?
Laurent GUERBY writes: > Hi, > > On the C side there's a bunch of gcc.dg/pch failures on > mipsel-unknown-linux-gnu > on trunk 143818: > > http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg00069.html > > FAIL: gcc.dg/pch/common-1.c -O0 -g -I. (test for excess errors) > FAIL: gcc.dg/pch/common-1.c -O0 -g assembly comparison > FAIL: gcc.dg/pch/common-1.c -O0 -I. (test for excess errors) > ... > > Executing on host: /n/pc2/guerby/build-143818/gcc/xgcc > -B/n/pc2/guerby/build-143818/gcc/ ./common-1.h -O0 -g -o common-1.h.gch > (timeout = 300) > PASS: ./common-1.h -O0 -g (test for excess errors) > Executing on host: /n/pc2/guerby/build-143818/gcc/xgcc > -B/n/pc2/guerby/build-143818/gcc/ > /home/guerby/work/trunk/gcc/testsuite/gcc.dg/pch/common-1.c -O0 -g -I. -S > -o common-1.s(timeout = 300) > xgcc: Internal error: Segmentation fault (program cc1) > Please submit a full bug report. It passes with a cross compiler, or at least did for me a fortnight ago. > Before my testresult I could find only trunk 140564 > in september 2008 with a patch by David Daney then no more testresults: > > http://gcc.gnu.org/ml/gcc-testresults/2008-09/msg02009.html FWIW, here are mips64el-linux-gnu results from 2009-01-15. Richard === gcc tests === Target: qemu64el/-mabi=32 FAIL: gcc.dg/pr35729.c scan-rtl-dump-times loop2_invariant "Decided to move invariant" 0 # of expected passes50670 # of unexpected failures1 # of expected failures 123 # of unsupported tests 470 Target: qemu64el/-mabi=64 FAIL: gcc.dg/pr35729.c scan-rtl-dump-times loop2_invariant "Decided to move invariant" 0 # of expected passes50684 # of unexpected failures1 # of expected failures 124 # of unsupported tests 463 Target: qemu64el/-mabi=n32 FAIL: gcc.dg/pr35729.c scan-rtl-dump-times loop2_invariant "Decided to move invariant" 0 # of expected passes50670 # of unexpected failures1 # of expected failures 123 # of unsupported tests 472 Target: qemu64el/-mips16/-mabi=32 FAIL: gcc.c-torture/compile/20001226-1.c -O0 (test for excess errors) FAIL: gcc.dg/pr35729.c scan-rtl-dump-times loop2_invariant "Decided to move invariant" 0: dump file does not exist FAIL: gcc.dg/tree-prof/stringop-2.c scan-tree-dump tree_profile "Single value 4 stringop" # of expected passes50515 # of unexpected failures3 # of expected failures 121 # of unsupported tests 517 === gcc summary === # of expected passes202539 # of unexpected failures6 # of expected failures 491 # of unsupported tests 1922 === gfortran tests === Target: qemu64el/-mabi=32 FAIL: gfortran.dg/widechar_4.f90 -O0 execution test FAIL: gfortran.dg/widechar_select_1.f90 -O0 execution test FAIL: gfortran.dg/widechar_select_1.f90 -O1 execution test FAIL: gfortran.dg/widechar_select_1.f90 -O2 execution test FAIL: gfortran.dg/widechar_select_1.f90 -O3 -fomit-frame-pointer execution test FAIL: gfortran.dg/widechar_select_1.f90 -O3 -fomit-frame-pointer -funroll-loops execution test FAIL: gfortran.dg/widechar_select_1.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test FAIL: gfortran.dg/widechar_select_1.f90 -O3 -g execution test FAIL: gfortran.dg/widechar_select_1.f90 -Os execution test # of expected passes28188 # of unexpected failures9 # of expected failures 10 # of unsupported tests 254 Target: qemu64el/-mabi=64 # of expected passes28627 # of expected failures 10 # of unsupported tests 44 Target: qemu64el/-mabi=n32 FAIL: gfortran.dg/widechar_4.f90 -O3 -g execution test FAIL: gfortran.dg/widechar_select_1.f90 -O0 execution test FAIL: gfortran.dg/widechar_select_1.f90 -O1 execution test FAIL: gfortran.dg/widechar_select_1.f90 -O2 execution test FAIL: gfortran.dg/widechar_select_1.f90 -O3 -fomit-frame-pointer execution test FAIL: gfortran.dg/widechar_select_1.f90 -O3 -fomit-frame-pointer -funroll-loops execution test FAIL: gfortran.dg/widechar_select_1.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test FAIL: gfortran.dg/widechar_select_1.f90 -O3 -g execution test FAIL: gfortran.dg/widechar_select_1.f90 -Os execution test # of expected passes28618 # of unexpected failures9 # of expected failures 10 # of unsupported tests 44 Target: qemu64el/-mips16/-mabi=32 FAIL: gfortran.dg/widechar_select_1.f90 -O0 execution test FAIL: gfortran.dg/widechar_select_1.f90 -O1 execution test FAIL: gfortran.dg/widechar_select_1.f90 -O2 execution test FAIL: gfortran.dg/widechar_select_1.f90 -O3 -fomit-frame-pointer
Re: GCC & OpenCL ?
On Feb 1, 2009, at 5:41 AM, Toon Moene wrote: I am just starting to think about adding OpenCL support into future versions of GCC, as it looks like a useful way of programming highly parallel type systems, particularly with hetrogeneous processors. At this point, I am wondering what kind of interest people have in working together on OpenCL in the GCC compiler? I might be working on parallelization (though in LLVM) for the next one or two years. If I have some free time to put into GCC, I'd love to port my work to it and to collaborate with people already working on OpenCL. Although the OpenCL infrastructure doesn't confine itself to it, this compute-on-the-graphic-processor type of parallellism mostly concerns itself with "let's do the FFT (or DGEMM) really fast on this processor and then return to the user". This was true a year or two ago, but isn't really true any more. Current GPUs are (almost) completely programmable and the trend is obviously continuing towards greater generality. If you have a data parallel problem, they can be an excellent solution. GPUs are also fully IEEE compatible now as well. OTOH, compiling for them is non-trivial ;-) If it isn't (surely not for us meteorology types) this approach is of limited use. If you are limited by flops and memory bandwidth and your problems can be tiled, GPUs can be extremely nice. -Chris
Re: GCC & OpenCL ?
> Although the OpenCL infrastructure doesn't confine itself to it, this > compute-on-the-graphic-processor type of parallellism mostly concerns > itself with "let's do the FFT (or DGEMM) really fast on this processor > and then return to the user". Not really, it's not about FFT/DGEMM only -- the parallel stuff can be expressed in a high-level language, and the communication cost is actually something you have to consider seriously. > If it isn't (surely not for us meteorology types) this approach is of > limited use. I'm pretty sure you meteorology guys can benefit quite from it. Paolo
Re: GCC Plug-in Framework ready to port
On Sat, Jan 31, 2009 at 17:49, Taras Glek wrote: > Why not start the branch with the API as is described and then change it as > people find problems with it. I am guessing we should converge on an API > that the majority of users are happy with fairly quickly. Yes, that's why I suggested using that as the base. > Where would plugin-centric enhancements such as improvements to the pass > manager go? i think it'd be useful to have them land in the plugin branch to > make sure the API is satisfactory. How about /gcc/plugins/? Maybe we could categorize the 'plugins' directory, but I don't think it makes sense to apply too much hierarchy this early in the game. > Indeed. As a maintainer of a couple gcc plugins and a corresponding API, > what can I do to help out? I want to start with the API patches first. Sean has posted a separate thread with feedback on the API. I will create the branch by the end of next week and start accepting API patches. While I would like to achieve some broad consensus on each patch, I don't want to make this too bureaucratic, we can refine the implementation as we go along. How does that sound? Diego.
Re: GCC Plug-in Framework ready to port
On Sun, 1 Feb 2009, Diego Novillo wrote: > > Where would plugin-centric enhancements such as improvements to the pass > > manager go? i think it'd be useful to have them land in the plugin branch to > > make sure the API is satisfactory. > > How about /gcc/plugins/? Maybe we could categorize > the 'plugins' directory, but I don't think it makes sense to apply too > much hierarchy this early in the game. I don't see how that answer relates to the question. The question "Where" seemed to me to be asking "On what branch", and the plugin branch seems find - but so does trunk once 4.4 has branched. As plugin-centric enhancements as described seem to be changes to existing GCC source code (providing infrastructure of potential use to multiple plugins), they don't have a single plugin-name, so the path you gave doesn't make sense as a path within the GCC source code. It might make sense for a path within the GCC source code to plugins distributed with GCC, however. As for installation directories, I've already noted that plugins should be installed under libsubdir or libexecsubdir since they will depend on both the target and version of GCC. -- Joseph S. Myers jos...@codesourcery.com
make install and gettext
This applies to GCC 4.2 on AIX 5.3 but probably applies elsewhere as well. If gettext is installed, then gcc builds differently. (That is not surprising.) gettext depends upon expat and expat depends upon libgcc_s.a. So there is a circle of dependancies. Again, all this is already known. I was trying to determine what files are installed with "make install" with each of these packages. I am creating AIX installp images for these. So, I configured, compiled and installed them all in an iterative approach until they all built completely. Then I removed all of /usr/local and did "make install" inside expat, gcc, and gettext. It turns out that the install of gettext rebuilds some libraries so it must be installed last. I took note of the files added or altered in each step. I then, half by accident, did make install in the gcc directory and discovered that it installed 100 some more files. To summaries: (cd expat ; make install ) << installed 6 files) (cd gcc ; make install ) << installed 600+ files (cd gettext ; make install ) << installed 1500+ files (cd gcc ; make install ) << installed 777 files total (100+ more than the first time). These are not the message files. All the new files are in these directories (or sub directories): /usr/local/include/c++/4.2.0/powerpc-ibm-aix5.3.0.0/ppc64 /usr/local/include/c++/4.2.0/powerpc-ibm-aix5.3.0.0/pthread /usr/local/include/c++/4.2.0/powerpc-ibm-aix5.3.0.0/pthread/ppc64 /usr/local/lib/ppc64 /usr/local/lib/pthread /usr/local/lib/pthread/ppc64 I doubt if this is deliberate. I have gone back and removed all of the gcc files and did make install after gettext is installed, and it installed all 777 files. So, it is not an iterative problem. There must be something in the makefile that assumes if some piece of gettext is not installed, the extra 100+ files are not needed. I hope all that makes sense. Perry Ease Software, Inc. ( http://www.easesoftware.com ) Low cost SATA Disk Systems for IBMs p5, pSeries, and RS/6000 AIX systems
Re: GCC Plug-in Framework ready to port
On Sun, Feb 1, 2009 at 13:50, Joseph S. Myers wrote: > As plugin-centric enhancements as described seem to be changes to existing > GCC source code (providing infrastructure of potential use to multiple > plugins), they don't have a single plugin-name, so the path you gave > doesn't make sense as a path within the GCC source code. It might make > sense for a path within the GCC source code to plugins distributed with > GCC, however. Yes, that's the path I was describing; plugins distributed with GCC. I don't expect we'll have more than a small number of them. Mostly as examples. > As for installation directories, I've already noted that plugins should be > installed under libsubdir or libexecsubdir since they will depend on both > the target and version of GCC. Agreed. We'll also need some convention for the API header files. Diego.
Re: GCC Plug-in Framework ready to port
On Sun, 1 Feb 2009, Diego Novillo wrote: > > As for installation directories, I've already noted that plugins should be > > installed under libsubdir or libexecsubdir since they will depend on both > > the target and version of GCC. > > Agreed. We'll also need some convention for the API header files. Those will also depend on both target and version; somewhere under libsubdir also probably works for them (the configure macros provided by GCC for plugin writers can deal with finding them for users). They'll also need to include some generated files (for example, plugins are bound to need to know the configured HOST_WIDE_INT, which depends on NEED_64BIT_HOST_WIDE_INT, even if anyone manages to separate cleanly those cases that are about the host from those relating more to the target). -- Joseph S. Myers jos...@codesourcery.com
[AVX]: Update x86-64 psABI for aggregates with __m256
Hi,
We like to update x86-64 psABI to pass aggregates of 32 bytes with
single __m256 field
in AVX registers, instead of memory. However, finding the proper
wording seems tricky.
Here is what I got. Any comments?
Thanks.
--
H.J.
Index: low-level-sys-info.tex
===
--- low-level-sys-info.tex (revision 5099)
+++ low-level-sys-info.tex (working copy)
@@ -343,10 +343,12 @@ classes are corresponding to \xARCH regi
\begin{description}
\item[INTEGER] This class consists of integral types that fit into one of
the general purpose registers.
-\item[SSE] The class consists of types that fit into a SSE register.
-\item[SSEUP] The class consists of types that fit into a SSE register
+\item[SSE] The class consists of types that fit into an SSE register.
+\item[SSEUP] The class consists of types that fit into an SSE register
+ and can be passed and returned in the most significant half of it.
+\item[AVX] The class consists of types that fit into an AVX register.
+\item[AVXUP] The class consists of types that fit into an AVX register
and can be passed and returned in the most significant half of it.
-\item[AVX] The class consists of types that fit into a AVX register.
\item[X87, X87UP] These classes consists of types that will be returned via
the x87 FPU.
\item[COMPLEX\_X87] This class consists of types that will be returned
@@ -372,7 +374,9 @@ The basic types are assigned their natur
\item Arguments of types \code{__float128}, \code{_Decimal128}
and \code{__m128} are split into two halves. The least significant
ones belong to class SSE, the most significant one to class SSEUP.
-\item Arguments of type \code{__m256} are in class AVX.
+\item Arguments of type \code{__m256} are split into into two halves.
+ The least significant ones belong to class AVX, the most significant
+ one to class AVXUP.
\item The 64-bit mantissa of arguments of type \code{long double}
belongs to class X87, the 16-bit exponent plus 6 bytes of padding
belongs to class X87UP.
@@ -407,11 +411,10 @@ The classification of aggregate (structu
types works as follows:
\begin{enumerate}
-\item If the size of an object is larger than two \eightbytes, or
- it contains unaligned fields, it has class MEMORY.
+\item If it contains unaligned fields, it has class MEMORY.
\item If a C++ object has either a non-trivial copy constructor
-or a non-trivial destructor
+or a non-trivial destructor,
\footnote{A de/constructor is trivial if it is an implicitly-declared
default de/constructor and if:
\begin{itemize}
@@ -433,6 +436,15 @@ types works as follows:
because such objects must have well defined addresses. Similar
issues apply when returning an object from a function.}
+\item If the size of the aggregate is four \eightbytes, two
+ consecutive \eightbytes are classified as an aggregate of two
+ \eightbytes. If the first of two \eightbytes aggregates has the
+ AVX class, it is broken into the SSE and SSEUP classes for
+ class merge purpose.
+
+\item If the size of an object is larger than two \eightbytes,
+ it has class MEMORY.
+
\item If the size of the aggregate exceeds a single \eightbyte, each is
classified separately. Each \eightbyte gets initialized to class NO_CLASS.
@@ -453,6 +465,8 @@ types works as follows:
\begin{enumerate}
\item If one of the classes is MEMORY, the whole argument is passed in
memory.
\item If SSEUP is not preceeded by SSE, it is converted to SSE.
+ \item If AVXUP is preceeded by SSE, the SSE class is converted to AVX.
+ \item If AVXUP is not preceeded by AVX, it is converted to AVX.
\end{enumerate}
\end{enumerate}
Re: GCC for mipsel-unknown-linux-gnu state on 4.3 and 4.4?
Laurent GUERBY schrieb: > Before my testresult I could find only trunk 140564 > in september 2008 with a patch by David Daney then no more testresults: > > http://gcc.gnu.org/ml/gcc-testresults/2008-09/msg02009.html > > I could'nt find any 4.3 result on mipsel posted on gcc-testresults (?). > > GCC 4.2.4 doesn't seem to have those pch FAIL: > http://gcc.gnu.org/ml/gcc-testresults/2009-01/msg01914.html > > Same for 4.1.3: > http://gcc.gnu.org/ml/gcc-testresults/2009-01/msg01913.html > > And 3.4.6: > http://gcc.gnu.org/ml/gcc-testresults/2008-10/msg02151.html Sorry, didn't notice this. The build logs of the mips*-linux logs were not uploaded, because of the size of the logs (all 64bit tests failing). You can find these now at http://people.debian.org/~doko/tmp/gcc-mips/ Arthur Loiret did want to have a look why these fail (the Debian build is patched to build a triarch compiler). Matthias
Re: GCC for mipsel-unknown-linux-gnu state on 4.3 and 4.4?
On Sun, 2009-02-01 at 22:14 +0100, Matthias Klose wrote: > Laurent GUERBY schrieb: > > Before my testresult I could find only trunk 140564 > > in september 2008 with a patch by David Daney then no more testresults: > > > > http://gcc.gnu.org/ml/gcc-testresults/2008-09/msg02009.html > > > > I could'nt find any 4.3 result on mipsel posted on gcc-testresults (?). > > > > GCC 4.2.4 doesn't seem to have those pch FAIL: > > http://gcc.gnu.org/ml/gcc-testresults/2009-01/msg01914.html > > > > Same for 4.1.3: > > http://gcc.gnu.org/ml/gcc-testresults/2009-01/msg01913.html > > > > And 3.4.6: > > http://gcc.gnu.org/ml/gcc-testresults/2008-10/msg02151.html > > Sorry, didn't notice this. The build logs of the mips*-linux logs were not > uploaded, because of the size of the logs (all 64bit tests failing). You can > find these now at http://people.debian.org/~doko/tmp/gcc-mips/ > Arthur Loiret did want to have a look why these fail (the Debian build is > patched to build a triarch compiler). Thanks for the link! This confirms that all pch test fail on mipsel, from the first to the last log available on your site: http://people.debian.org/~doko/tmp/gcc-mips/gcc-snapshot_20080523-1_mipsel.bz2 http://people.debian.org/~doko/tmp/gcc-mips/gcc-snapshot_20090107-1_mipsel.bz2 FAIL: ./common-1.h -O0 -g (test for excess errors) FAIL: gcc.dg/pch/common-1.c -O0 -g FAIL: gcc.dg/pch/common-1.c -O0 -g assembly comparison FAIL: ./common-1.h -O0 (test for excess errors) FAIL: gcc.dg/pch/common-1.c -O0 FAIL: gcc.dg/pch/common-1.c -O0 assembly comparison ... Whereas they don't fail for 4.3. I opened: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39071 Laurent
Re: Solve transitive closure issue in modulo scheduling
"Bingfeng Mei" wrote on 30/01/2009 14:44:01: > Hello, > I try to make modulo scheduling work more efficiently for our VLIW target. I > found one serious issue that prevents current SMS algorithm from achieving > high IPC is so-called "transitive closure" problem, where scheduling window is > only calculated using direct predecessors and successors. Because SMS is not > an iterative algorithm, this may cause failures in finding a valid schedule. Agreed. > Without splitting rows, some simple loops just cannot be scheduled not matter > how big the II is. With splitting rows, schedule can be found, but only at > bigger II. It may happen that even splitting rows will not help, e.g. when we repeatedly end up with a node having negative sched window. > GCC wiki (http://gcc.gnu.org/wiki/SwingModuloScheduling) lists this > as a TODO. Is there any work going on about this issue No, not to my knowledge. We had some testcase where this showed up, hence its appearance in the TODO, but afaicr some change caused it to disappear. > (the last wiki update > was one year ago)? If no one is working on it, I plan to do it. My idea is to > use the MinDist algorithm described in B. Rau's classic paper "iterative > modulo scheduling" (http://www.hpl.hp.com/techreports/94/HPL-94-115.html). The > same algorithm can also be used to compute better RecMII. The biggest concern > is complexity of computing MinDist matrix, which is O(N^3). N is number of > nodes in the loop. I remember somewhere GCC coding guide says "never write > quadratic algorithm" :-) Is this an absolute requirement? If yes, I will keep > it as our target-specific code (we are less concerned about compilation time). > Otherwise, I will try to make it more generic to see if it can make into > mainline in 4.5. Any comments? > The problem appears only when the DDG is cyclic, and for every cycle in the DDG, the problem may arise when trying to schedule the last node of the cycle, which has both predecessors and successors already scheduled. So you might try to connect only each such predecessor to every such successor with a transitive arc, to ensure that this last node will have a non-empty scheduling window. But this might not suffice; you may eventually need to wire (nearly) every pair of nodes in the strongly connected component. If this happens, you'd be better off with a dense graph representation (incidence matrix) than the current sparse one (adjaceny lists). An example would help see things more clearly. If you have a (small :) DDG demonstrating the need for transitive arcs, I'd be happy to have a look and advise what should be done. Ayal. > Cheers, > Bingfeng Mei > > Broadcom UK > >
Re: GCC Plug-in Framework ready to port
On Sun, 2009-02-01 at 14:26 -0500, Diego Novillo wrote: > Yes, that's the path I was describing; plugins distributed with GCC. > I don't expect we'll have more than a small number of them. Mostly as > examples. The usual problem with example plugins is that they stop working. It would be nice if they were built and tested as part of the usual build process (and `make check'), but not installed. Ben
Re: MIPS64 -msym32 and DWARF2_ADDR_SIZE
Richard Sandiford writes: > How about the patch below? I'll apply it in the next couple of days > if there are no objections. Thanks for patch. I also like the new comments you added. Adam
