problems with -fdump-tree options (gcc 4.1.2)
Hi, I tried the following: gcc-fdump-tree-all example.c, and i got these files: example.c.t00.tu , example.c.t02.original , example.c.t03.gimple , example.c.t06.vcg , I have two questions: How can i get example.c.original rather than example.c.t02.original? What does the symbol "t0x" stand for? Thanks a lot! Tony.
Successfull build of gcc-4.4.0 [trunk revision 145008] on i686-pc-cygwin
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Compiler version: 4.4.0 20090323 (experimental) [trunk revision 145008] (GCC) Platform: i686-pc-cygwin configure flags: --prefix=/opt/devel/gnu/gcc/gcc-4.4.0/i686-pc-cygwin - --with-gmp=/opt/devel/gnu/gcc/gcc-4.4.0/i686-pc-cygwin - --with-mpfr=/opt/devel/gnu/gcc/gcc-4.4.0/i686-pc-cygwin --with-gnu-as - --with-as=/opt/devel/gnu/gcc/gcc-4.4.0/i686-pc-cygwin/bin/as.exe --with-gnu-ld - --with-ld=/opt/devel/gnu/gcc/gcc-4.4.0/i686-pc-cygwin/bin/ld.exe - --enable-bootstrap --enable-checking=release --enable-threads=posix - --enable-languages=c,ada,c++,fortran,java,objc,obj-c++ --enable-libgomp binutils: binutils-2.19.51.20090323 Build system: CYGWIN_NT-5.2-WOW64 kasandra 1.5.25(0.156/4/2) 2008-06-12 19:34 i686 Cygwin cc for building: gcc-4.4.0-20090323 gcc (GCC) 4.4.0 20090323 (experimental) [trunk revision 145008] Copyright (C) 2009 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. as for building: GNU assembler (GNU Binutils) 2.19.51.20090323 Copyright 2008 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or later. This program has absolutely no warranty. This assembler was configured for a target of \`i686-pc-cygwin'. ld for building: GNU ld (GNU Binutils) 2.19.51.20090323 Copyright 2008 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) a later version. This program has absolutely no warranty. testresults: http://gcc.gnu.org/ml/gcc-testresults/2009-03/msg02525.html Over all it looks not to bad. For the acats tests most of the FAIL cases ar of the form: violation of restriction "NO_IMPLICIT_DYNAMIC_CODE" at system.ads:44 The same is true for the gnat tests. gcc tests show several ICEs: gcc.c-torture/compile/20001226-1.c with optimization different than -O0 gcc.c-torture/compile/limits-declparen.c with optimization -O3 gcc.c-torture/compile/limits-exprparen.c gcc.c-torture/compile/limits-pointer.c -O3 -g -w gcc.dg/20020425-1.c -ansi -pedantic-errors -S gcc.dg/pch/largefile.c Hope that helps to improve further. Cheers, Rainer -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknKAT0ACgkQoUhjsh59BL5ezACdFdsWTewJyZq3POBT1d4325ca QgwAni4G7UJi7loTJRSfkUby8x0oJelc =HJcw -END PGP SIGNATURE-
Re: Successfull build of gcc-4.4.0 [trunk revision 145008] on i686-pc-cygwin
> For the acats tests most of the FAIL cases ar of the form: > violation of restriction "NO_IMPLICIT_DYNAMIC_CODE" at system.ads:44 This very likely means that the compiler is misconfigured. Try to replace "cygwin32" with "cygwin" in ada/gcc-interface/Makefile.in and rebuild the runtime (make all-target-libada). -- Eric Botcazou
Re: Successfull build of gcc-4.4.0 [trunk revision 145008] on i686-pc-cygwin
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eric Botcazou schrieb: >> For the acats tests most of the FAIL cases ar of the form: >> violation of restriction "NO_IMPLICIT_DYNAMIC_CODE" at system.ads:44 > > This very likely means that the compiler is misconfigured. Try to replace > "cygwin32" with "cygwin" in ada/gcc-interface/Makefile.in and rebuild the > runtime (make all-target-libada). > Will try that in the evening. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEUEARECAAYFAknKDxkACgkQoUhjsh59BL7i9ACWIOLYIsEL77j/zpGmXNYDrlrH /wCeKXxB6UlIReKn7qAnjNJmqwPFfgc= =fbZA -END PGP SIGNATURE-
Register Allocation Bug?
Hi List
(Sorry for the cross-post in gcc-bugs, I didn't look properly at the
list before I posted).
I have a question (or possible compiler bug) regarding inline assembly
that I hope you can help me with.
I wanted a routine that would give me the value and address of a
memory location relative to the stack pointer. What I initially tried
was the following:
#define ESP(rel,value,addr) \
asm volatile ("mov (%%esp, %2, 4), %0\n\t" \
"lea (%%esp, %2, 4), %1\n\t" \
: "=r" (value), "=r" (addr) \
: "r" (rel)); \
It didn't work as expected so I looked at the assembler code generated
for the above:
1: b8 00 00 00 00 mov$0x0,%eax
2: 8b 04 84mov(%esp,%eax,4),%eax
3: 8d 14 84lea(%esp,%eax,4),%edx
4: 89 45 f8mov%eax,0xfff8(%ebp)
5: 89 55 fcmov%edx,0xfffc(%ebp)
As it turns out, %eax is being used for both input and output in line
2, clobbering %eax, so of course line 3 does not give the expected
result... Is this a compiler error? I thought the only way the same
register would be used for both input and output was if you use the
"0" constraint? I'm compiling with 'GCC 4.2.1 20070719'.
The best solution I found was to split the two assembler statements in
the following way:
#define ESP(rel,value,addr) \
asm volatile ("movl (%%esp, %1, 4), %0\n\t" : \
"=r" (value) : "r" (rel));\
asm volatile ("lea (%%esp, %1, 4), %0\n\t" : \
"=r" (addr) : "r" (rel));
The above compiles into six instructions instead of five (duplicating
mov $0x0,%eax) but is has the benefit of only using one register:
1: b8 00 00 00 00 mov$0x0,%eax
2: 8b 04 84mov(%esp,%eax,4),%eax
3: 89 45 fcmov%eax,0xfffc(%ebp)
4: b8 00 00 00 00 mov$0x0,%eax
5: 8d 04 84lea(%esp,%eax,4),%eax
6: 89 45 f0mov%eax,0xfff0(%ebp)
So, again, my question is this: Is the compiler doing what it's
supposed to when it's assigning the same register to both input and
output when the specified constraint is "r" and not "0"?
As far as I can tell this problem have been floating around for a
number of years. The following post from 2000 describes exactly the
same issue:
http://gcc.gnu.org/ml/gcc-bugs/2000-07/msg00456.html
Since it hasn't been fixed maybe it's a bu..*ahem*..feature?
Best
/Kasper
Re: Register Allocation Bug?
Kasper Bonne wrote: > > Since it hasn't been fixed maybe it's a bu..*ahem*..feature? It's a feature. Look up "earlyclobber" in the Fine Manual. Andrew.
Re: Should structure with flexible array be allowed to be passed by value?
On Tue, Mar 24, 2009 at 10:46 AM, Dave Korn
wrote:
> Brian Ellis wrote:
>> struct dynamic { int size; int array[]; };
>
>> int main() { struct dynamic * pBadness = ((struct dynamic *) malloc(
>> sizeof(int) * 3) );
>
>> dont_do_this( *pBadness );
>
>
> Are you even allowed to dereference a pointer to a struct containing a VLA?
> Should it be treated like an incomplete type in this respect?
>
gcc.c-torture/compile/pr16566-2.c has
---
struct A
{
int i;
int x[];
};
int foo(struct A a)
{
return (a,a).x[0];
}
---
foo will return a random number. I don't think it should be allowed.
H.J.
Re: Should structure with flexible array be allowed to be passed by value?
On Wed, 25 Mar 2009, H.J. Lu wrote:
> gcc.c-torture/compile/pr16566-2.c has
>
> ---
> struct A
> {
> int i;
> int x[];
> };
>
> int foo(struct A a)
> {
> return (a,a).x[0];
> }
> ---
>
> foo will return a random number. I don't think it should be allowed.
This is a perfectly ordinary case of accessing outside array bounds,
undefined behavior at runtime if the code in question is ever executed but
OK in a program as long as the dereference isn't executed.
--
Joseph S. Myers
jos...@codesourcery.com
Re: Register Allocation Bug?
Hi Andrew On Wed, Mar 25, 2009 at 12:41, Andrew Haley wrote: >> Since it hasn't been fixed maybe it's a bu..*ahem*..feature? > > It's a feature. Look up "earlyclobber" in the Fine Manual. I tried that already and it does work but I actually thought the 'earlyclobber' modifier was for situations when the compiler couldn't otherwise know that a register would be, well, clobbered early. E.g., when using 'rdtsc' or other instructions that modify a specific set of registers. In my example the compiler should be able to figure out that the register is not available for output (because it is used as input in the following line), so if this behavior is not a bug, it should be. IMO. The wording in the description of digit constraints (like "0") lead me to believe that without such a constraint, the same register would not be used for both input and output... but OK, it doesn't say that explicitly. Anyway, thanks for you answer... On a side note, the assembler for your proposal is the following: 1: b8 00 00 00 00 mov$0x0,%eax 2: 8b 0c 84mov(%esp,%eax,4),%ecx 3: 8d 14 84lea(%esp,%eax,4),%edx 4: 89 c8 mov%ecx,%eax 5: 89 45 fcmov%eax,0xfffc(%ebp) 6: 89 55 f0mov%edx,0xfff0(%ebp) What is the point of line 4? Why not just: 1: b8 00 00 00 00 mov$0x0,%eax 2: 8b 0c 84mov(%esp,%eax,4),%ecx 3: 8d 14 84lea(%esp,%eax,4),%edx 4: 89 45 fcmov%ecx,0xfffc(%ebp) 5: 89 55 f0mov%edx,0xfff0(%ebp) So at least there is still room for optimizations. Best /Kasper
Re: Should structure with flexible array be allowed to be passed by value?
On Wed, Mar 25, 2009 at 6:37 AM, Joseph S. Myers
wrote:
> On Wed, 25 Mar 2009, H.J. Lu wrote:
>
>> gcc.c-torture/compile/pr16566-2.c has
>>
>> ---
>> struct A
>> {
>> int i;
>> int x[];
>> };
>>
>> int foo(struct A a)
>> {
>> return (a,a).x[0];
>> }
>> ---
>>
>> foo will return a random number. I don't think it should be allowed.
>
> This is a perfectly ordinary case of accessing outside array bounds,
> undefined behavior at runtime if the code in question is ever executed but
> OK in a program as long as the dereference isn't executed.
Shouldn't gcc warn out of bound array access here?
--
H.J.
Re: Register Allocation Bug?
Kasper Bonne writes: > In my example the compiler should be able to figure out that the > register is not available for output (because it is used as input in > the following line), so if this behavior is not a bug, it should > be. IMO. This thread should really be on gcc-h...@gcc.gnu.org, not g...@gcc.gnu.org. Please take any followups to gcc-help. The string in an asm statement is just that: a string. The compiler does not analyze or parse it in any way, other than to process % substitutions. Ian
Re: Successfull build of gcc-4.4.0 [trunk revision 145008] on i686-pc-cygwin
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eric Botcazou schrieb: >> For the acats tests most of the FAIL cases ar of the form: >> violation of restriction "NO_IMPLICIT_DYNAMIC_CODE" at system.ads:44 > > This very likely means that the compiler is misconfigured. Try to replace > "cygwin32" with "cygwin" in ada/gcc-interface/Makefile.in and rebuild the > runtime (make all-target-libada). > that gives an bootstrap failure: g-socthi.adb:534:15: "WSASYSNOTREADY" is undefined g-socthi.adb:535:15: "WSAVERNOTSUPPORTED" is undefined g-socthi.adb:537:15: "WSANOTINITIALISED" is undefined g-socthi.adb:539:15: "WSAEDISCON" is undefined g-socthi.adb:546:15: duplication of choice value at line 494 make[6]: *** [g-socthi.o] Error 1 make[6]: Leaving directory `/home/rainer/software/build/i686-pc-cygwin/gcc/gcc/ada/rts' make[5]: *** [gnatlib] Error 2 make[5]: Leaving directory `/home/rainer/software/build/i686-pc-cygwin/gcc/gcc/ada' make[4]: *** [gnatlib-shared-win32] Error 2 make[4]: Leaving directory `/home/rainer/software/build/i686-pc-cygwin/gcc/gcc/ada' make[3]: *** [gnatlib-shared] Error 2 make[3]: Leaving directory `/home/rainer/software/build/i686-pc-cygwin/gcc/gcc/ada' make[2]: *** [gnatlib-shared] Error 2 make[2]: Leaving directory `/home/rainer/software/build/i686-pc-cygwin/gcc/i686-pc-cygwin/libada' make[1]: *** [all-target-libada] Error 2 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknKWvYACgkQoUhjsh59BL5EZQCghGptRJ15WCtztI0W0gcFI7Bt bscAoKQlzGtlnTAHtK1GWF9mtsWGv1oA =PF7B -END PGP SIGNATURE-
Re: Successfull build of gcc-4.4.0 [trunk revision 145008] on i686-pc-cygwin
Rainer Emrich wrote:
> Eric Botcazou schrieb:
>>> For the acats tests most of the FAIL cases ar of the form:
>>> violation of restriction "NO_IMPLICIT_DYNAMIC_CODE" at system.ads:44
>> This very likely means that the compiler is misconfigured. Try to replace
>> "cygwin32" with "cygwin" in ada/gcc-interface/Makefile.in and rebuild the
>> runtime (make all-target-libada).
>>
> that gives an bootstrap failure:
> g-socthi.adb:534:15: "WSASYSNOTREADY" is undefined
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.)
cheers,
DaveK
--- origsrc/gcc-4.3.3/gcc/ada/Makefile.in 2008-02-13 19:04:53.0 +
+++ src/gcc-4.3.3/gcc/ada/Makefile.in 2009-03-06 07:14:26.56250 +
@@ -198,6 +198,10 @@
# Type of tools build we are doing; default is not compiling tools.
TOOLSCASE =
+# Which install goal to use.
+INSTALL_GNATLIB_MAIN = install-gnatlib
+INSTALL_GNATLIB_WIN32 = unused-install-gnatlib
+
# End of variables for you to override.
all: all.indirect
@@ -273,7 +277,7 @@
$(CC) -c -x assembler $< $(OUTPUT_OPTION)
.c.o:
- $(CC) -c $(ALL_CFLAGS) $(ADA_CFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) $< \
+ $(CC) -c $(ALL_CFLAGS) $(ALL_ADA_CFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) $< \
$(OUTPUT_OPTION)
.adb.o:
@@ -1298,7 +1302,7 @@
LIBRARY_VERSION := $(subst .,_,$(LIB_VERSION))
endif
-ifeq ($(strip $(filter-out cygwin32% mingw32% pe,$(osys))),)
+ifeq ($(strip $(filter-out cygwin% mingw% pe,$(osys))),)
LIBGNAT_TARGET_PAIRS = \
a-dirval.adb
+
+int
+__gnat_is_windows_xp (void)
+{
+ static int is_win_xp=0, is_win_xp_checked=0;
+
+ if (!is_win_xp_checked)
+{
+ OSVERSIONINFO version;
+
+ is_win_xp_checked = 1;
+
+ memset (&version, 0, sizeof (version));
+ version.dwOSVersionInfoSize = sizeof (version);
+
+ is_win_xp = GetVersionEx (&version)
+&& version.dwPlatformId == VER_PLATFORM_WIN32_NT
+&& (version.dwMajorVersion > 5
+|| (version.dwMajorVersion == 5 && version.dwMinorVersion >= 1));
+}
+ return is_win_xp;
+}
+
+#endif /* __CYGWIN__ */
+
#ifdef VMS
/* This gets around a problem with using the old threads library on VMS 7.0. */
--- origsrc/gcc-4.3.3/gcc/ada/system-mingw.ads 2007-12-19 16:22:26.0 +
+++ src/gcc-4.3.3/gcc/ada/system-mingw.ads 2009-03-06 07:14:26.59375 +
@@ -141,7 +141,7 @@
Always_Compatible_Rep : constant Boolean := True;
Suppress_Standard_Library : constant Boolean := False;
Use_Ada_Main_Program_Name : constant Boolean := False;
- ZCX_By_Default: constant Boolean := False;
+ ZCX_By_Default: constant Boolean := True;
GCC_ZCX_Support : constant Boolean := True;
---
--- origsrc/gcc-4.3.3/gcc/testsuite/ada/acats/run_all.sh 2006-09-14 11:12:03.0 +0100
+++ src/gcc-4.3.3/gcc/testsuite/ada/acats/run_all.sh 2009-03-06 07:14:26.68750 +
@@ -13,7 +13,7 @@
gnatflags="-gnatws"
target_run () {
-$*
+ $testdir/run_test.exp $1 > $2 2>&1
}
# End of customization section.
@@ -99,7 +99,7 @@
# Find out the size in bit of an address on the target
target_gnatmake $testdir/support/impbit.adb >> $dir/acats.log 2>&1
-target_run $dir/support/impbit > $dir/support/impbit.out 2>&1
+target_run $dir/support/impbit $dir/support/impbit.out
target_bit=`cat $dir/support/impbit.out`
echo target_bit="$target_bit" >> $dir/acats.log
@@ -276,7 +276,7 @@
if [ ! -x $dir/tests/$chapter/$i/$binmain ]; then
sync
fi
- target_run $dir/tests/$chapter/$i/$binmain > $dir/tests/$chapter/$i/${i}.log 2>&1
+ target_run $dir/tests/$chapter/$i/$binmain $dir/tests/$chapter/$i/${i}.log
cd $dir/tests/$chapter/$i
cat ${i}.log >> $dir/acats.log
egrep -e '( |\+\+\+\+ |\!\!\!\! )' ${i}.log > /dev/null 2>&1
--- origsrc/gcc-4.3.3/gcc/testsuite/ada/acats/run_test.exp 1970-01-01 00:00:00.0 +
+++ src/gcc-4.3.3/gcc/testsuite/ada/acats/run_test.exp 2009-03-06 07:14:26.68750 +
@@ -0,0 +1,10 @@
+#!/usr/bin/expect -f
+
+set timeout 300
+
+spawn -noecho $argv
+expect timeout {
+ send_user "Program timed out.\n"
+ exit 1
+}
+
Re: Successfull build of gcc-4.4.0 [trunk revision 145008] on i686-pc-cygwin
> 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. -- Eric Botcazou
Re: Google Summer of Code 2009
Hi Pranav, On Tue, 2009-03-24 at 23:32 +0530, Pranav wrote: > Hi Sebastian and Tobias, [...] > To delve deeper into compiler's research I will be joining the graduate > school at UIUC from next Fall. I feel that working on this project would > give me great pleasure and it would be the best way I could have ever > spent my long vacations. I think we can implement most of the classical > optimizations - loop permutation, loop fusion / fission, strip mining, > etc in the summers. As I do not know what all optimizations are expected > to be covered in the project could you please help me with the problem > before I write my project proposal. It is great to hear from you and thank you for this interesting introduction of yourself. As it seems that you are interested in some optimizations based on the polyhedral model, I added two new projects to the Graphite Google Summer of Code ideas page (http://gcc.gnu.org/wiki/Graphite/SoC). I think both might be interesting for you. If you are interested in one of these feel free to ask any question, so we can find out together what you might want to cover in your Google Summer of Code application See you Tobias
gcc-4.2-20090325 is now available
Snapshot gcc-4.2-20090325 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20090325/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.2 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_2-branch revision 145077 You'll find: gcc-4.2-20090325.tar.bz2 Complete GCC (includes all of below) gcc-core-4.2-20090325.tar.bz2 C front end and core compiler gcc-ada-4.2-20090325.tar.bz2 Ada front end and runtime gcc-fortran-4.2-20090325.tar.bz2 Fortran front end and runtime gcc-g++-4.2-20090325.tar.bz2 C++ front end and runtime gcc-java-4.2-20090325.tar.bz2 Java front end and runtime gcc-objc-4.2-20090325.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.2-20090325.tar.bz2The GCC testsuite Diffs from 4.2-20090318 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.2 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.
{gSoc}application : Automatic parallelization in Graphite
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.
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.
* The Project
In GCC there already exists an auto-parallelization pass, but it
can't works on some not-simple loops.
e.g. The following code can't be handled by autopar, which yields
a scev_not_known dependency.
int Z[100][100];
int main(void)
{
int i,j;
for (i = 0; i <= 10; i++)
for (j = 0; j <=10; j++)
Z[i][j] = Z[j+10][i+11];
return 0;
}
I made some experimental work on "What kind of loops can
autopar handle and what it can't" ,you can find it here:
http://gcc.gnu.org/wiki/AutoparRelated.
Graphite can analyze every loop, condition that can be analyzed
by polyhedral analysis, and even complicated loop nests.
Under Graphite, we could detect synchronization free parallel
loops and generate parallel code for them. During Google Summer
of Code, I want to solve the two issues.
First of all, I will write test cases for different kind of loops
that can be parallelized under Graphite. This work will be done
by some discussions about data dependency analysis under polyhedral
model with Graphite developers.
The first issue will be parallel loop detection. This means that
Graphite will recognize simple parallel loops using SCoP detection
and data dependency analysis. SCoP detection is well supported
by Graphite and Konrad Trifunic is now working on data dependency
analysis based on polyhedral model, which will be done about 3-4
weeks.
The place for parallel loop detection will be after CLOOG generate
the new loops, either CLAST(cloog AST after call cloog on polyhedra)
or after clast_to_gimple. At this time as we have the polyhedral
information (poly_bb_p) still available during code generation, we
can try to update the dependency information using the restrictions
CLOOG added and the polyhedral dependency analysis to check if there
is any dependency in the generated loops.
So the basic step of parallel loop detection will be:
1. Get the poly_bb_p after CLOOG
2. Check that if there are dependencies.
3. If dependency doesn't exist, mark the loop as parallel. We may
add annotations of more detailed information here. e.g.
shared/private objects.
The second issue will be parallel code generation. At this part,
I will try to integrate autopar's code generation to Graphite. This
work will be done precisely after cloog_to_gimple. I will make sure
that the loops Graphite creates can be handled by the autopar's
code generation. Currently the autopar pass in GCC lower the
OMP_FOR and OMP_PARALLEL to libgomp functions. Still, maybe we
could call autopar's reduction analysis, if the scalar analysis
determines that the loop is still parallelizable, then the code
generation will be called.
* Success Criteria
1. Graphite can recognize and mark loops that can be parallelized
2. Graphite will generate parallelized code for them
3. Pass test cases for Graphite's auto-parallelization
* 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.)
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)
4. Code cleaning and write documents.(Second week of August)
* Profit for GCC
- When the auto-parallelization has been done in Graphite, developer
can mostly take their effort to loop transformations. Graphite will
in charge of optimizations(generate parallelism) and the autopar
code in Graphite will just detect and generate code for them.
