Re: Build requirements for the graphite loop optimization passes

["Joseph S. Myers" <joseph at codesourcery dot com>]

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 <mark@codesourcery.com> wrote:
> > I agree with Joseph's comments. Thanks,
> >
> > --
> > Mark Mitchell
> > CodeSourcery
> > mark@codesourcery.com
> > (650) 331-3385 x713
> >
> > On Aug 3, 2008, at 11:23 AM, "Joseph S. Myers" <joseph@codesourcery.com>
> > 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
joseph@codesourcery.com