Re: [GSoC] Elimination of CLooG library installation dependency
Thank you for the report! (1) FAIL: gcc.dg/graphite/vect-pr43423.c scan-tree-dump-times vect vectorized 2 loops 1 before I saw [Book15] f90/bug% grep vectorized vect-pr43423.c.114t.vect /opt/gcc/p_work/gcc/testsuite/gcc.dg/graphite/vect-pr43423.c:14:17: note: === vect_mark_stmts_to_be_vectorized === /opt/gcc/p_work/gcc/testsuite/gcc.dg/graphite/vect-pr43423.c:14:17: note: loop vectorized /opt/gcc/p_work/gcc/testsuite/gcc.dg/graphite/vect-pr43423.c:12:17: note: === vect_mark_stmts_to_be_vectorized === /opt/gcc/p_work/gcc/testsuite/gcc.dg/graphite/vect-pr43423.c:12:17: note: loop vectorized /opt/gcc/p_work/gcc/testsuite/gcc.dg/graphite/vect-pr43423.c:6:6: note: vectorized 2 loops in function. after I see [Book15] f90/bug% grep vectorized vect-pr43423.c.115t.vect /opt/gcc/p_work/gcc/testsuite/gcc.dg/graphite/vect-pr43423.c:14:17: note: not vectorized: not suitable for gather load _55 = a[_56]; /opt/gcc/p_work/gcc/testsuite/gcc.dg/graphite/vect-pr43423.c:12:17: note: not vectorized: not suitable for gather load _36 = a[_37]; /opt/gcc/p_work/gcc/testsuite/gcc.dg/graphite/vect-pr43423.c:6:6: note: vectorized 0 loops in function. We’ve already met with this problem. https://gcc.gnu.org/ml/gcc-patches/2014-08/msg00118.html https://gcc.gnu.org/ml/gcc-patches/2014-08/msg00155.html https://gcc.gnu.org/ml/gcc-patches/2014-08/msg00173.html In our opinion, it requires help of the vectorizer people. Maybe it’ll disappear by itself, when the computation of types is finished. (2) FAIL: gfortran.dg/graphite/pr42393.f90 -O (internal compiler error) FAIL: gfortran.dg/graphite/pr42393.f90 -O (test for excess errors) The backtrace is * thread #1: tid = 0x13bd91f, 0x7fff8621aca0 libsystem_malloc.dylib`tiny_malloc_from_free_list + 12, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=2, address=0x7fff5bc00ff8) frame #0: 0x7fff8621aca0 libsystem_malloc.dylib`tiny_malloc_from_free_list + 12 libsystem_malloc.dylib`tiny_malloc_from_free_list + 12: - 0x7fff8621aca0: pushq %rbx 0x7fff8621aca1: pushq %rax 0x7fff8621aca2: movl %edx, %r12d 0x7fff8621aca5: movq %rsi, %r14 (lldb) bt * thread #1: tid = 0x13bd91f, 0x7fff8621aca0 libsystem_malloc.dylib`tiny_malloc_from_free_list + 12, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=2, address=0x7fff5bc00ff8) * frame #0: 0x7fff8621aca0 libsystem_malloc.dylib`tiny_malloc_from_free_list + 12 frame #1: 0x7fff8621b3c3 libsystem_malloc.dylib`szone_malloc_should_clear + 320 frame #2: 0x7fff8621d868 libsystem_malloc.dylib`malloc_zone_malloc + 71 frame #3: 0x7fff8621e27c libsystem_malloc.dylib`malloc + 42 frame #4: 0x000141dbdc79 libgmp.10.dylib`__gmp_default_allocate + 9 frame #5: 0x000141dd0148 libgmp.10.dylib`__gmpz_init + 24 frame #6: 0x000141c180ef libisl.10.dylib`isl_basic_map_normalize_constraints + 47 frame #7: 0x000141c18f04 libisl.10.dylib`isl_basic_map_simplify + 68 frame #8: 0x000141c2509b libisl.10.dylib`isl_basic_set_preimage + 619 frame #9: 0x000141c4e146 libisl.10.dylib`isl_basic_set_sample_with_cone + 150 frame #10: 0x000141c4ea88 libisl.10.dylib`basic_set_sample + 744 frame #11: 0x000141c4e849 libisl.10.dylib`basic_set_sample + 169 frame #12: 0x000141c09978 libisl.10.dylib`isl_basic_map_is_empty + 136 frame #13: 0x000141bb2870 libisl.10.dylib`domain_follows_at_depth + 112 frame #14: 0x000141c7cdba libisl.10.dylib`isl_tarjan_components + 154 getting to the ICE take ~19s compared to less than a second before r214069. This is a bug in ISL. They’ll fix it in a new version of ISL. https://groups.google.com/forum/#!topic/isl-development/SeNZf5IA-Lk -- Cheers, Roman Gareev.
Re: [GSoC] Elimination of CLooG library installation dependency
I see two regressions after r214069 on x86_64-apple-darwin13 for both -m32 and -m64: (1) FAIL: gcc.dg/graphite/vect-pr43423.c scan-tree-dump-times vect vectorized 2 loops 1 before I saw [Book15] f90/bug% grep vectorized vect-pr43423.c.114t.vect /opt/gcc/p_work/gcc/testsuite/gcc.dg/graphite/vect-pr43423.c:14:17: note: === vect_mark_stmts_to_be_vectorized === /opt/gcc/p_work/gcc/testsuite/gcc.dg/graphite/vect-pr43423.c:14:17: note: loop vectorized /opt/gcc/p_work/gcc/testsuite/gcc.dg/graphite/vect-pr43423.c:12:17: note: === vect_mark_stmts_to_be_vectorized === /opt/gcc/p_work/gcc/testsuite/gcc.dg/graphite/vect-pr43423.c:12:17: note: loop vectorized /opt/gcc/p_work/gcc/testsuite/gcc.dg/graphite/vect-pr43423.c:6:6: note: vectorized 2 loops in function. after I see [Book15] f90/bug% grep vectorized vect-pr43423.c.115t.vect /opt/gcc/p_work/gcc/testsuite/gcc.dg/graphite/vect-pr43423.c:14:17: note: not vectorized: not suitable for gather load _55 = a[_56]; /opt/gcc/p_work/gcc/testsuite/gcc.dg/graphite/vect-pr43423.c:12:17: note: not vectorized: not suitable for gather load _36 = a[_37]; /opt/gcc/p_work/gcc/testsuite/gcc.dg/graphite/vect-pr43423.c:6:6: note: vectorized 0 loops in function. (2) FAIL: gfortran.dg/graphite/pr42393.f90 -O (internal compiler error) FAIL: gfortran.dg/graphite/pr42393.f90 -O (test for excess errors) The backtrace is * thread #1: tid = 0x13bd91f, 0x7fff8621aca0 libsystem_malloc.dylib`tiny_malloc_from_free_list + 12, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=2, address=0x7fff5bc00ff8) frame #0: 0x7fff8621aca0 libsystem_malloc.dylib`tiny_malloc_from_free_list + 12 libsystem_malloc.dylib`tiny_malloc_from_free_list + 12: - 0x7fff8621aca0: pushq %rbx 0x7fff8621aca1: pushq %rax 0x7fff8621aca2: movl %edx, %r12d 0x7fff8621aca5: movq %rsi, %r14 (lldb) bt * thread #1: tid = 0x13bd91f, 0x7fff8621aca0 libsystem_malloc.dylib`tiny_malloc_from_free_list + 12, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=2, address=0x7fff5bc00ff8) * frame #0: 0x7fff8621aca0 libsystem_malloc.dylib`tiny_malloc_from_free_list + 12 frame #1: 0x7fff8621b3c3 libsystem_malloc.dylib`szone_malloc_should_clear + 320 frame #2: 0x7fff8621d868 libsystem_malloc.dylib`malloc_zone_malloc + 71 frame #3: 0x7fff8621e27c libsystem_malloc.dylib`malloc + 42 frame #4: 0x000141dbdc79 libgmp.10.dylib`__gmp_default_allocate + 9 frame #5: 0x000141dd0148 libgmp.10.dylib`__gmpz_init + 24 frame #6: 0x000141c180ef libisl.10.dylib`isl_basic_map_normalize_constraints + 47 frame #7: 0x000141c18f04 libisl.10.dylib`isl_basic_map_simplify + 68 frame #8: 0x000141c2509b libisl.10.dylib`isl_basic_set_preimage + 619 frame #9: 0x000141c4e146 libisl.10.dylib`isl_basic_set_sample_with_cone + 150 frame #10: 0x000141c4ea88 libisl.10.dylib`basic_set_sample + 744 frame #11: 0x000141c4e849 libisl.10.dylib`basic_set_sample + 169 frame #12: 0x000141c09978 libisl.10.dylib`isl_basic_map_is_empty + 136 frame #13: 0x000141bb2870 libisl.10.dylib`domain_follows_at_depth + 112 frame #14: 0x000141c7cdba libisl.10.dylib`isl_tarjan_components + 154 getting to the ICE take ~19s compared to less than a second before r214069. Dominique
Re: [GSoC] Elimination of CLooG library installation dependency
I think it's a issue in isl library check for (Canadian) cross_compiling. Will send a patch soon. Thanks, bin On Wed, Aug 20, 2014 at 1:47 PM, Bin.Cheng amker.ch...@gmail.com wrote: On Wed, Aug 20, 2014 at 1:24 PM, Roman Gareev gareevro...@gmail.com wrote: Which configure options do you use? Have you tried to bootstrap r214105 with same configure options? Have you tried to manually export the path to isl to LD_RUN_PATH? (You've probably tried. I just want to make sure.) I can't access the build bot right now, so haven't tried other options yet. The latest good I got build was against r213896. Thanks, bin 2014-08-20 9:28 GMT+06:00 Bin.Cheng amker.ch...@gmail.com: I suspect this causes arm/aarch64 native bootstrap failure with below messages. aarch64-none-linux-gnu-g++ -c -g -O2 -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -I. -I/projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/src/gcc/gcc -I/projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/src/gcc/gcc/. -I/projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/src/gcc/gcc/../include -I/projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/src/gcc/gcc/../libcpp/include -I/projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/workdir/aarch64-none-linux-gnu/sysroot//usr/include -I/projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/workdir/aarch64-none-linux-gnu/sysroot//usr/include -I/projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/src/gcc/gcc/../libdecnumber -I/projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/src/gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I/projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/src/gcc/gcc/../libbacktrace -DCLOOG_INT_GMP -o graphite.o -MT graphite.o -MMD -MP -MF ./.deps/graphite.TPo /projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/src/gcc/gcc/graphite.c /projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/src/gcc/gcc/graphite.c:38:21: fatal error: isl/set.h: No such file or directory compilation terminated. make[1]: *** [graphite.o] Error 1 make[1]: Leaving directory `/arm/scratch/pdtltest/bld-temporary/builds/fsf-trunk/502/workdir/aarch64-none-linux-gnu/obj/build-gcc/gcc' make: *** [all-gcc] Error 2 Thanks, bin -- Cheers, Roman Gareev.
Re: [GSoC] Elimination of CLooG library installation dependency
I suspect this causes arm/aarch64 native bootstrap failure with below messages. aarch64-none-linux-gnu-g++ -c -g -O2 -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -I. -I/projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/src/gcc/gcc -I/projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/src/gcc/gcc/. -I/projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/src/gcc/gcc/../include -I/projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/src/gcc/gcc/../libcpp/include -I/projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/workdir/aarch64-none-linux-gnu/sysroot//usr/include -I/projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/workdir/aarch64-none-linux-gnu/sysroot//usr/include -I/projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/src/gcc/gcc/../libdecnumber -I/projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/src/gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I/projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/src/gcc/gcc/../libbacktrace -DCLOOG_INT_GMP -o graphite.o -MT graphite.o -MMD -MP -MF ./.deps/graphite.TPo /projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/src/gcc/gcc/graphite.c /projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/src/gcc/gcc/graphite.c:38:21: fatal error: isl/set.h: No such file or directory compilation terminated. make[1]: *** [graphite.o] Error 1 make[1]: Leaving directory `/arm/scratch/pdtltest/bld-temporary/builds/fsf-trunk/502/workdir/aarch64-none-linux-gnu/obj/build-gcc/gcc' make: *** [all-gcc] Error 2 Thanks, bin On Mon, Aug 18, 2014 at 11:22 PM, Roman Gareev gareevro...@gmail.com wrote: This patch is ok. I assume you have tested compiling with/without cloog and isl. Yes, I've tested compiling with/without cloog and isl. Thank you very much for review! -- Cheers, Roman Gareev.
Re: [GSoC] Elimination of CLooG library installation dependency
Which configure options do you use? Have you tried to bootstrap r214105 with same configure options? Have you tried to manually export the path to isl to LD_RUN_PATH? (You’ve probably tried. I just want to make sure.) 2014-08-20 9:28 GMT+06:00 Bin.Cheng amker.ch...@gmail.com: I suspect this causes arm/aarch64 native bootstrap failure with below messages. aarch64-none-linux-gnu-g++ -c -g -O2 -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -I. -I/projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/src/gcc/gcc -I/projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/src/gcc/gcc/. -I/projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/src/gcc/gcc/../include -I/projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/src/gcc/gcc/../libcpp/include -I/projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/workdir/aarch64-none-linux-gnu/sysroot//usr/include -I/projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/workdir/aarch64-none-linux-gnu/sysroot//usr/include -I/projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/src/gcc/gcc/../libdecnumber -I/projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/src/gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I/projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/src/gcc/gcc/../libbacktrace -DCLOOG_INT_GMP -o graphite.o -MT graphite.o -MMD -MP -MF ./.deps/graphite.TPo /projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/src/gcc/gcc/graphite.c /projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/src/gcc/gcc/graphite.c:38:21: fatal error: isl/set.h: No such file or directory compilation terminated. make[1]: *** [graphite.o] Error 1 make[1]: Leaving directory `/arm/scratch/pdtltest/bld-temporary/builds/fsf-trunk/502/workdir/aarch64-none-linux-gnu/obj/build-gcc/gcc' make: *** [all-gcc] Error 2 Thanks, bin -- Cheers, Roman Gareev.
Re: [GSoC] Elimination of CLooG library installation dependency
On Wed, Aug 20, 2014 at 1:24 PM, Roman Gareev gareevro...@gmail.com wrote: Which configure options do you use? Have you tried to bootstrap r214105 with same configure options? Have you tried to manually export the path to isl to LD_RUN_PATH? (You've probably tried. I just want to make sure.) I can't access the build bot right now, so haven't tried other options yet. The latest good I got build was against r213896. Thanks, bin 2014-08-20 9:28 GMT+06:00 Bin.Cheng amker.ch...@gmail.com: I suspect this causes arm/aarch64 native bootstrap failure with below messages. aarch64-none-linux-gnu-g++ -c -g -O2 -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -I. -I/projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/src/gcc/gcc -I/projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/src/gcc/gcc/. -I/projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/src/gcc/gcc/../include -I/projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/src/gcc/gcc/../libcpp/include -I/projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/workdir/aarch64-none-linux-gnu/sysroot//usr/include -I/projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/workdir/aarch64-none-linux-gnu/sysroot//usr/include -I/projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/src/gcc/gcc/../libdecnumber -I/projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/src/gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I/projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/src/gcc/gcc/../libbacktrace -DCLOOG_INT_GMP -o graphite.o -MT graphite.o -MMD -MP -MF ./.deps/graphite.TPo /projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/src/gcc/gcc/graphite.c /projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/src/gcc/gcc/graphite.c:38:21: fatal error: isl/set.h: No such file or directory compilation terminated. make[1]: *** [graphite.o] Error 1 make[1]: Leaving directory `/arm/scratch/pdtltest/bld-temporary/builds/fsf-trunk/502/workdir/aarch64-none-linux-gnu/obj/build-gcc/gcc' make: *** [all-gcc] Error 2 Thanks, bin -- Cheers, Roman Gareev.
Re: [GSoC] Elimination of CLooG library installation dependency
On Fri, Aug 15, 2014 at 1:13 PM, Roman Gareev gareevro...@gmail.com wrote: I've attached the patch, which should eliminate CLooG library installation dependency from GCC. The CLooG AST generator is still the main code generator, but the isl ast generator will be chosen in case of nonavailability of CLooG library. However, I've found out a problem. Almost all the functions of the ISL cannot be used without installed CLooG. (I get errors which contain “undefined reference to...”). Maybe I missed something. What do you think about this? I’ve attached a patch, which contains mentioned changes and doesn’t cause the error. I want to commit it in coming days. What do you think about it? This patch is ok. I assume you have tested compiling with/without cloog and isl. Maybe we should make the ISL AST generator to be the main code generator of Graphite (the patch1 implements this). What do you think about it? This patch is also ok if you and Tobias think it is ready for wider testing. I propose to remove the cloog path at latest when we enter stage3. Thanks, Richard. -- Cheers, Roman Gareev.
Re: [GSoC] Elimination of CLooG library installation dependency
This patch is ok. I assume you have tested compiling with/without cloog and isl. Yes, I’ve tested compiling with/without cloog and isl. Thank you very much for review! -- Cheers, Roman Gareev.
Re: [GSoC] Elimination of CLooG library installation dependency
On 16/08/2014 13:28, Roman Gareev wrote: Richard, could you please review these patches? We would be very glad for your comments. P.S: I’ve attached an improved ChangeLog_entry. The patch and changelog looks good to me, but we still need a non-graphite reviewer oking the changes. Tobias
Re: [GSoC] Elimination of CLooG library installation dependency
I've attached the patch, which should eliminate CLooG library
installation dependency from GCC. The CLooG AST generator is still the
main code generator, but the isl ast generator will be chosen in case
of nonavailability of CLooG library.
However, I've found out a problem. Almost all the functions of the ISL
cannot be used without installed CLooG. (I get errors which contain
“undefined reference to...”). Maybe I missed something. What do you
think about this?
I’ve attached a patch, which contains mentioned changes and doesn’t
cause the error. I want to commit it in coming days. What do you think
about it?
Maybe we should make the ISL AST generator to be the main code
generator of Graphite (the patch1 implements this). What do you think
about it?
--
Cheers, Roman Gareev.
2014-08-15 Roman Gareev gareevro...@gmail.com
* configure.ac: Eliminate ClooG installation dependency.
* configure: Regenerate.
* Makefile.tpl: Add definition of ISLLIBS and HOST_ISLLIBS.
* Makefile.in: Regenerate.
[config/]
* cloog.m4: Remove the path to isllibs from clooglibs.
* isl.m4: Add paths to islinc, isllibs.
[gcc/]
* Makefile.in: Add definition of ISLLIBS. Update LIBS.
* config.in: Add undef of HAVE_isl.
* configure: Regenerate.
* configure.ac: Add definition of HAVE_isl.
* graphite-blocking.c: Add checking of HAVE_isl.
* graphite-dependences.c: Likewise.
* graphite-interchange.c: Likewise.
* graphite-isl-ast-to-gimple.c: Likewise.
* graphite-optimize-isl.c: Likewise.
* graphite-poly.c: Likewise.
* graphite-scop-detection.c: Likewise.
* graphite-sese-to-poly.c: Likewise.
* graphite.c:
* toplev.c: Replace the checking of HAVE_cloog with the checking
of HAVE_isl.
2014-08-15 Roman Gareev gareevro...@gmail.com
[gcc/]
* common.opt: Make the ISL AST generator to be the main code generator
of Graphite.
Index: Makefile.in
===
--- Makefile.in (revision 214008)
+++ Makefile.in (working copy)
@@ -219,6 +219,7 @@
HOST_LIBS=$(STAGE1_LIBS); export HOST_LIBS; \
GMPLIBS=$(HOST_GMPLIBS); export GMPLIBS; \
GMPINC=$(HOST_GMPINC); export GMPINC; \
+ ISLLIBS=$(HOST_ISLLIBS); export ISLLIBS; \
ISLINC=$(HOST_ISLINC); export ISLINC; \
CLOOGLIBS=$(HOST_CLOOGLIBS); export CLOOGLIBS; \
CLOOGINC=$(HOST_CLOOGINC); export CLOOGINC; \
@@ -310,6 +311,7 @@
HOST_GMPINC = @gmpinc@
# Where to find ISL
+HOST_ISLLIBS = @isllibs@
HOST_ISLINC = @islinc@
# Where to find CLOOG
Index: Makefile.tpl
===
--- Makefile.tpl(revision 214008)
+++ Makefile.tpl(working copy)
@@ -222,6 +222,7 @@
HOST_LIBS=$(STAGE1_LIBS); export HOST_LIBS; \
GMPLIBS=$(HOST_GMPLIBS); export GMPLIBS; \
GMPINC=$(HOST_GMPINC); export GMPINC; \
+ ISLLIBS=$(HOST_ISLLIBS); export ISLLIBS; \
ISLINC=$(HOST_ISLINC); export ISLINC; \
CLOOGLIBS=$(HOST_CLOOGLIBS); export CLOOGLIBS; \
CLOOGINC=$(HOST_CLOOGINC); export CLOOGINC; \
@@ -313,6 +314,7 @@
HOST_GMPINC = @gmpinc@
# Where to find ISL
+HOST_ISLLIBS = @isllibs@
HOST_ISLINC = @islinc@
# Where to find CLOOG
Index: config/cloog.m4
===
--- config/cloog.m4 (revision 214008)
+++ config/cloog.m4 (working copy)
@@ -69,7 +69,7 @@
fi
clooginc=-DCLOOG_INT_GMP ${clooginc}
- clooglibs=${clooglibs} -lcloog-isl ${isllibs} -lisl
+ clooglibs=${clooglibs} -lcloog-isl
]
)
Index: config/isl.m4
===
--- config/isl.m4 (revision 214008)
+++ config/isl.m4 (working copy)
@@ -68,6 +68,9 @@
ENABLE_ISL_CHECK=no
AC_MSG_WARN([using in-tree ISL, disabling version check])
fi
+
+ islinc=-DCLOOG_INT_GMP ${islinc}
+ isllibs=${isllibs} -lisl
]
)
Index: configure
===
--- configure (revision 214008)
+++ configure (working copy)
@@ -649,6 +649,7 @@
clooginc
clooglibs
islinc
+isllibs
poststage1_ldflags
poststage1_libs
stage1_ldflags
@@ -2760,7 +2761,7 @@
build_tools=build-texinfo build-flex build-bison build-m4 build-fixincludes
# these libraries are used by various programs built for the host environment
-#
+#f
host_libs=intl libiberty opcodes bfd readline tcl tk itcl libgui zlib
libbacktrace libcpp libdecnumber gmp mpfr mpc isl cloog libelf libiconv
# these tools are built for the host environment
@@ -5835,10 +5836,9 @@
fi
-# Treat either --without-cloog or --without-isl as a request to disable
+# Treat --without-isl as a request to disable
# GRAPHITE support and skip all following checks.
-if test x$with_isl != xno
- test
Re: [GSoC] Elimination of CLooG library installation dependency
On Fri, Aug 15, 2014 at 1:13 PM, Roman Gareev gareevro...@gmail.com wrote: I've attached the patch, which should eliminate CLooG library installation dependency from GCC. The CLooG AST generator is still the main code generator, but the isl ast generator will be chosen in case of nonavailability of CLooG library. However, I've found out a problem. Almost all the functions of the ISL cannot be used without installed CLooG. (I get errors which contain “undefined reference to...”). Maybe I missed something. What do you think about this? I’ve attached a patch, which contains mentioned changes and doesn’t cause the error. I want to commit it in coming days. What do you think about it? Maybe we should make the ISL AST generator to be the main code generator of Graphite (the patch1 implements this). What do you think about it? We definitely should do that (and rip out the cloog code after a while). Richard. -- Cheers, Roman Gareev.
Re: [GSoC] Elimination of CLooG library installation dependency
Richard, could you please review these patches? We would be very glad for your comments. P.S: I’ve attached an improved ChangeLog_entry. 2014-08-15 17:44 GMT+06:00 Richard Biener richard.guent...@gmail.com: On Fri, Aug 15, 2014 at 1:13 PM, Roman Gareev gareevro...@gmail.com wrote: I've attached the patch, which should eliminate CLooG library installation dependency from GCC. The CLooG AST generator is still the main code generator, but the isl ast generator will be chosen in case of nonavailability of CLooG library. However, I've found out a problem. Almost all the functions of the ISL cannot be used without installed CLooG. (I get errors which contain “undefined reference to...”). Maybe I missed something. What do you think about this? I’ve attached a patch, which contains mentioned changes and doesn’t cause the error. I want to commit it in coming days. What do you think about it? Maybe we should make the ISL AST generator to be the main code generator of Graphite (the patch1 implements this). What do you think about it? We definitely should do that (and rip out the cloog code after a while). Richard. -- Cheers, Roman Gareev. 2014-08-15 Roman Gareev gareevro...@gmail.com * configure.ac: Eliminate ClooG installation dependency. * configure: Regenerate. * Makefile.tpl: Add definition of ISLLIBS and HOST_ISLLIBS. * Makefile.in: Regenerate. [config/] * cloog.m4: Remove the path to isllibs from clooglibs. * isl.m4: Add paths to islinc, isllibs. [gcc/] * Makefile.in: Add definition of ISLLIBS, HOST_ISLLIBS. * config.in: Add undef of HAVE_isl. * configure: Regenerate. * configure.ac: Add definition of HAVE_isl. * graphite-blocking.c: Add checking of HAVE_isl. * graphite-dependences.c: Likewise. * graphite-interchange.c: Likewise. * graphite-isl-ast-to-gimple.c: Likewise. * graphite-optimize-isl.c: Likewise. * graphite-poly.c: Likewise. * graphite-scop-detection.c: Likewise. * graphite-sese-to-poly.c: Likewise. * graphite.c: Likewise. * toplev.c: Replace the checking of HAVE_cloog with the checking of HAVE_isl.
Re: [GSoC] Elimination of CLooG library installation dependency
If I’m not mistaken all tree nodes, which have pointer type, can be divided into two groups: the type is a is a pointer to data member (TYPE_PTRMEM_P is true for it), the type is a pointer type, and the pointee is not a data member (TYPE_PTR_P is true for it). I think that we’re interested in disabling of the second group handling. It can also be divided into two groups: the type is a pointer to function type (TYPE_PTRFN_P is true for it), the type is a pointer to object type (TYPE_PTROB_P is true for it). In my opinion, the second one is worth to be considered. It contains, for example, nop_expr (these nodes are used to represent conversions that do not require any code-generation) integer_cst (these nodes represent integer constants), ssa_name. I haven’t found all types, which are contained in it. However, I think that we could disable other types, if it is necessary in the future. What we should do later is to build a run-time check that ensures no pointer overflow is happening and then just create code without it. I think that it is better to do this when the pointer handling is completed. I’ve attached a Change_Log, which corresponds to the previous patch. Are they fine for trunk? Could we give a headsup on the GCC mailing list and ask other people to try the new isl support in case this patch is committed? -- Cheers, Roman Gareev. 2014-07-12 Roman Gareev gareevro...@gmail.com gcc/ * graphite-scop-detection.c: Add inclusion of cp-tree.h. (graphite_can_represent_scev): Disables the handling of SSA_NAME nodes in case they are pointers to object types.
Re: [GSoC] Elimination of CLooG library installation dependency
On 13/08/2014 16:07, Roman Gareev wrote: If I’m not mistaken all tree nodes, which have pointer type, can be divided into two groups: the type is a is a pointer to data member (TYPE_PTRMEM_P is true for it), the type is a pointer type, and the pointee is not a data member (TYPE_PTR_P is true for it). I think that we’re interested in disabling of the second group handling. It can also be divided into two groups: the type is a pointer to function type (TYPE_PTRFN_P is true for it), the type is a pointer to object type (TYPE_PTROB_P is true for it). In my opinion, the second one is worth to be considered. It contains, for example, nop_expr (these nodes are used to represent conversions that do not require any code-generation) integer_cst (these nodes represent integer constants), ssa_name. I haven’t found all types, which are contained in it. However, I think that we could disable other types, if it is necessary in the future. What we should do later is to build a run-time check that ensures no pointer overflow is happening and then just create code without it. I think that it is better to do this when the pointer handling is completed. I’ve attached a Change_Log, which corresponds to the previous patch. Are they fine for trunk? Could we give a headsup on the GCC mailing list and ask other people to try the new isl support in case this patch is committed? Two minor thinks: - I assume you verified this passes all graphite tests. - Please add a brief comment in the source code regarding why we do not want to detect such SCoPs. Otherwise LGTM. Cheers, Tobias
Re: [GSoC] Elimination of CLooG library installation dependency
On Wed, Aug 13, 2014 at 10:07 AM, Roman Gareev gareevro...@gmail.com wrote: If I’m not mistaken all tree nodes, which have pointer type, can be divided into two groups: the type is a is a pointer to data member (TYPE_PTRMEM_P is true for it), the type is a pointer type, and the pointee is not a data member (TYPE_PTR_P is true for it). Both are C++ frontend concepts and not relevant for the middle-end and thus GRAPHITE. I think that we’re interested in disabling of the second group handling. It can also be divided into two groups: the type is a pointer to function type (TYPE_PTRFN_P is true for it), the type is a pointer to object type (TYPE_PTROB_P is true for it). In my opinion, the second one is worth to be considered. It contains, for example, nop_expr (these nodes are used to represent conversions that do not require any code-generation) integer_cst (these nodes represent integer constants), ssa_name. I haven’t found all types, which are contained in it. However, I think that we could disable other types, if it is necessary in the future. What we should do later is to build a run-time check that ensures no pointer overflow is happening and then just create code without it. I think you can assume that pointers don't overflow. Richard. I think that it is better to do this when the pointer handling is completed. I’ve attached a Change_Log, which corresponds to the previous patch. Are they fine for trunk? Could we give a headsup on the GCC mailing list and ask other people to try the new isl support in case this patch is committed? -- Cheers, Roman Gareev.
Re: [GSoC] Elimination of CLooG library installation dependency
- I assume you verified this passes all graphite tests. Yes, I’ve found out that there is no regression. - Please add a brief comment in the source code regarding why we do not want to detect such SCoPs. Would you add anything to the following comment: “We disable the handling of pointer types, because it’s currently not supported by Graphite with the ISL AST generator. SSA_NAME nodes are the only nodes, which are disabled in case they are pointers to object types, but this can be changed.” ? -- Cheers, Roman Gareev.
Re: [GSoC] Elimination of CLooG library installation dependency
Thank you for the comment! 2014-08-13 15:55 GMT+06:00 Richard Biener richard.guent...@gmail.com: On Wed, Aug 13, 2014 at 10:07 AM, Roman Gareev gareevro...@gmail.com wrote: If I’m not mistaken all tree nodes, which have pointer type, can be divided into two groups: the type is a is a pointer to data member (TYPE_PTRMEM_P is true for it), the type is a pointer type, and the pointee is not a data member (TYPE_PTR_P is true for it). Both are C++ frontend concepts and not relevant for the middle-end and thus GRAPHITE. I think that we’re interested in disabling of the second group handling. It can also be divided into two groups: the type is a pointer to function type (TYPE_PTRFN_P is true for it), the type is a pointer to object type (TYPE_PTROB_P is true for it). In my opinion, the second one is worth to be considered. It contains, for example, nop_expr (these nodes are used to represent conversions that do not require any code-generation) integer_cst (these nodes represent integer constants), ssa_name. I haven’t found all types, which are contained in it. However, I think that we could disable other types, if it is necessary in the future. What we should do later is to build a run-time check that ensures no pointer overflow is happening and then just create code without it. I think you can assume that pointers don't overflow. Richard. I think that it is better to do this when the pointer handling is completed. I’ve attached a Change_Log, which corresponds to the previous patch. Are they fine for trunk? Could we give a headsup on the GCC mailing list and ask other people to try the new isl support in case this patch is committed? -- Cheers, Roman Gareev. -- Cheers, Roman Gareev.
Re: [GSoC] Elimination of CLooG library installation dependency
On 09/08/2014 12:05, Roman Gareev wrote: With just C++ code, Sven can help little. He has no knowledge about graphite internals. I want to ask him about correctness of ISL ASTs generated from mentioned isl_codegens. I am not sure if he can see it just like this. Do you now have a setup where you can just compile one of the attached files with graphite and everything else without and the code crashes? No, I don't. As I mentioned earlier, all the files from this test case individually produce object files which linked into the one executable, which cause “Segmentation fault (core dumped)” (It'll cause “Segmentation fault (core dumped)”, if we try to run it). I think that it's very difficult to detach the code, which would produce the executable and save the semantics of this big OOP project. Furthermore, there is a possibility that the detached code can produce no new useful information. I've found that if we try to compile any of the btCollisionWorld.cpp, btCollisionDispatcher.cpp and btDiscreteDynamicsWorld.llvm.cpp by modified Graphite, the produced object file will lead to creation of the wrong executable (after linking with other object files generated by origin Graphite). I am confused. It seems you attached some kind of reduced version of btCollisionWorld.cpp? How did you obtain it? Did you compile and test with these versions? That's why I think that we could consider only, for example, btCollisionDispatcher.cpp. It contains only one scope, which is incorrectly processed by Graphite with the ISL code generator as the main generator. Why did you provide two files. I assume one should be sufficient to reproduce the crash, no? I've detached the code, which is used by Graphite to produce similar AST's. OK. But did you check if they actually segfault or fail? I think for the one file you choose, it would be interesting to look at the code generation input as well as the kernels generated by CLooG and isl. Maybe we can understand what is going on. Yes, exactly those that you provided. At a first look, I don't see anything obvious wrong, except that the huge modulo values, which arise from some integer wrapping support Sebastian added once for unsigned integers. I see two approaches you can take: 1) The easy one Disallow unsigned integers in the scop detection. I have doubts we can do anything good with those huge modulo constraints placed all over the generated code 2) Try to understand the test case I would try a couple of easy unsigned int loops to see if we can handle them properly. Something like: for (unsigned long i = 0; i M; i++) A[i] += i; At best, we could even write your test case as such a loop and reproduce the bug outside of this huge C++ code. Maybe looking at the GIMPLE allows you to write C code that has similar behavior and where we could check the output? Tobias
Re: [GSoC] Elimination of CLooG library installation dependency
I am confused. It seems you attached some kind of reduced version of
btCollisionWorld.cpp? How did you obtain it? Did you compile and test
with these versions?
I’ve manually selected parts of code, which produce the scope.
I’ve found out that this bug is most probably caused by absence of
pointer handling. The tree, which is corresponding to P_11 has
pointer type. Furthermore, if we consider the transformed gimple code
for (it can be found attached), we’ll see that it contains wrong
parts:
The code produced by modified version of Graphite:
...
_35 = (signed long) _11;
_36 = _34 + _35;
_37 = _36 % 0;
_38 = _37 0;
_39 = (signed long) _38;
...
The code produced by origin version of Graphite:
...
_36 = (sizetype) _11;
_37 = _36 + 18446744073709551615;
_38 = 8B + _37;
_39 = _38 % 0B;
_40 = _39 != -1B;
...
(If I’m not mistaken, 0B, for example, corresponds to (void *). It
can be seen here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50712)
I’ve tried to implement pointer handling in the attached patch, but it
is wrong. I get the following error instead of seagfault now:
Floating point exception (core dumped)
back trace:
Program terminated with signal 8, Arithmetic exception.
#0 0x004204c5 in allocSize (this=optimized out,
size=optimized out)
at
/home/roman/llvm-test-suite/MultiSource/Benchmarks/Bullet/include/LinearMath/btAlignedObjectArray.h:59
59 return (size ? size*2 : 1);
(gdb) bt
#0 0x004204c5 in allocSize (this=optimized out,
size=optimized out)
at
/home/roman/llvm-test-suite/MultiSource/Benchmarks/Bullet/include/LinearMath/btAlignedObjectArray.h:59
#1 push_back (_Val=synthetic pointer, this=0x1125600)
at
/home/roman/llvm-test-suite/MultiSource/Benchmarks/Bullet/include/LinearMath/btAlignedObjectArray.h:220
#2 btCollisionDispatcher::getNewManifold (this=0x11255f0, b0=optimized out,
b1=optimized out) at btCollisionDispatcher.llvm.cpp:100
#3 0x0044e764 in
btConvexPlaneCollisionAlgorithm::btConvexPlaneCollisionAlgorithm
(this=0x7f665ca6b0c0, mf=0x0, ci=..., col0=optimized out,
col1=optimized out, isSwapped=optimized out,
numPerturbationIterations=1, minimumPointsPerturbationThreshold=1)
at
/home/roman/llvm-test-suite/MultiSource/Benchmarks/Bullet/btConvexPlaneCollisionAlgorithm.cpp:38
#4 0x0046281b in
btConvexPlaneCollisionAlgorithm::CreateFunc::CreateCollisionAlgorithm
(this=0x11254e0, ci=..., body0=0x113d040, body1=0x113d810)
at
/home/roman/llvm-test-suite/MultiSource/Benchmarks/Bullet/include/BulletCollision/CollisionDispatch/btConvexPlaneCollisionAlgorithm.h:76
#5 0x004205ac in btCollisionDispatcher::findAlgorithm (
this=optimized out, body0=optimized out, body1=optimized out,
sharedManifold=optimized out) at btCollisionDispatcher.llvm.cpp:145
#6 0x004202e2 in btCollisionDispatcher::defaultNearCallback (
---Type return to continue, or q return to quit---
collisionPair=..., dispatcher=..., dispatchInfo=...)
at btCollisionDispatcher.llvm.cpp:258
#7 0x0042083b in btCollisionPairCallback::processOverlap (
this=optimized out, pair=...) at btCollisionDispatcher.llvm.cpp:224
#8 0x004acff2 in
btHashedOverlappingPairCache::processAllOverlappingPairs
(this=0x1127f80, callback=0x7fff0d1af790, dispatcher=0x11255f0)
at
/home/roman/llvm-test-suite/MultiSource/Benchmarks/Bullet/btOverlappingPairCache.cpp:387
#9 0x004200c9 in btCollisionDispatcher::dispatchAllCollisionPairs (
this=optimized out, pairCache=optimized out, dispatchInfo=...,
dispatcher=optimized out) at btCollisionDispatcher.llvm.cpp:238
#10 0x00421bd4 in btCollisionWorld::performDiscreteCollisionDetection()
()
#11 0x00464d9a in
btDiscreteDynamicsWorld::internalSingleStepSimulation(float) ()
#12 0x0046473f in
btDiscreteDynamicsWorld::stepSimulation(float, int, float) ()
#13 0x00401e08 in BenchmarkDemo::clientMoveAndDisplay (
this=0x7fff0d1af980)
at
/home/roman/llvm-test-suite/MultiSource/Benchmarks/Bullet/BenchmarkDemo.cpp:232
#14 0x00401b12 in main (argc=optimized out, argv=optimized out)
at /home/roman/llvm-test-suite/MultiSource/Benchmarks/Bullet/main.cpp:63
Could you please advise me an algorithm for pointer handling?
--
Cheers, Roman Gareev.
loop_0 (header = 0, latch = 1, niter = )
{
bb_2 (preds = {bb_0 }, succs = {bb_4 bb_3 })
{
bb 2:
# DEBUG D#5 = this_1(D)-m_manifoldsPtr
# DEBUG this = D#5
# VUSE .MEM_3(D)
_5 = MEM[(struct btAlignedObjectArray *)this_1(D) + 8B].m_size;
_6 = _5 * 2;
# DEBUG D#4 = D#5-m_allocator
# DEBUG D#2 = D#4
# DEBUG D#3 = 0B
# DEBUG n = _6
# DEBUG this = D#2
# DEBUG hint = D#3
_7 = (long unsigned int) _6;
_8 = (unsigned int) _7;
_9 = _8 * 8;
_10 = (int) _9;
# .MEM_22 = VDEF .MEM_3(D)
_11 = btAlignedAlloc (_10, 16);
#
Re: [GSoC] Elimination of CLooG library installation dependency
On 11/08/2014 09:11, Roman Gareev wrote: I am confused. It seems you attached some kind of reduced version of btCollisionWorld.cpp? How did you obtain it? Did you compile and test with these versions? I’ve manually selected parts of code, which produce the scope. I’ve found out that this bug is most probably caused by absence of pointer handling. The tree, which is corresponding to P_11 has pointer type. Furthermore, if we consider the transformed gimple code for (it can be found attached), we’ll see that it contains wrong parts: Could you please advise me an algorithm for pointer handling? Did you try your code with 64bit pointer types? In any case, I don't think it is worth spending time on this. I would check in the scop detection that we disable the handling of unsigned and pointer types. It is a complex thing to model and the approach currently taking of always model their wrapping behaviour seems wrong. What we should do later is to build a run-time check that ensures no pointer overflow is happening and then just create code without it. Cheers, Tobias
Re: [GSoC] Elimination of CLooG library installation dependency
Did you try your code with 64bit pointer types?
Yes. It seems that the result is the same.
In any case, I don't think it is worth spending time on this. I would check
in the scop detection that we disable the handling of unsigned and pointer
types. It is a complex thing to model and the approach currently taking of
always model their wrapping behaviour seems wrong.
I’ve attached a patch, which disables the handling SSA_NAME nodes in
case they are pointers to object types. Which nodes should also be
disabled? (I’ve found that this disabling helps to avoid the error and
can be a temporary solution) Is the graphite_can_represent_scev an
appropriate place for the disabling of type handling?
--
Cheers, Roman Gareev.
Index: gcc/graphite-scop-detection.c
===
--- gcc/graphite-scop-detection.c (revision 213773)
+++ gcc/graphite-scop-detection.c (working copy)
@@ -54,6 +54,7 @@
#include tree-pass.h
#include sese.h
#include tree-ssa-propagate.h
+#include cp/cp-tree.h
#ifdef HAVE_cloog
#include graphite-poly.h
@@ -217,6 +218,9 @@
if (chrec_contains_undetermined (scev))
return false;
+ if (TYPE_PTROB_P (TREE_TYPE (scev)) TREE_CODE (scev) == SSA_NAME)
+return false;
+
switch (TREE_CODE (scev))
{
case NEGATE_EXPR:
Re: [GSoC] Elimination of CLooG library installation dependency
Is this segmentation fault at compile time or at run-time? I believe it was
a segfault at run-time due to a miscompile.
Yes, it's a segfault at run-time. These source codes produce wrong object files.
Possibly. Can you split the .cpp files such that you only compile a single
function with graphite and that compiling this function causes the
miscompile. This allows us to look at less code.
I've tried to reduce btCollisionWorld.cpp and
btCollisionDispatcher.cpp (They can be found attached). Should we ask
Sven?
--
Cheers, Roman Gareev.
void *btAlignedAlloc (int size, int alignment);
template typename T, unsigned Alignment
class btAlignedAllocator
{
typedef btAlignedAllocator T, Alignment self_type;
public:
T *allocate (int n, const T** hint = 0)
{
(void) hint;
return reinterpret_castT*(btAlignedAlloc(sizeof (T) * n, Alignment));
}
};
#include new
template typename T
class btAlignedObjectArray
{
btAlignedAllocatorT, 16 m_allocator;
int m_size;
T *m_data;
public:
void push_back ()
{
T *s = (T*) m_allocator.allocate (m_size * 2);
int i;
for (i=0; im_size; ++i)
new (s[i]) T (m_data[i]);
}
};
class btCollisionDispatcher
{
btAlignedObjectArraybtCollisionDispatcher* m_manifoldsPtr;
virtual void getNewManifold ();
};
void btCollisionDispatcher::getNewManifold ()
{
m_manifoldsPtr.push_back ();
}
void* btAlignedAlloc (int size, int alignment);
template typename T, unsigned Alignment
class btAlignedAllocator
{
typedef btAlignedAllocatorT, Alignment self_type;
public:
template typename Other
btAlignedAllocator (const btAlignedAllocatorOther, Alignment ) {}
T *allocate (int n, const T **hint = 0)
{
(void) hint;
return reinterpret_castT* (btAlignedAlloc (sizeof (T) * n ,
Alignment));
}
};
#include new
template typename T
class btAlignedObjectArray
{
btAlignedAllocatorT, 16 m_allocator;
int m_size;
T *m_data;
public:
void push_back (const T _Val)
{
T *s = (T*) m_allocator.allocate (m_size * 2);
int i;
for (i=0; im_size; ++i)
new (s[i]) T (m_data[i]);
new (m_data[m_size]) T (_Val);
}
};
typedef btAlignedObjectArrayclass btCollisionObject* btCollisionObjectArray;
class btCollisionObject;
class btCollisionWorld
{
protected:
btAlignedObjectArraybtCollisionObject* m_collisionObjects;
public:
virtual void addCollisionObject(btCollisionObject* collisionObject);
};
void btCollisionWorld::addCollisionObject(btCollisionObject* collisionObject)
{
m_collisionObjects.push_back(collisionObject);
}
Re: [GSoC] Elimination of CLooG library installation dependency
On 09/08/2014 09:42, Roman Gareev wrote: Is this segmentation fault at compile time or at run-time? I believe it was a segfault at run-time due to a miscompile. Yes, it's a segfault at run-time. These source codes produce wrong object files. Possibly. Can you split the .cpp files such that you only compile a single function with graphite and that compiling this function causes the miscompile. This allows us to look at less code. I've tried to reduce btCollisionWorld.cpp and btCollisionDispatcher.cpp (They can be found attached). Should we ask Sven? With just C++ code, Sven can help little. He has no knowledge about graphite internals. Do you now have a setup where you can just compile one of the attached files with graphite and everything else without and the code crashes? Why did you provide two files. I assume one should be sufficient to reproduce the crash, no? I think for the one file you choose, it would be interesting to look at the code generation input as well as the kernels generated by CLooG and isl. Maybe we can understand what is going on. Cheers, Tobias
Re: [GSoC] Elimination of CLooG library installation dependency
With just C++ code, Sven can help little. He has no knowledge about graphite
internals.
I want to ask him about correctness of ISL ASTs generated from
mentioned isl_codegens.
Do you now have a setup where you can just compile one of the attached files
with graphite and everything else without and the code crashes?
No, I don't. As I mentioned earlier, all the files from this test case
individually produce object files which linked into the one
executable, which cause “Segmentation fault (core dumped)” (It'll
cause “Segmentation fault (core dumped)”, if we try to run it). I
think that it's very difficult to detach the code, which would produce
the executable and save the semantics of this big OOP project.
Furthermore, there is a possibility that the detached code can produce
no new useful information.
I've found that if we try to compile any of the btCollisionWorld.cpp,
btCollisionDispatcher.cpp
and btDiscreteDynamicsWorld.llvm.cpp by modified Graphite, the
produced object file will lead to creation of the wrong executable
(after linking with other object files generated by origin Graphite).
That's why I think that we could consider only, for example,
btCollisionDispatcher.cpp. It contains only one scope, which is
incorrectly processed by Graphite with the ISL code generator as the
main generator.
Why did you provide two files. I assume one should be sufficient to
reproduce the crash, no?
I've detached the code, which is used by Graphite to produce similar AST's.
I think for the one file you choose, it would be interesting to look
at the code generation input as well as the kernels generated by CLooG and
isl. Maybe we can understand what is going on.
What do you mean by the kernels generated by CLooG and isl?
btCollisionDispatcher.cpp:
isl_codegen:
[P_2, P_11] - { S_6[i0] - [0, i0, 0] : exists (e0 = floor((-1 +
P_2)/4294967296), e1 = floor((P_11 + 8i0)/18446744073709551616): i0 =
0 and 4294967296e0 = -1 + P_2 and 4294967296e0 = -4294967296 + P_2
and 4294967296e0 = -1 + P_2 - i0 and i0 = 2147483646 and
18446744073709551616e1 = -18446744073709551615 + P_11 + 8i0 and
18446744073709551616e1 = -1 + P_11 + 8i0) }
[P_2, P_11] - { : exists (e0 = floor((-1 + P_2)/4294967296):
4294967296e0 = -1 + P_2 and 4294967296e0 = -2147483647 + P_2 and P_2
= -2147483648 and P_2 = 2147483647 and P_11 = 0 and P_11 =
18446744073709551615) }
[P_2, P_11] - { [i0, i1, i2] - separate[o0] }
ISL AST generated by ISL:
for (int c1 = 0; c1 P_2; c1 += 1)
if ((P_11 + 8 * c1) % 18446744073709551616 = 1)
S_6(c1);
cloog_input:
# CLooG - CLooG
# This is an automatic dump of a CLooG input file from a CloogInput data
# structure.
# Language: C
c
# Context:
1
4 4 0 0 0 2
1 1 0-1
1-1 0 2147483647
1 0-1 18446744073709551615
1 0 1 0
1 # Parameter name(s)
T_2 T_11
# Statement number:
1
# Iteration domain of statement 1 ().
1
7 7 1 0 2 2
1 1 0 0 0 0 0
1 0 -4294967296 0 1 0-1
1 0 4294967296 0-1 0 4294967296
1-1 -4294967296 0 1 0-1
1-1 0 0 0 0 2147483646
1-8 0 18446744073709551616 0-1 18446744073709551615
1 8 0 -18446744073709551616 0 1-1
0 0 0 # For future options.
1 # Iterator name(s)
git_0
# - SCATTERING
1 # Scattering functions
# Scattering of statement 1 ().
1
3 8 3 1 0 2
0 0 0 1 0 0 0 0
0 0 1 0-1 0 0 0
0 1 0 0 0 0 0 0
1 # Scattering dimension name(s)
scat_0 scat_1 scat_2
CLAST generated by ClooG:
if (8*T_2 = -T_11+9) {
for (scat_1=0;scat_1=T_2-1;scat_1++) {
if ((8*scat_1+T_11+18446744073709551615)%18446744073709551616 =
18446744073709551614) {
(scat_1);
}
}
}
--
Cheers, Roman Gareev.
Re: [GSoC] Elimination of CLooG library installation dependency
I think this is fine. On the other side, I think the test case itself
is unnecessarily large. I would assume the majority of the code could
be deleted while still triggering the bug. Could you give it a shot.
I've attached an improved version of the patch.
Is there anything else you still would like to do?
I wanted to make the current code available to be able to fix all new
possible bugs before 'pencils down'. If I have free time, I'll try to
improve the performance of the generation.
Otherwise, I believe fixing the last remaining bugs is of high importance, as
we want to enable
this code as soon as possible to avoid future bitrot.
I understand that reducing this may require some work, but I don't think it
is that hard. Specifically, you could first compile the individual *.cpp
files to .o files once using once graphite once not.
I've found out that btCollisionWorld.cpp, btCollisionDispatcher.cpp
and btDiscreteDynamicsWorld.llvm.cpp cause “Segmentation fault”. All
of them produce similar ASTs:
btCollisionWorld.cpp:
CLAST generated by CLooG:
if (8*T_45 = -T_44+9) {
for (scat_1=0;scat_1=T_45-1;scat_1++) {
if ((8*scat_1+T_44+18446744073709551615)%18446744073709551616 =
18446744073709551614) {
(scat_1);
}
}
}
isl_codegen:
[P_45, P_44] - { S_12[i0] - [0, i0, 0] : exists (e0 = floor((-1 +
P_45)/4294967296), e1 = floor((P_44 + 8i0)/18446744073709551616): i0
= 0 and 4294967296e0 = -1 + P_45 and 4294967296e0 = -4294967296 +
P_45 and 4294967296e0 = -1 + P_45 - i0 and i0 = 2147483646 and
18446744073709551616e1 = -18446744073709551615 + P_44 + 8i0 and
18446744073709551616e1 = -1 + P_44 + 8i0) }
[P_45, P_44] - { : exists (e0 = floor((-1 + P_45)/4294967296):
4294967296e0 = -1 + P_45 and 4294967296e0 = -2147483647 + P_45 and
P_45 = -2147483648 and P_45 = 2147483647 and P_44 = 0 and P_44 =
18446744073709551615) }
[P_45, P_44] - { [i0, i1, i2] - separate[o0] }
ISL AST generated by ISL:
for (int c1 = 0; c1 P_45; c1 += 1)
if ((P_44 + 8 * c1) % 18446744073709551616 = 1)
S_12(c1);
btCollisionDispatcher.cpp:
CLAST generated by CLooG:
if (8*T_81 = -T_80+9) {
for (scat_1=0;scat_1=T_81-1;scat_1++) {
if ((8*scat_1+T_80+18446744073709551615)%18446744073709551616 =
18446744073709551614) {
(scat_1);
}
}
}
isl_codegen:
[P_81, P_80] - { S_22[i0] - [0, i0, 0] : exists (e0 = floor((-1 +
P_81)/4294967296), e1 = floor((P_80 + 8i0)/18446744073709551616): i0
= 0 and 4294967296e0 = -1 + P_81 and 4294967296e0 = -4294967296 +
P_81 and 4294967296e0 = -1 + P_81 - i0 and i0 = 2147483646 and
18446744073709551616e1 = -18446744073709551615 + P_80 + 8i0 and
18446744073709551616e1 = -1 + P_80 + 8i0) }
[P_81, P_80] - { : exists (e0 = floor((-1 + P_81)/4294967296):
4294967296e0 = -1 + P_81 and 4294967296e0 = -2147483647 + P_81 and
P_81 = -2147483648 and P_81 = 2147483647 and P_80 = 0 and P_80 =
18446744073709551615) }
[P_81, P_80] - { [i0, i1, i2] - separate[o0] }
ISL AST generated by ISL:
for (int c1 = 0; c1 P_81; c1 += 1)
if ((P_80 + 8 * c1) % 18446744073709551616 = 1)
S_22(c1);
btDiscreteDynamicsWorld.llvm.cpp:
CLAST generated by CLooG:
if (8*T_24 = -T_23+9) {
for (scat_1=0;scat_1=T_24-1;scat_1++) {
if ((8*scat_1+T_23+18446744073709551615)%18446744073709551616 =
18446744073709551614) {
(scat_1);
}
}
}
isl_codegen:
[P_24, P_23] - { S_13[i0] - [0, i0, 0] : exists (e0 = floor((-1 +
P_24)/4294967296), e1 = floor((P_23 + 8i0)/18446744073709551616): i0
= 0 and 4294967296e0 = -1 + P_24 and 4294967296e0 = -4294967296 +
P_24 and 4294967296e0 = -1 + P_24 - i0 and i0 = 2147483646 and
18446744073709551616e1 = -18446744073709551615 + P_23 + 8i0 and
18446744073709551616e1 = -1 + P_23 + 8i0) }
[P_24, P_23] - { : exists (e0 = floor((-1 + P_24)/4294967296):
4294967296e0 = -1 + P_24 and 4294967296e0 = -2147483647 + P_24 and
P_24 = -2147483648 and P_24 = 2147483647 and P_23 = 0 and P_23 =
18446744073709551615) }
[P_24, P_23] - { [i0, i1, i2] - separate[o0] }
ISL AST generated by ISL:
for (int c1 = 0; c1 P_24; c1 += 1)
if ((P_23 + 8 * c1) % 18446744073709551616 = 1)
S_13(c1);
CLAST generated by CLooG:
if (8*T_46 = -T_45+9) {
for (scat_1=0;scat_1=T_46-1;scat_1++) {
if ((8*scat_1+T_45+18446744073709551615)%18446744073709551616 =
18446744073709551614) {
(scat_1);
}
}
}
isl_codegen:
[P_46, P_45] - { S_16[i0] - [0, i0, 0] : exists (e0 = floor((-1 +
P_46)/4294967296), e1 = floor((P_45 + 8i0)/18446744073709551616): i0
= 0 and 4294967296e0 = -1 + P_46 and 4294967296e0 = -4294967296 +
P_46 and 4294967296e0 = -1 + P_46 - i0 and i0 = 2147483646 and
18446744073709551616e1 = -18446744073709551615 + P_45 + 8i0 and
18446744073709551616e1 = -1 + P_45 + 8i0) }
[P_46, P_45] - { : exists (e0 = floor((-1 + P_46)/4294967296):
4294967296e0 = -1 + P_46 and 4294967296e0 = -2147483647 + P_46 and
P_46 = -2147483648 and P_46 = 2147483647 and P_45 = 0 and P_45 =
18446744073709551615) }
[P_46, P_45] - { [i0, i1, i2] - separate[o0] }
ISL AST generated by
Re: [GSoC] Elimination of CLooG library installation dependency
On 08/08/2014 15:11, Roman Gareev wrote:
I think this is fine. On the other side, I think the test case itself
is unnecessarily large. I would assume the majority of the code could
be deleted while still triggering the bug. Could you give it a shot.
I've attached an improved version of the patch.
LGTM.
Is there anything else you still would like to do?
I wanted to make the current code available to be able to fix all new
possible bugs before 'pencils down'. If I have free time, I'll try to
improve the performance of the generation.
Good, though before let's try to get the correctness right.
Otherwise, I believe fixing the last remaining bugs is of high importance, as
we want to enable
this code as soon as possible to avoid future bitrot.
I understand that reducing this may require some work, but I don't think it
is that hard. Specifically, you could first compile the individual *.cpp
files to .o files once using once graphite once not.
I've found out that btCollisionWorld.cpp, btCollisionDispatcher.cpp
and btDiscreteDynamicsWorld.llvm.cpp cause “Segmentation fault”. All
of them produce similar ASTs:
Is this segmentation fault at compile time or at run-time? I believe it
was a segfault at run-time due to a miscompile.
btCollisionWorld.cpp:
CLAST generated by CLooG:
if (8*T_45 = -T_44+9) {
for (scat_1=0;scat_1=T_45-1;scat_1++) {
if ((8*scat_1+T_44+18446744073709551615)%18446744073709551616 =
18446744073709551614) {
(scat_1);
}
}
}
isl_codegen:
[P_45, P_44] - { S_12[i0] - [0, i0, 0] : exists (e0 = floor((-1 +
P_45)/4294967296), e1 = floor((P_44 + 8i0)/18446744073709551616): i0
= 0 and 4294967296e0 = -1 + P_45 and 4294967296e0 = -4294967296 +
P_45 and 4294967296e0 = -1 + P_45 - i0 and i0 = 2147483646 and
18446744073709551616e1 = -18446744073709551615 + P_44 + 8i0 and
18446744073709551616e1 = -1 + P_44 + 8i0) }
[P_45, P_44] - { : exists (e0 = floor((-1 + P_45)/4294967296):
4294967296e0 = -1 + P_45 and 4294967296e0 = -2147483647 + P_45 and
P_45 = -2147483648 and P_45 = 2147483647 and P_44 = 0 and P_44 =
18446744073709551615) }
[P_45, P_44] - { [i0, i1, i2] - separate[o0] }
ISL AST generated by ISL:
for (int c1 = 0; c1 P_45; c1 += 1)
if ((P_44 + 8 * c1) % 18446744073709551616 = 1)
S_12(c1);
btCollisionDispatcher.cpp:
CLAST generated by CLooG:
if (8*T_81 = -T_80+9) {
for (scat_1=0;scat_1=T_81-1;scat_1++) {
if ((8*scat_1+T_80+18446744073709551615)%18446744073709551616 =
18446744073709551614) {
(scat_1);
}
}
}
isl_codegen:
[P_81, P_80] - { S_22[i0] - [0, i0, 0] : exists (e0 = floor((-1 +
P_81)/4294967296), e1 = floor((P_80 + 8i0)/18446744073709551616): i0
= 0 and 4294967296e0 = -1 + P_81 and 4294967296e0 = -4294967296 +
P_81 and 4294967296e0 = -1 + P_81 - i0 and i0 = 2147483646 and
18446744073709551616e1 = -18446744073709551615 + P_80 + 8i0 and
18446744073709551616e1 = -1 + P_80 + 8i0) }
[P_81, P_80] - { : exists (e0 = floor((-1 + P_81)/4294967296):
4294967296e0 = -1 + P_81 and 4294967296e0 = -2147483647 + P_81 and
P_81 = -2147483648 and P_81 = 2147483647 and P_80 = 0 and P_80 =
18446744073709551615) }
[P_81, P_80] - { [i0, i1, i2] - separate[o0] }
ISL AST generated by ISL:
for (int c1 = 0; c1 P_81; c1 += 1)
if ((P_80 + 8 * c1) % 18446744073709551616 = 1)
S_22(c1);
btDiscreteDynamicsWorld.llvm.cpp:
CLAST generated by CLooG:
if (8*T_24 = -T_23+9) {
for (scat_1=0;scat_1=T_24-1;scat_1++) {
if ((8*scat_1+T_23+18446744073709551615)%18446744073709551616 =
18446744073709551614) {
(scat_1);
}
}
}
isl_codegen:
[P_24, P_23] - { S_13[i0] - [0, i0, 0] : exists (e0 = floor((-1 +
P_24)/4294967296), e1 = floor((P_23 + 8i0)/18446744073709551616): i0
= 0 and 4294967296e0 = -1 + P_24 and 4294967296e0 = -4294967296 +
P_24 and 4294967296e0 = -1 + P_24 - i0 and i0 = 2147483646 and
18446744073709551616e1 = -18446744073709551615 + P_23 + 8i0 and
18446744073709551616e1 = -1 + P_23 + 8i0) }
[P_24, P_23] - { : exists (e0 = floor((-1 + P_24)/4294967296):
4294967296e0 = -1 + P_24 and 4294967296e0 = -2147483647 + P_24 and
P_24 = -2147483648 and P_24 = 2147483647 and P_23 = 0 and P_23 =
18446744073709551615) }
[P_24, P_23] - { [i0, i1, i2] - separate[o0] }
ISL AST generated by ISL:
for (int c1 = 0; c1 P_24; c1 += 1)
if ((P_23 + 8 * c1) % 18446744073709551616 = 1)
S_13(c1);
CLAST generated by CLooG:
if (8*T_46 = -T_45+9) {
for (scat_1=0;scat_1=T_46-1;scat_1++) {
if ((8*scat_1+T_45+18446744073709551615)%18446744073709551616 =
18446744073709551614) {
(scat_1);
}
}
}
isl_codegen:
[P_46, P_45] - { S_16[i0] - [0, i0, 0] : exists (e0 = floor((-1 +
P_46)/4294967296), e1 = floor((P_45 + 8i0)/18446744073709551616): i0
= 0 and 4294967296e0 = -1 + P_46 and 4294967296e0 = -4294967296 +
P_46 and 4294967296e0 = -1 + P_46 - i0 and i0 = 2147483646 and
18446744073709551616e1 = -18446744073709551615 + P_45 + 8i0 and
18446744073709551616e1 = -1 + P_45 + 8i0) }
[P_46, P_45] - { :
[GSoC] Elimination of CLooG library installation dependency
Hi Tobias,
I've attached the patch, which should eliminate CLooG library
installation dependency from GCC. The CLooG AST generator is still the
main code generator, but the isl ast generator will be chosen in case
of nonavailability of CLooG library.
However, I've found out a problem. Almost all the functions of the ISL
cannot be used without installed CLooG. (I get errors which contain
“undefined reference to...”). Maybe I missed something. What do you
think about this?
I also have a few questions about gcc. Could you please answer them?
Should Makefile.in be regenerated or manually changed? (I haven't
found out how to regenerate it.)
I've used printf to print “The CLooG code generator cannot be used
+(CLooG is not available). The ISL code generator was chosen.\n”.
Should another function be used for this purpose?
--
Cheers, Roman Gareev.
Index: Makefile.in
===
--- Makefile.in (revision 213622)
+++ Makefile.in (working copy)
@@ -219,6 +219,7 @@
HOST_LIBS=$(STAGE1_LIBS); export HOST_LIBS; \
GMPLIBS=$(HOST_GMPLIBS); export GMPLIBS; \
GMPINC=$(HOST_GMPINC); export GMPINC; \
+ ISLLIBS=$(HOST_ISLLIBS); export ISLLIBS; \
ISLINC=$(HOST_ISLINC); export ISLINC; \
CLOOGLIBS=$(HOST_CLOOGLIBS); export CLOOGLIBS; \
CLOOGINC=$(HOST_CLOOGINC); export CLOOGINC; \
@@ -310,6 +311,7 @@
HOST_GMPINC = @gmpinc@
# Where to find ISL
+HOST_ISLLIBS = @isllibs@
HOST_ISLINC = @islinc@
# Where to find CLOOG
Index: Makefile.tpl
===
--- Makefile.tpl(revision 213622)
+++ Makefile.tpl(working copy)
@@ -222,6 +222,7 @@
HOST_LIBS=$(STAGE1_LIBS); export HOST_LIBS; \
GMPLIBS=$(HOST_GMPLIBS); export GMPLIBS; \
GMPINC=$(HOST_GMPINC); export GMPINC; \
+ ISLLIBS=$(HOST_ISLLIBS); export ISLLIBS; \
ISLINC=$(HOST_ISLINC); export ISLINC; \
CLOOGLIBS=$(HOST_CLOOGLIBS); export CLOOGLIBS; \
CLOOGINC=$(HOST_CLOOGINC); export CLOOGINC; \
@@ -313,6 +314,7 @@
HOST_GMPINC = @gmpinc@
# Where to find ISL
+HOST_ISLLIBS = @isllibs@
HOST_ISLINC = @islinc@
# Where to find CLOOG
Index: gcc/config.in
===
--- gcc/config.in (revision 213622)
+++ gcc/config.in (working copy)
@@ -1705,6 +1705,10 @@
#undef HAVE_cloog
#endif
+/* Define if isl is in use. */
+#ifndef USED_FOR_TARGET
+#undef HAVE_isl
+#endif
/* Define if F_SETLKW supported by fcntl. */
#ifndef USED_FOR_TARGET
Index: gcc/configure
===
--- gcc/configure (revision 213622)
+++ gcc/configure (working copy)
@@ -27888,9 +27888,14 @@
+if test x${ISLLIBS} != x ; then
+$as_echo #define HAVE_isl 1 confdefs.h
+fi
+
+
if test x${CLOOGLIBS} != x ; then
$as_echo #define HAVE_cloog 1 confdefs.h
Index: gcc/configure.ac
===
--- gcc/configure.ac(revision 213622)
+++ gcc/configure.ac(working copy)
@@ -5514,6 +5514,9 @@
AC_ARG_VAR(ISLLIBS,[How to link ISL])
AC_ARG_VAR(ISLINC,[How to find ISL include files])
+if test x${ISLLIBS} != x ; then
+ AC_DEFINE(HAVE_isl, 1, [Define if isl is in use.])
+fi
AC_ARG_VAR(CLOOGLIBS,[How to link CLOOG])
AC_ARG_VAR(CLOOGINC,[How to find CLOOG include files])
Index: gcc/graphite-blocking.c
===
--- gcc/graphite-blocking.c (revision 213622)
+++ gcc/graphite-blocking.c (working copy)
@@ -23,14 +23,16 @@
#include config.h
-#ifdef HAVE_cloog
+#ifdef HAVE_isl
#include isl/set.h
#include isl/map.h
#include isl/union_map.h
#include isl/constraint.h
+#ifdef HAVE_cloog
#include cloog/cloog.h
#include cloog/isl/domain.h
#endif
+#endif
#include system.h
#include coretypes.h
@@ -49,7 +51,7 @@
#include tree-data-ref.h
#include sese.h
-#ifdef HAVE_cloog
+#ifdef HAVE_isl
#include graphite-poly.h
Index: gcc/graphite-dependences.c
===
--- gcc/graphite-dependences.c (revision 213622)
+++ gcc/graphite-dependences.c (working copy)
@@ -21,15 +21,17 @@
#include config.h
-#ifdef HAVE_cloog
+#ifdef HAVE_isl
#include isl/set.h
#include isl/map.h
#include isl/union_map.h
#include isl/flow.h
#include isl/constraint.h
+#ifdef HAVE_cloog
#include cloog/cloog.h
#include cloog/isl/domain.h
#endif
+#endif
#include system.h
#include coretypes.h
@@ -49,7 +51,7 @@
#include tree-scalar-evolution.h
#include sese.h
-#ifdef HAVE_cloog
+#ifdef HAVE_isl
#include graphite-poly.h
#include graphite-htab.h
Index: gcc/graphite-interchange.c
===
--- gcc/graphite-interchange.c (revision 213622)
+++ gcc/graphite-interchange.c (working
Re: [GSoC] Elimination of CLooG library installation dependency
On 06/08/2014 17:21, Roman Gareev wrote: Hi Tobias, I've attached the patch, which should eliminate CLooG library installation dependency from GCC. The CLooG AST generator is still the main code generator, but the isl ast generator will be chosen in case of nonavailability of CLooG library. Nice. However, I've found out a problem. Almost all the functions of the ISL cannot be used without installed CLooG. (I get errors which contain “undefined reference to...”). Maybe I missed something. What do you think about this? This is surprising. What is the exact error message? To which library does gcc link (Check with 'ldd cc1')? I wonder if gcc happens to link against the system CLooG/isl instead of the ones you installed? Also, does objdump -x libisl.so show those missing symbols? I also have a few questions about gcc. Could you please answer them? Should Makefile.in be regenerated or manually changed? (I haven't found out how to regenerate.) I think it is manually maintained. I've used printf to print “The CLooG code generator cannot be used +(CLooG is not available). The ISL code generator was chosen.\n”. Should another function be used for this purpose? I have no idea. Let's leave it for now. I expect the CLooG code to disappear very soon. Also, regarding this patch. It seems you mix two important changes. 1) The configure/makefile changes that make cloog optional 2) The switch from isl to cloog Best starting with 2), followed by 1). To commit 2), I would like you to run a wider set of tests (e.g., the LLVM test suite). If this passes successful, we should give a headsup on the GCC mailing list and ask other people to try the new isl support. If now bugs have found, we switch. Cheers, Tobias
