What are '1B' variables ?
Hi all, I'm playing with -fdump-tree-final_cleanup-blocks and I find from time to time '1B' used as a variable or a numerical value, e.g.: # BLOCK 14 freq:1053 # PRED: 12 [99.0%] (false,exec) :; *D.5198 = (char) __c; stdout.10->_IO_write_ptr = D.5198 + 1B; goto (); # SUCC: 16 [100.0%] (fallthru,exec) What does exactly does mean '1B' in this case ? PS: I did try to Google and to browse the source code but I was unsuccessful in both... Regards -- Emmanuel Fleury My major preoccupation is the question, 'What is reality?' -- Philip K. Dick (1975)
Re: What are '1B' variables ?
Emmanuel Fleury writes:
> # BLOCK 14 freq:1053
> # PRED: 12 [99.0%] (false,exec)
> :;
> *D.5198 = (char) __c;
> stdout.10->_IO_write_ptr = D.5198 + 1B;
> goto ();
> # SUCC: 16 [100.0%] (fallthru,exec)
>
> What does exactly does mean '1B' in this case ?
I think it just means 1 byte.
Andrew.
case INTEGER_CST:
if (TREE_CODE (TREE_TYPE (node)) == POINTER_TYPE)
{
/* In the case of a pointer, one may want to divide by the
size of the pointed-to type. Unfortunately, this not
straightforward. The C front-end maps expressions
(int *) 5
int *p; (p + 5)
in such a way that the two INTEGER_CST nodes for "5" have
different values but identical types. In the latter
case, the 5 is multiplied by sizeof (int) in c-common.c
(pointer_int_sum) to convert it to a byte address, and
yet the type of the node is left unchanged. Argh. What
is consistent though is that the number value corresponds
to bytes (UNITS) offset.
NB: Neither of the following divisors can be trivially
used to recover the original literal:
TREE_INT_CST_LOW (TYPE_SIZE_UNIT (TREE_TYPE (node)))
TYPE_PRECISION (TREE_TYPE (TREE_TYPE (node))) */
pp_wide_integer (buffer, TREE_INT_CST_LOW (node));
pp_string (buffer, "B"); /* pseudo-unit */
}
else if (! host_integerp (node, 0))
{
Wrong lib address
Hi I use gdbserver to debug my program. The problem is gdb can't load library file correctly. Belowed is snapshot for my debug process. I think I have set the right path for loading library file. metrodev:/home/chenxi # ppc_8xx-ldd metro.elf libpthread.so.0 => /opt/montavista/pro/devkit/ppc/8xx/target/lib/libpthread.so.0 (0xdead1000) librt.so.1 => /opt/montavista/pro/devkit/ppc/8xx/target/lib/librt.so.1 (0xdead2000) libstdc++.so.5 => /opt/montavista/pro/devkit/ppc/8xx/target/usr/lib/libstdc++.so.5 (0xdead3000) libm.so.6 => /opt/montavista/pro/devkit/ppc/8xx/target/lib/libm.so.6 (0xdead4000) libgcc_s.so.1 => /opt/montavista/pro/devkit/ppc/8xx/target/lib/libgcc_s.so.1 (0xdead5000) libc.so.6 => /opt/montavista/pro/devkit/ppc/8xx/target/lib/libc.so.6 (0xdead6000) /lib/ld.so.1 => /opt/montavista/pro/devkit/ppc/8xx/target/lib/ld.so.1 (0xdead7000) metrodev:/home/chenxi/cpu_io_v106_af/cpu_v106_af/cpu_v/Debug # ppc-linux-gdb metro.elf GNU gdb 6.6 Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "--host=i686-pc-linux-gnu --target=ppc-linux"... === (gdb) set solib-absolute-prefix /opt/montavista/pro/devkit/ppc/8xx/target/ == (gdb) target remote 192.168.70.99:1234 Remote debugging using 192.168.70.99:1234 _start () at ../sysdeps/powerpc/powerpc32/dl-start.S:33 33 ../sysdeps/powerpc/powerpc32/dl-start.S: No such file or directory. in ../sysdeps/powerpc/powerpc32/dl-start.S Current language: auto; currently asm (gdb) b main Breakpoint 1 at 0x1000a5cc: file ../working/src/root.cpp, line 232. (gdb) list 28 in ../sysdeps/powerpc/powerpc32/dl-start.S (gdb) continue Continuing. Error while mapping shared library sections: /mnt/cf/shared/lib/libpthread.so.0: No such file or directory. Error while mapping shared library sections: /mnt/cf/shared/lib/librt.so.1: No such file or directory. Error while mapping shared library sections: /mnt/cf/shared/lib/libstdc++.so.5: No such file or directory. Error while mapping shared library sections: /mnt/cf/shared/lib/libm.so.6: No such file or directory. Breakpoint 1, main (argc=2147483016, argv=0xfc32da4) at ../working/src/root.cpp:232 232 pthread_attr_init( &init_attr ); Current language: auto; currently c++ (gdb) info sharedlibrary >FromTo Syms Read Shared Object Library 0x30001f90 0x30013760 Yes /opt/montavista/pro/devkit/ppc/8xx/target/lib/ld.so.1 No /mnt/cf/shared/lib/libpthread.so.0 No /mnt/cf/shared/lib/librt.so.1 No /mnt/cf/shared/lib/libstdc++.so.5 No /mnt/cf/shared/lib/libm.so.6 0x0fd7da40 0x0fd86f3c Yes /opt/montavista/pro/devkit/ppc/8xx/target/lib/libgcc_s.so.1 0x0fc32ad0 0x0fd3a1fc Yes /opt/montavista/pro/devkit/ppc/8xx/target/lib/libc.so.6 (gdb) I don't know why the path changed to /mnt/cf/shared/lib, this is my target lib path. I just know gcc -print-search-dirs to display the the lib path for compile. Could anyone tell me the parameter to display the lib path for running and how can I change the lib path. Set LD_LIBRARY_PATH or other else. Thx, Xi
Comment mismatch in tree-cfg.c:verify_gimple_expr
Richard, this comment does not match the code. The code allows type conversions between two integral types and between arbitrary types that happen to *not* be integral. Which semantics did you mean here? /* Allow conversions between integral types. */ if (INTEGRAL_TYPE_P (type) == INTEGRAL_TYPE_P (TREE_TYPE (op))) return false; I'm thinking this should be && not ==. Thanks.
Re: Comment mismatch in tree-cfg.c:verify_gimple_expr
On Fri, 31 Aug 2007, Richard Guenther wrote: > On Fri, 31 Aug 2007, Diego Novillo wrote: > > > > > Richard, this comment does not match the code. The code allows type > > conversions between two integral types and between arbitrary types that > > happen to *not* be integral. Which semantics did you mean here? > > > > /* Allow conversions between integral types. */ > > if (INTEGRAL_TYPE_P (type) == INTEGRAL_TYPE_P (TREE_TYPE (op))) > > return false; > > > > I'm thinking this should be && not ==. > > Whoops. Indeed. Now - no guarantee that this won't "break" anything > of course... (I'll check on the mainline) I'm checking the following. Richard. 2007-08-31 Richard Guenther <[EMAIL PROTECTED]> * tree-cfg.c (verify_gimple_expr): Fix check for conversions between integral types. Also allow conversions between pointer types. Index: tree-cfg.c === *** tree-cfg.c (revision 127968) --- tree-cfg.c (working copy) *** verify_gimple_expr (tree expr) *** 3574,3581 return true; } ! /* Allow conversions between integral types. */ ! if (INTEGRAL_TYPE_P (type) == INTEGRAL_TYPE_P (TREE_TYPE (op))) return false; /* Allow conversions between integral types and pointers only if --- 3574,3583 return true; } ! /* Allow conversions between integral types and between ! pointer types. */ ! if ((INTEGRAL_TYPE_P (type) && INTEGRAL_TYPE_P (TREE_TYPE (op))) ! || (POINTER_TYPE_P (type) && POINTER_TYPE_P (TREE_TYPE (op return false; /* Allow conversions between integral types and pointers only if
Error in c-lex.c
Hello, I get the following error running trunk r127993 with --enable-checking=assert on ppc64: gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute-DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber ../../gcc/gcc/c-lex.c -o c-lex.o ../../gcc/gcc/c-lex.c: In function גinterpret_floatג: ../../gcc/gcc/c-lex.c:645: error: גCPP_N_FRACTג undeclared (first use in this function) ../../gcc/gcc/c-lex.c:645: error: (Each undeclared identifier is reported only once ../../gcc/gcc/c-lex.c:645: error: for each function it appears in.) ../../gcc/gcc/c-lex.c:645: error: גCPP_N_ACCUMג undeclared (first use in this function) ../../gcc/gcc/c-lex.c: In function גinterpret_fixedג: ../../gcc/gcc/c-lex.c:753: error: גCPP_N_FRACTג undeclared (first use in this function) make[3]: *** [c-lex.o] Error 1 Thanks, Revital
Re: Comment mismatch in tree-cfg.c:verify_gimple_expr
On Fri, 31 Aug 2007, Diego Novillo wrote: > > Richard, this comment does not match the code. The code allows type > conversions between two integral types and between arbitrary types that > happen to *not* be integral. Which semantics did you mean here? > > /* Allow conversions between integral types. */ > if (INTEGRAL_TYPE_P (type) == INTEGRAL_TYPE_P (TREE_TYPE (op))) > return false; > > I'm thinking this should be && not ==. Whoops. Indeed. Now - no guarantee that this won't "break" anything of course... (I'll check on the mainline) Richard.
Re: Stage 2 project: upgrade decNumber
On Thu, Aug 30, 2007 at 07:25:35PM -0700, Mark Mitchell wrote: > FWIW, keeping this as much like the upstream sources as possible seems > desirable to me; I'd probably do the C++ comments and leave it at that, > just to ease future merges. But, that's just my two cents. I suggest asking upstream to accept a patch to use traditional C-style comments, to increase the portability of the library (and to make future merges a no-op). But there's no reason to re-format to follow GNU style rules, as it's an external library.
Re: What are '1B' variables ?
On 8/31/07, Emmanuel Fleury <[EMAIL PROTECTED]> wrote: > Hi all, > > I'm playing with -fdump-tree-final_cleanup-blocks and I find from time > to time '1B' used as a variable or a numerical value, e.g.: > > # BLOCK 14 freq:1053 > # PRED: 12 [99.0%] (false,exec) > :; > *D.5198 = (char) __c; > stdout.10->_IO_write_ptr = D.5198 + 1B; > goto (); > # SUCC: 16 [100.0%] (fallthru,exec) > > What does exactly does mean '1B' in this case ? it means 1 byte (aka 1 in a pointer type). But I notice you are using a pre pointer plus expression compiler. You might be better off looking into using the current trunk (which will become 4.3) as pointer addition was changed there so there are almost no 1B's left. -- Pinski
RE: Error in c-lex.c
Revital1 Eres wrote: > > I get the following error running trunk r127993 with > --enable-checking=assert on ppc64: > > gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall > -Wwrite-strings > -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition > -Wmissing-format-attribute-DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc > -I../../gcc/gcc/. -I../../gcc/gcc/../include > -I../../gcc/gcc/../libcpp/include -I../../gcc/gcc/../libdecnumber > -I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber > ../../gcc/gcc/c-lex.c -o c-lex.o > ../../gcc/gcc/c-lex.c: In function גinterpret_floatג: > ../../gcc/gcc/c-lex.c:645: error: גCPP_N_FRACTג undeclared > (first use in > this function) > ../../gcc/gcc/c-lex.c:645: error: (Each undeclared identifier > is reported > only once > ../../gcc/gcc/c-lex.c:645: error: for each function it appears in.) > ../../gcc/gcc/c-lex.c:645: error: גCPP_N_ACCUMג undeclared > (first use in > this function) > ../../gcc/gcc/c-lex.c: In function גinterpret_fixedג: > ../../gcc/gcc/c-lex.c:753: error: גCPP_N_FRACTג undeclared > (first use in > this function) > make[3]: *** [c-lex.o] Error 1 > > Thanks, > Revital > We need to update gcc/libcpp in order to get these definitions. Thanks a lot! Regards, Chao-ying
Re: MacOS X Ada patches?
Sorry to reply one month late: if you're refering to the June 9th discussion I believe it ended by Andrew Reynolds hinting he will resubmit some needed patches and Eric Christopher expressed interest in seeing those patches. Checking the changelogs I'm unable to spot any relevant patch, Andrew did you submit them? Thanks in advance, Laurent On Mon, 2007-07-23 at 23:39 -0400, Jack Howarth wrote: > I recall one of the Ada developers mentioning that there > were patches available from another Mac OS X Ada project > which could be backported to gcc trunk to complete the > support for Ada on Mac OS X. I believe the issues were > related to the creation of shared libraries for Ada > on Darwin. Does anyone know about the status of these > patches? It would be a shame to have yet another gcc > release without proper support for Ada on Mac OS X. > Jack >
Build failure on Darwin, revision 127998
After an update to revision 127998 (from 127986), make failed with: make[3]: Nothing to be done for `all'. true "AR_FLAGS=rc" "CC_FOR_BUILD=/opt/gcc/darwin_buildw/./prev-gcc/xgcc -B/opt/gcc/darwin_buildw/./prev-gcc/ -B/opt/gcc/gcc4.3w/powerpc-apple-darwin8/bin/" "CFLAGS=-g -O2" "CXXFLAGS=-g -O2" "CFLAGS_FOR_BUILD=-g -O2" "CFLAGS_FOR_TARGET=-O2 -g -O2 " "INSTALL=/sw/bin/ginstall -c" "INSTALL_DATA=/sw/bin/ginstall -c -m 644" "INSTALL_PROGRAM=/sw/bin/ginstall -c" "INSTALL_SCRIPT=/sw/bin/ginstall -c" "LDFLAGS=" "LIBCFLAGS=-g -O2" "LIBCFLAGS_FOR_TARGET=-O2 -g -O2 " "MAKE=make" "MAKEINFO=makeinfo --split-size=500 --split-size=500 --split-size=500 " "PICFLAG=" "PICFLAG_FOR_TARGET=" "SHELL=/bin/sh" "EXPECT=expect" "RUNTEST=runtest" "RUNTESTFLAGS=" "exec_prefix=/opt/gcc/gcc4.3w" "infodir=/opt/gcc/gcc4.3w/share/info" "libdir=/opt/gcc/gcc4.3w/lib" "prefix=/opt/gcc/gcc4.3w" "tooldir=/opt/gcc/gcc4.3w/powerpc-apple-darwin8" "AR=ar" "AS=as" "CC=/opt/gcc/darwin_buildw/./prev-gcc/xgcc -B/opt/gcc/darwin_buildw/./prev-gcc/ -B/opt/gcc/gcc4.3w/powerpc-apple-darwin8/bin/" "CXX=g++" "LD=ld" "LIBCFLAGS=-g -O2" "NM=nm" "PICFLAG=" "RANLIB=ranlib" "DESTDIR=" DO=all multi-do # make make[3]: Nothing to be done for `all'. make[3]: Nothing to be done for `all'. build/gengtype ../../gcc-4.3-work/gcc gtyp-input.list echo timestamp > s-gtype /opt/gcc/darwin_buildw/./prev-gcc/xgcc -B/opt/gcc/darwin_buildw/./prev-gcc/ -B/opt/gcc/gcc4.3w/powerpc-apple-darwin8/bin/ -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../../gcc-4.3-work/gcc -I../../gcc-4.3-work/gcc/build -I../../gcc-4.3-work/gcc/../include -I../../gcc-4.3-work/gcc/../libcpp/include -I/sw/include -I../../gcc-4.3-work/gcc/../libdecnumber -I../../gcc-4.3-work/gcc/../libdecnumber/dpd -I../libdecnumber -I/sw/include -o build/rtl.o ../../gcc-4.3-work/gcc/rtl.c /var/tmp//cc5X0jZP.s:765:non-relocatable subtraction expression, "___FUNCTION__.13184" minus "L006$pb" /var/tmp//cc5X0jZP.s:765:symbol: "___FUNCTION__.13184" can't be undefined in a subtraction expression /var/tmp//cc5X0jZP.s:763:non-relocatable subtraction expression, "___FUNCTION__.13184" minus "L006$pb" /var/tmp//cc5X0jZP.s:763:symbol: "___FUNCTION__.13184" can't be undefined in a subtraction expression /var/tmp//cc5X0jZP.s:511:non-relocatable subtraction expression, "___FUNCTION__.13132" minus "L004$pb" /var/tmp//cc5X0jZP.s:511:symbol: "___FUNCTION__.13132" can't be undefined in a subtraction expression /var/tmp//cc5X0jZP.s:509:non-relocatable subtraction expression, "___FUNCTION__.13132" minus "L004$pb" /var/tmp//cc5X0jZP.s:509:symbol: "___FUNCTION__.13132" can't be undefined in a subtraction expression /var/tmp//cc5X0jZP.s:239:non-relocatable subtraction expression, "___FUNCTION__.13259" minus "L003$pb" /var/tmp//cc5X0jZP.s:239:symbol: "___FUNCTION__.13259" can't be undefined in a subtraction expression /var/tmp//cc5X0jZP.s:237:non-relocatable subtraction expression, "___FUNCTION__.13259" minus "L003$pb" /var/tmp//cc5X0jZP.s:237:symbol: "___FUNCTION__.13259" can't be undefined in a subtraction expression make[3]: *** [build/rtl.o] Error 1 make[2]: *** [all-stage2-gcc] Error 2 make[1]: *** [stage2-bubble] Error 2 make: *** [all] Error 2 Any idea? TIA Dominique
building libgcc
I have spend the morning tracking down a bug that shows up only for a bootstrapped compiler. This is on i686-pc-linux-gnu. The bug is in libgcc:bid64_add.c The reason that the problem does not show up for the stage1 compile is that libgcc is built without -fomit-frame-pointer in the stage1 build and with -fomit-frame-pointer in the stage3 build. Aside from that the command lines are the same. This seems like a bug. Any comments? stage1 command /gondorpublic/gbG2/./gcc/xgcc -B/gondorpublic/gbG2/./gcc/ -B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/ -isystem /usr/local/i686-pc-linux-gnu/include -isystem /usr/local/i686-pc-linux-gnu/sys-include -O2 -g -O2 -O2 -g -O2 -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../.././gcc -I/home/zadeck/gccGlobal/libgcc -I/home/zadeck/gccGlobal/libgcc/. -I/home/zadeck/gccGlobal/libgcc/../gcc -I/home/zadeck/gccGlobal/libgcc/../include -I/home/zadeck/gccGlobal/libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS -DUSE_TLS -o bid64_add.o -MT bid64_add.o -MD -MP -MF bid64_add.dep -c /home/zadeck/gccGlobal/libgcc/config/libbid/bid64_add.c stage3 command /gondorpublic/gbGlobal/./gcc/xgcc -B/gondorpublic/gbGlobal/./gcc/ -B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/ -isystem /usr/local/i686-pc-linux-gnu/include -isystem /usr/local/i686-pc-linux-gnu/sys-include -g -O2 -fomit-frame-pointer -O2 -O2 -g -O2 -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../.././gcc -I/home/zadeck/gccGlobal/libgcc -I/home/zadeck/gccGlobal/libgcc/. -I/home/zadeck/gccGlobal/libgcc/../gcc -I/home/zadeck/gccGlobal/libgcc/../include -I/home/zadeck/gccGlobal/libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS -DUSE_TLS -o bid64_add.o -MT bid64_add.o -MD -MP -MF bid64_add.dep -c /home/zadeck/gccGlobal/libgcc/config/libbid/bid64_add.c Kenny
Re: building libgcc
On 8/31/07, Kenneth Zadeck <[EMAIL PROTECTED]> wrote: > The reason that the problem does not show up for the stage1 compile is > that libgcc is built without -fomit-frame-pointer in the stage1 build > and with -fomit-frame-pointer in the stage3 build. Aside from that the > command lines are the same. I think this is related to PR 32161. -- Pinski
Re: MacOS X Ada patches?
Hi Laurent, I submitted the patches that were approved but I don't have commit privileges to the GCC tree. I asked Arno to submit them and he never got back to me. I will be submitting new patches that include Leopard and x86_64 support. I will post the patches to my web site as well as the current builds for each of the compilers at the end of the long weekend. My web site: http:/homepage.mac.com/awreynolds AdaCore has already added x86 support to the Make files. I have a fix for the dynamic library support that includes the installation path in the library so that applications can find the correct version. This patch will not be submitted until I find a better approach than hard coding the path. Andrew W. Reynolds GNAT for Mac OS X Development Team Compiler/Run-Time System/Bindings/Sample Code On Friday, August 31, 2007, at 03:16PM, "Laurent GUERBY" <[EMAIL PROTECTED]> wrote: >Sorry to reply one month late: if you're refering to the >June 9th discussion I believe it ended by Andrew Reynolds >hinting he will resubmit some needed patches and >Eric Christopher expressed interest in seeing those patches. > >Checking the changelogs I'm unable to spot any relevant patch, >Andrew did you submit them? > >Thanks in advance, > >Laurent > >On Mon, 2007-07-23 at 23:39 -0400, Jack Howarth wrote: >> I recall one of the Ada developers mentioning that there >> were patches available from another Mac OS X Ada project >> which could be backported to gcc trunk to complete the >> support for Ada on Mac OS X. I believe the issues were >> related to the creation of shared libraries for Ada >> on Darwin. Does anyone know about the status of these >> patches? It would be a shame to have yet another gcc >> release without proper support for Ada on Mac OS X. >> Jack >> > > >
DFA Scheduler - unable to pipeline loads
Hi, I am working with GCC-4.1.1 on a simple 5-pipe stage simple scalar RISC processors with the following description for loads and stores, (define_insn_reservation "integer" 1 (eq_attr "type" "branch,jump,call,arith,darith,icmp,nop") "issue,iu,wb") (define_insn_reservation "load" 3 (eq_attr "type" "load") "issue,iu,wb") (define_insn_reservation "store" 1 (eq_attr "type" "store") "issue,iu,wb") I am seeing poor scheduling in Dhrystone where a memcpy call is expanded inline. memcpy (&dst, &src, 16) ==> load 1, rA + 4 store 1, rB + 4 load 2, rA + 8 store 2, rB + 8 ... Basically, instead of pipelining the loads, the current schedule stalls the processor for two cycles on every dependent store. Here is a dump from the .35.sched1 file. ;; == ;; -- basic block 0 from 6 to 36 -- before reload ;; == ;;0--> 6r84=r5 :issue,iu,wb ;;1--> 13 r86=[`Ptr_Glob'] :issue,iu,wb ;;2--> 25 r92=0x5:issue,iu,wb ;;3--> 12 r85=[r84] :issue,iu,wb ;;4--> 14 r87=[r86] :issue,iu,wb ;;7--> 15 [r85]=r87 :issue,iu,wb ;;8--> 16 r88=[r86+0x4] :issue,iu,wb ;; 11--> 17 [r85+0x4]=r88 :issue,iu,wb ;; 12--> 18 r89=[r86+0x8] :issue,iu,wb ;; 15--> 19 [r85+0x8]=r89 :issue,iu,wb ;; 16--> 20 r90=[r86+0xc] :issue,iu,wb ;; 19--> 21 [r85+0xc]=r90 :issue,iu,wb ;; 20--> 22 r91=[r86+0x10] :issue,iu,wb ;; 23--> 23 [r85+0x10]=r91 :issue,iu,wb ;; 24--> 26 [r84+0xc]=r92 :issue,iu,wb ;; 25--> 31 clobber r3 :nothing ;; 25--> 36 use r3 :nothing ;; Ready list (final): ;; total time = 25 ;; new head = 7 ;; new tail = 36 There is an obvious better schedule to be obtained. Here is one such (hand-modified) schedule which just pipelines two of the loads to obtain a shorter critical path length to the whole function (function has only bb 0) ;;0--> 6r84=r5 :issue,iu,wb ;;1--> 13 r86=[`Ptr_Glob'] :issue,iu,wb ;;2--> 25 r92=0x5:issue,iu,wb ;;3--> 12 r85=[r84] :issue,iu,wb ;;4--> 14 r87=[r86] :issue,iu,wb ;;7--> 15 [r85]=r87 :issue,iu,wb ;;8--> 16 r88=[r86+0x4] :issue,iu,wb ;;9--> 18 r89=[r86+0x8] :issue,iu,wb ;; 10--> 20 r90=[r86+0xc] :issue,iu,wb ;; 11--> 17 [r85+0x4]=r88 :issue,iu,wb ;; 12--> 19 [r85+0x8]=r89 :issue,iu,wb ;; 13--> 21 [r85+0xc]=r90 :issue,iu,wb ;; 14--> 22 r91=[r86+0x10] :issue,iu,wb ;; 17--> 23 [r85+0x10]=r91 :issue,iu,wb ;; 18--> 26 [r84+0xc]=r92 :issue,iu,mb_wb ;; 19--> 31 clobber r3 :nothing ;; 20--> 36 use r3 :nothing ;; Ready list (final): ;; total time = 20 ;; new head = 7 ;; new tail = 36 This schedule is 5 cycles faster. I have read and re-read the material surrounding the DFA scheduler. I understand that the heuristics optimize critical path length and not stalls or other metrics. But in this case it is precisely the critical path length that is shortened by the better schedule. I have been examining various hooks available and for a while it seemed like TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD must be set to a larger window to look for better candidates to schedule into the ready queue. For instance, this discussion seems to say so. http://gcc.gnu.org/ml/gcc/2002-05/msg01132.html But a post that follows soon after seems to imply otherwise. http://gcc.gnu.org/ml/gcc/2002-05/msg01388.html Both posts are from Vladimir. In any case the final conclusion seems to be that the lookahead is useful only for multi-issue processors. So what is wrong in my description? How do I get GCC to produce the optimal schedule? I appreciate any help as I have run into a similiar scheduling situation with other architectures in the past (GCC seems to choose not to pipeline things as much as it can) and this time I would like to understand it a bit more. Compile flags used are basically, -O3. -- thanks, Matt
gcc-4.3-20070831 is now available
Snapshot gcc-4.3-20070831 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20070831/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.3 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 128003 You'll find: gcc-4.3-20070831.tar.bz2 Complete GCC (includes all of below) gcc-core-4.3-20070831.tar.bz2 C front end and core compiler gcc-ada-4.3-20070831.tar.bz2 Ada front end and runtime gcc-fortran-4.3-20070831.tar.bz2 Fortran front end and runtime gcc-g++-4.3-20070831.tar.bz2 C++ front end and runtime gcc-java-4.3-20070831.tar.bz2 Java front end and runtime gcc-objc-4.3-20070831.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.3-20070831.tar.bz2The GCC testsuite Diffs from 4.3-20070824 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.3 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
RFC: Hack to make restrict more useful
This bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33272 is about a situation in which -fargument-noalias works better than putting "restrict" on all pointer arguments to a function, even though that should be logically equivalent. Using "restrict" for all arguments to a function is probably one of the most common cases of "restrict"; that's what you want for things like the test case I posted, and for other Fortran-ish code. I have a prototype hack which changes checks of flag_argument_noalias != 0 to also check for the presence of "restrict" on all pointer arguments. This fixes the test case, modulo a C front-end bug which Joseph has volunteered to fix. To make that a real patch, here's what I plan to do: (1) Add a flag to "struct function" to say "all pointer arguments are restrict". (2) Lazily set it, when something wants to check it. (3) Change checks of flag_argument_noalias to call a function argument_noalias() which will return an "int" with the same meaning as flag_argument_noalias. Does that plan sound OK to folks? -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Stage 2 project: new interference graph representation.
Peter Bergner wrote: > As a somewhat related follow on to Kenny's new interference graph > builder patch (which is still waiting for a full review): > > http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01729.html > > I'd like to squeeze in a new representation of the interference graph > that in some cases can save a significant amount of memory. That sounds exciting. If you can get it done, and the middle-end maintainers feel confident in the code, it's fine by me. Thanks for the heads-up! -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: DFA Scheduler - unable to pipeline loads
"Matt Lee" <[EMAIL PROTECTED]> writes: > I am seeing poor scheduling in Dhrystone where a memcpy call is > expanded inline. > > memcpy (&dst, &src, 16) ==> > > load 1, rA + 4 > store 1, rB + 4 > load 2, rA + 8 > store 2, rB + 8 > ... Are you sure that there are no dependencies due to aliasing here. The only similar thing that Dhrystone has to what you quote is between a pointer and a global variable and in fact there is an aliasing conflict there. If that is the case you can define a movmem pattern where you first load everthing in one chunk and then store it later. See MIPS's movmemsi pattern and the function mips_block_move_straight. Adam
Re: Stage 2 project: new interference graph representation.
Mark Mitchell wrote: > Peter Bergner wrote: > >> As a somewhat related follow on to Kenny's new interference graph >> builder patch (which is still waiting for a full review): >> >> http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01729.html >> >> I'd like to squeeze in a new representation of the interference graph >> that in some cases can save a significant amount of memory. >> > > That sounds exciting. If you can get it done, and the middle-end > maintainers feel confident in the code, it's fine by me. > > Thanks for the heads-up! > > Yes, and of course, i plan to have my interference graph builder finished this weekend. I am down to the last bug on the 4th platform. thanks Kenny
