On Sun, 3 Aug 2008, Sebastian Pop wrote: > Hi, > > I'm moving this thread to gcc@ mailing list for a wider audience.
This message didn't seem to go to the gcc list. > On Sun, Aug 3, 2008 at 2:07 PM, Mark Mitchell <[EMAIL PROTECTED]> wrote: > > I agree with Joseph's comments. Thanks, > > > > -- > > Mark Mitchell > > CodeSourcery > > [EMAIL PROTECTED] > > (650) 331-3385 x713 > > > > On Aug 3, 2008, at 11:23 AM, "Joseph S. Myers" <[EMAIL PROTECTED]> > > wrote: > > > >> On Sat, 2 Aug 2008, Sebastian Pop wrote: > >> > >>> Hi, > >>> > >>> The graphite branch has been tuplified and the port to PPL passes the > >>> graphite testsuite. For building the graphite branch right now, here > >>> are the steps you'll have to go through: > >>> > >>> You have to get a copy of the release 0.9 of PPL from: > >>> http://www.cs.unipr.it/ppl/Download/ > >> > >> I see this is documented as needing (a) C++, (b) GCC 4.0.3 or later, (c) > >> GMP compiled with the C++ interface enabled. I believe we previously > >> reached a conclusion that if GCC is made to require C++ it would work with > >> any version of GCC 3.4 or later (and did not discuss the question of the > >> GMP C++ interface). Recall that right now the documented requirement is > >> that a cross-compiler (so all non-Ada front ends) can be built with GCC > >> 2.95 or later; Ada requires 3.4 or later; and any ISO C compiler should > >> work for bootstrapping a native compiler. > >> > > Note that we ported Cloog to PPL because of the "GPLv2 only" license > of PolyLib, and thus there are two ways to configure Cloog, and one > does not require C++. > > PolyLib is written in C and its main author, Doran Wilde agreed to > contact PolyLib's authors for changing the license of PolyLib to > "GPLv3 or later". This license change is still not complete. Because > such changes usually take more time than solving a technical problem, > porting Cloog to PPL, we now have two polyhedral library back-ends in > Cloog. Clearly GCC's configure code should constrain the choice of back-end, its version, and how it is configured, precisely enough to determine uniquely the code generated by GCC. Exactly how far this means constraining things is a key piece of information that we need. (But the configure code also shouldn't allow configuring with a GPLv2 version of polylib.) > >> At this point I think the policy questions regarding the build > >> requirements for graphite, even as an optional feature, need to be raised > >> on their own in a thread on the gcc list rather than buried in the patch > >> discussion. > >> > >> I also think that the configuration machinery needs to be set up so that > >> if static versions of Cloog/PPL are being used then the compiler will also > >> be linked with static libgcc/libstdc++ (-static-libgcc > >> -Wl,-Bstatic,-lstdc++,-Bdynamic with the GNU linker, other options may be > >> needed for e.g. OS X), as stated in Ian's slides - even for an optional > >> feature using C++. > >> > >> C++ also increases the importance of testing the libraries on all primary > >> and secondary host OSes. > > We can set up some of the systems needed to test the graphite passes. > Do we have the list of primary and secondary host OSes documented > somewhere? http://gcc.gnu.org/gcc-4.4/criteria.html On that list, arm-eabi and mipsisa64-elf are bare-metal targets that do not make sense as hosts. So the testing needed is for the other platforms in those lists, including that the .s files generated (for whatever tests in the testsuite are built with graphite enabled, say) for some given target do not depend on the host. I'm not particularly concerned about different CPUs for the same OS (I don't think testing on five different GNU/Linux hosts gives more useful information than just testing on 32-bit and 64-bit GNU/Linux), rather about testing the different OSes in the list. Pick a target that can be tested on a simulator following simtest-howto.html (either arm-eabi or mipsisa64-elf will do, and both use 64-bit HOST_WIDE_INT so you won't run into pre-existing HOST_WIDE_INT-dependence code generation issues). Build for it on whatever hosts and make a script to run the graphite tests and save the .s files available, along with a baseline tarball of .s files for people to compare against. Native build and testing on those systems is a good idea as well as comparing the code generated for host-dependence. > Thanks, > Sebastian Pop and Jan Sjodin > -- > AMD - GNU Tools -- Joseph S. Myers [EMAIL PROTECTED]
