Re: [tuples] Call for help converting passes
On Mon, Feb 11, 2008 at 2:50 PM, Zdenek Dvorak <[EMAIL PROTECTED]> wrote: > I will take care of the loop optimizer passes. Awesome. Thanks! Diego.
Re: [tuples] Call for help converting passes
Hi, > Everything else should work well enough for passes to be converted. > If anyone has some free cycles and are willing to put up with various > broken bits, would you be willing to help converting passes? There is > a list of the passes that need conversion in the tuples wiki > (http://gcc.gnu.org/wiki/tuples). Passes that have already been > converted or are being converted are marked. I will take care of the loop optimizer passes. Zdenek
gcc-4.1-20080211 is now available
Snapshot gcc-4.1-20080211 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20080211/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.1 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_1-branch revision 132243 You'll find: gcc-4.1-20080211.tar.bz2 Complete GCC (includes all of below) gcc-core-4.1-20080211.tar.bz2 C front end and core compiler gcc-ada-4.1-20080211.tar.bz2 Ada front end and runtime gcc-fortran-4.1-20080211.tar.bz2 Fortran front end and runtime gcc-g++-4.1-20080211.tar.bz2 C++ front end and runtime gcc-java-4.1-20080211.tar.bz2 Java front end and runtime gcc-objc-4.1-20080211.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.1-20080211.tar.bz2The GCC testsuite Diffs from 4.1-20080204 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.1 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
RE: Request For Help with GCC Tests
On 11 February 2008 16:53, Joel Sherrill wrote: > Is there someone out there who can walk me through > the steps necessary to run them cross on a simulator? > I will need to test an installed toolset and > will have to be able to specify: > > + an extra object file to link with. > + target CFLAGS and LDFLAGS > + command to run simulator > > I know all of these from running ACATS. > > Please help me get over the first time so the RTEMS > targets can provide some gcc feedback. Thread has moved to the dejagnu list, if anyone's interested. F-ups set. cheers, DaveK -- Can't think of a witty .sigline today
Re: Some 4.4 project musings
On 11 Feb 2008, at 14:49, Diego Novillo wrote: On Fri, Feb 1, 2008 at 3:55 PM, Andrew MacLeod <[EMAIL PROTECTED]> wrote: 1 - Pass cleanup. There have been rumblings about this, but I haven't seen a lot of actual progress. We currently run 100's of passes all the time, and we don't really know how effective or necessary many of them are. We also don't know whether the cleanups they run are truly doing much. It would be nice to do some actual analysis and do something with the results. Yes, this is an area that is in desperate need of TLC. Your plan looks good to me. We need to have a mechanism to determine whether a pass did something, we need to be able to have different pipelines for different architectures. Do you have anything specific in mind? Create a branch? Work directly on mainline? Perhaps the first stage would be to define the logging so we can start doing some analysis. I believe the work we did for CGO'08 is relevant here. We came up with an automated way to select combinations of passes which perform well as candidate optimization levels. We trade off compilation time vs execution time in the paper, but the framework we came up with is more general than that. We had some nice results, showing that using only 25% of the passes activated at -O3 were enough to come up with candidate optimization levels which significantly outperform -O1/2/3, especially in terms of compilation time. There is an overview of the key passes in the paper, along with a description of how we handled things... If you guys are interested, you can find the paper on my website (http://www.elis.ugent.be/~kehoste ), and I'll be happy to provide more info if needed, just shout. Or come and see my talk at CGO in April ;-) Kenneth -- Computer Science is no more about computers than astronomy is about telescopes. (E. W. Dijkstra) Kenneth Hoste ELIS - Ghent University email: [EMAIL PROTECTED] blog: http://www.elis.ugent.be/~kehoste/blog website: http://www.elis.ugent.be/~kehoste
Re: Is anyone testing for a (cross-) target (board) with dynlinking?
> Date: Mon, 11 Feb 2008 18:04:52 -0800 > From: Nathan Froyd <[EMAIL PROTECTED]> > On Tue, Feb 12, 2008 at 02:47:39AM +0100, Hans-Peter Nilsson wrote: > > Is it as simple as nobody having tested cross-gcc setups for > > targets with dynamic linking, or are they incorrectly using the > > wrong (the installed, not the newly compiled) libgcc_s.so.1? > > > > Or how did you do it? NFS mounts on target and > > "env LD_LIBRARY_PATH=... make check"? > > One way to do it is with NFS mounts and setting -Wl,-dynamic-linker > -Wl,-rpath for your ldflags. Thanks to you and David Daney. Have you used it yourself? Apparently tricks are needed as the -rpath is used both at run-time and at link-time, ld complains about "No such file or directory" if the path doesn't exist on the host side. I think I'll look into fixing gcc so no tricks are needed and that libraries are copied to the target automatically. brgds, H-P
Is anyone testing for a (cross-) target (board) with dynlinking?
Cross-compiling from "one Linux/GNU" to another, different
arches. In my case, from x86_64-unknown-linux-gnu to
crisv32-axis-linux-gnu. Replace with arm, mips, ppc or yourarch
as you please; you should see the same thing. When you've
eventually added the required telnet_exec support needed due to
the lack of rsh support on your target ("only" telnet and ftp),
and you get the files over to the target and chmod +x:ed, you'll
get (wrapped):
/tmp/2112-1.x0.23789: error while loading shared libraries:
libgcc_s.so.1: cannot load shared object file: No such file or directory^M
Looking closer, I don't see anything in the gcc testsuite files
dealing with putting libgcc_s.so.1 on the target. It does set
LD_LIBRARY_PATH, except for is_remote targets where it returns
early, after the terse comment
# Setting the ld library path causes trouble when testing cross-compilers.
which is presumably because for the *compiler* it'd cause
problems, but for the *testcase*, it's certainly needed for
targets with dynamic linking. I'd rather not do the equivalent of
set_board_info ldflags "-static"
because that'd remove most of the value of this setup; I already
do that in a simulator setup.
Is it as simple as nobody having tested cross-gcc setups for
targets with dynamic linking, or are they incorrectly using the
wrong (the installed, not the newly compiled) libgcc_s.so.1?
Or how did you do it? NFS mounts on target and
"env LD_LIBRARY_PATH=... make check"?
brgds, H-P
Request For Help with GCC Tests
Hi, I can now run the ACATS reasonably automatically and test powerpc, sparc, and i386 RTEMS targets. I would like to keep my momentum going and get some results on the non-Ada tests. Is there someone out there who can walk me through the steps necessary to run them cross on a simulator? I will need to test an installed toolset and will have to be able to specify: + an extra object file to link with. + target CFLAGS and LDFLAGS + command to run simulator I know all of these from running ACATS. Please help me get over the first time so the RTEMS targets can provide some gcc feedback. Thanks. -- Joel Sherrill, Ph.D. Director of Research & Development [EMAIL PROTECTED]On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
Re: Does Ada build on Linux/ia32?
> My patch will only change alignment for long long scalars and arrays. > What alignments do Ada expect for long long on ia32? Does Ada expect > 8 byte alignments for struct/record? AFAICS your patch will downgrade the alignment of DImode, not just long long. It looks like the Ada compiler expects DImode to be aligned according to its size, like other integral modes. I'd suggest to distill a reduced testcase and debug side-by-side in decl.o (the error message is issued there) against the pristine compiler, maybe it's only an oversight. -- Eric Botcazou
Re: Does Ada build on Linux/ia32?
> I don't know Ada to create a testcase. Can some Ada people help out? It's not very different from C++. Start from the command line you posted and remove code simultaneously from s-pack33.ads (roughly the .h file) and from s-pack33.adb (roughly the .C file). Then put a breakpoint in decl.c where the error message is issued and try to find out why it is issued with the modified compiler and why it is not with the pristine compiler. -- Eric Botcazou
Re: ACATS Results for powerpc-rtems on Trunk
Duncan Sands wrote: Hi, 4.2.3 only failed c380004, c761007, and c953002. c380004 can be considered to be an expected failure. It also fails on x86-linux, and this is normal because the code produced by the front-end (gcc-4.2) can't possibly pass. Thanks. I did a lot of testing over the weekend and just posted the ACATS results on gcc-testresults. The PR now has a patch applied to it which gives ACATS results for SPARC and PowerPC on the trunk which are comparable to 4.2.3. --joel Best wishes, Duncan. -- Joel Sherrill, Ph.D. Director of Research & Development [EMAIL PROTECTED]On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
Re: Some 4.4 project musings
On Fri, Feb 1, 2008 at 3:55 PM, Andrew MacLeod <[EMAIL PROTECTED]> wrote: > 1 - Pass cleanup. There have been rumblings about this, but I haven't > seen a lot of actual progress. We currently run 100's of passes all the > time, and we don't really know how effective or necessary many of them > are. We also don't know whether the cleanups they run are truly doing > much. It would be nice to do some actual analysis and do something with > the results. Yes, this is an area that is in desperate need of TLC. Your plan looks good to me. We need to have a mechanism to determine whether a pass did something, we need to be able to have different pipelines for different architectures. Do you have anything specific in mind? Create a branch? Work directly on mainline? Perhaps the first stage would be to define the logging so we can start doing some analysis. > 2 - Interface to the virtual operands. The virtual operand web provides > what really amounts to low level detail of memory accesses. Every pass > that cares about memory access ends up interpreting the data and dealing > with the VOP web modification itself. This is in some ways analogous to > every pass having to implement bsi_insert() itself. It would be nice if > there was one standard central interpreter of the data that knows how to > view and modify the web. Richi is working on an alias oracle of some > sort, I'm not sure of its details so I don't know how far it delves into > this sort of thing, or what approach it takes. Yes, we have to stop relying on the accuracy of the memory ssa web to do memory optimizations. It should just be used to produce a conservative answer. Anything that we want to keep in too much detail only blows memory utilization and compile time. One additional thing I want to have in this area is the ability to completely turn off alias analysis. We have run into several pathological cases that take the compiler out for a long spin. Dan has fixed the ones we found in PTA, I'm on the hook to fix one in memory partitioning, but in general I would like to have a Big Switch we can use in extreme cases. This is useful when you are dealing with a soon-to-be-released compiler and don't want to muck around something like alias analysis. In fact, it would be useful to have a generic time-out mechanism for passes to use. This way, users could place a limit on the amount of optimization effort they want the compiler to spend. I think this would be better implemented as a polling mechanism and passes should be responsible for undoing their own actions. I'm not really sure how to go about it in general. I think the amount of automatic infrastructure we can provide here is limited because most of the interesting work will be pass-specific. > 3 - SRA. There appear to be some deficiencies in SRA, and also how it > interacts with the MEMSSA partitioner. I found when looking at some 4.3 > bugs that its never as simple as looking at the base and offset, at > least not consistently. Most of it appears to be > first-implementation-itis, the discovering of new issues as you go. > Stepping back and reviewing the functional requirements and its > interaction with the partitioner should be useful. Agreed. SRA needs a new implementation. > 4 - SSA pressure reduction. I'm throwing this back on the table. I never > quite got around to it before, and nothing has changed to resolve the > issues. We freely create as much register pressure in the SSA optimizers > as we want (as we should be able to). The backend has doing nothing to > address the issue and the RTL register allocator is simply swamped by > the sheer quantity of live ranges sometimes. Perhaps Vlad's RA will get > in this release, and/or perhaps the need for this will be eliminated by > something else, but it is something that may help code generation in the > short term at least. What about the RTL expansion from SSA directly? This is an area that is going to affect the tuples branch very soon. We are currently going into RTL from tuples directly (no TER), but since most passes have not been converted, I can yet tell how much of a problem this is. In a few weeks we'll hit this problem. > If anyone is interested in any of these tasks, or has any > questions/observations/criticisms, please let me know. (I know you will! > :-) Definitely interested in #1 and #2. Though #4 will probably affect me the most short-term. Diego.
Re: Volunteer for a Beginner's Project: Header-Header Interdependencies
Jonathan Adamczewski <[EMAIL PROTECTED]> writes: > NightStrike wrote: > > What is gcc's irc server? > > > > > #gcc on irc.oftc.net Which is mentioned on http://gcc.gnu.org/wiki , by the way. Ian
Re: Is anyone testing for a (cross-) target (board) with dynlinking?
Hans-Peter Nilsson wrote:
Cross-compiling from "one Linux/GNU" to another, different
arches. In my case, from x86_64-unknown-linux-gnu to
crisv32-axis-linux-gnu. Replace with arm, mips, ppc or yourarch
as you please; you should see the same thing. When you've
eventually added the required telnet_exec support needed due to
the lack of rsh support on your target ("only" telnet and ftp),
I had a lot of problem with ftp and telnet, so I built rsh/rcp for the
target. They seem to work well.
and you get the files over to the target and chmod +x:ed, you'll
get (wrapped):
/tmp/2112-1.x0.23789: error while loading shared libraries:
libgcc_s.so.1: cannot load shared object file: No such file or directory^M
I don't know what others do, but I always manually copy all the target
libraries to the target board before running the testsuite remotely.
All my remote testing has been on a mipsel-linux-gnu target.
David Daney
Re: Is anyone testing for a (cross-) target (board) with dynlinking?
On Tue, Feb 12, 2008 at 02:47:39AM +0100, Hans-Peter Nilsson wrote: > Is it as simple as nobody having tested cross-gcc setups for > targets with dynamic linking, or are they incorrectly using the > wrong (the installed, not the newly compiled) libgcc_s.so.1? > > Or how did you do it? NFS mounts on target and > "env LD_LIBRARY_PATH=... make check"? One way to do it is with NFS mounts and setting -Wl,-dynamic-linker -Wl,-rpath for your ldflags. You could skip -Wl,-dynamic-linker if you weren't testing a newly compiled libc. -Nathan
Re: Does Ada build on Linux/ia32?
On Feb 11, 2008 3:13 PM, Eric Botcazou <[EMAIL PROTECTED]> wrote: > > My patch will only change alignment for long long scalars and arrays. > > What alignments do Ada expect for long long on ia32? Does Ada expect > > 8 byte alignments for struct/record? > > AFAICS your patch will downgrade the alignment of DImode, not just long long. That is true and it still conforms to i386 psABI. > > It looks like the Ada compiler expects DImode to be aligned according to its > size, like other integral modes. I'd suggest to distill a reduced testcase > and debug side-by-side in decl.o (the error message is issued there) against > the pristine compiler, maybe it's only an oversight. > I don't know Ada to create a testcase. Can some Ada people help out? Thanks. H.J.
Re: Some 4.4 project musings
Diego Novillo wrote: On Fri, Feb 1, 2008 at 3:55 PM, Andrew MacLeod <[EMAIL PROTECTED]> wrote: 1 - Pass cleanup. There have been rumblings about this, but I haven't Yes, this is an area that is in desperate need of TLC. Your plan looks good to me. We need to have a mechanism to determine whether a pass did something, we need to be able to have different pipelines for different architectures. Do you have anything specific in mind? Create a branch? Work directly on mainline? I think I'll create a branch since its not completely clear if the chosen information will be sufficient.. First convert all the passes to pass some info back in an organized way and then there will be some collecting/experimenting to do. I'll do the trees first, but make sure it can be applied to RTL as well. 2 - Interface to the virtual operands. The virtual operand web provides what really amounts to low level detail of memory accesses. Every pass Richi's work will probably change what the web looks like, so this seems like a good item for me to defer for a bit until we see where we end up. 3 - SRA. There appear to be some deficiencies in SRA, and also how it interacts with the MEMSSA partitioner. I found when looking at some 4.3 Agreed. SRA needs a new implementation. Richi's work may completely remove need for touching SRA, so I'm going to punt on this for the time being as well. 4 - SSA pressure reduction. I'm throwing this back on the table. I never quite got around to it before, and nothing has changed to resolve the issues. We freely create as much register pressure in the SSA optimizers as we want (as we should be able to). The backend has doing nothing to address the issue and the RTL register allocator is simply swamped by the sheer quantity of live ranges sometimes. Perhaps Vlad's RA will get in this release, and/or perhaps the need for this will be eliminated by something else, but it is something that may help code generation in the short term at least. What about the RTL expansion from SSA directly? This is an area that is going to affect the tuples branch very soon. We are currently going into RTL from tuples directly (no TER), but since most passes have not been converted, I can yet tell how much of a problem this is. In a few weeks we'll hit this problem. Thats a lot more work, and by itself may actually increase pressure in the average case :-) It will be interesting to see if anything has changed in the past few years regarding RTL that gets generated without TER. It would be nice if it wasn't needed, but I'm not aware of work which has changed enough to help select better RTL patterns. we'll see :-) It will be interesting to see what happens. As an easy experiment, have you tried a straight comparison with -fno-tree-ter on SPEC or anything like that? It may give you some idea of what to expect. The pressure is likely to go up since TER usually moves defs closer to the use... I have no data whatsoever, but I would think that TER reduces the pressure slightly in the average case. The larger pathological cases are a little more unpredictable. Andrew
