Question about polyhedral model and solver used in GRAPHITE
Dear all, I was reading one of the first technical reports of GRAPHITE and it looks like several libraries have been considered for integration into GCC for solving the ILP problem and polyhedral model representation. In the document the Omega library, PIP, PolyLib and PPL are mentioned. I am wondering about which library is actually used in the current implementation of the GRAPHITE framework and if possible I would like to know the motivations behind this choice. I actually need to build dependence analysis on top of a source-to-source compiler and I find myself in the 'nightmare' of choosing a suitable library for supporting the polyhedral model analysis and transformation. Thanks in advance for any help. best regards, Simone Pellegrini
Re: RFC: ARM Cortex-A8 and floating point performance
On Wednesday 16 June 2010 15:22:32 Ramana Radhakrishnan wrote: > On Wed, 2010-06-16 at 15:52 +, Siarhei Siamashka wrote: > > Currently gcc (at least version 4.5.0) does a very poor job generating > > single precision floating point code for ARM Cortex-A8. > > > > The source of this problem is the use of VFP instructions which are run > > on a slow nonpipelined VFP Lite unit in Cortex-A8. Even turning on > > RunFast mode (flush denormals to zero, disable exceptions) just provides > > a relatively minor performance gain. > > > > The right solution seems to be the use of NEON instructions for doing > > most of the single precision calculations. > > Only in situations that the user is aware about -ffast-math. I will > point out that single precision floating point operations on NEON are > not completely IEEE compliant. Sure. The way how gcc deals with IEEE compliance in the generated code should be preferably consistent and clearly defined. That's why I reported the following problem earlier: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43703 Generating fast floating code for Cortex-A8 with -ffast-math option can be a good starting point. And ideally it would be nice to be able to mix IEEE compliant and non-IEEE compliant parts of code. Supporting something like this would be handy: typedef __attribute__((ieee_noncompliant)) float fast_float; For example, Qt defines its own 'qreal' type, which currently defaults to 'float' for ARM and to 'double' for all the other architectures. Many applications are not that sensitive to strict IEEE compliance or even precision. But some of the applications and libraries do, so they need to be respected too. But in any case, ARM Cortex-A8 has some hardware to do reasonably fast single precision floating point calculations (with some compliance issues). It makes a lot of sense to be able to utilize this hardware efficiently from a high level language such as C/C++ without rewriting tons of existing code. AFAIK x86 had its own bunch of issues with the 80-bit extended precision, when just 32-bit or 64-bit precision is needed. By the way, I tried to experiment with solving/workarounding this floating point performance issue by making a C++ wrapper class, overloading operators and using neon intrinsics. It provided a nice speedup in some cases. But gcc still has troubles generating efficient code for neon intrinsics, and there were other issues like the size of this newly defined type, which make it not very practical overall. -- Best regards, Siarhei Siamashka
Re: Question about polyhedral model and solver used in GRAPHITE
On 06/17/2010 10:41 AM, Simone Pellegrini wrote: Dear all, I was reading one of the first technical reports of GRAPHITE and it looks like several libraries have been considered for integration into GCC for solving the ILP problem and polyhedral model representation. In the document the Omega library, PIP, PolyLib and PPL are mentioned. I am wondering about which library is actually used in the current implementation of the GRAPHITE framework and if possible I would like to know the motivations behind this choice. I actually need to build dependence analysis on top of a source-to-source compiler and I find myself in the 'nightmare' of choosing a suitable library for supporting the polyhedral model analysis and transformation. Hi Simone, currently we use PPL. At the time we wanted to commit Graphite it was the only realistic choice. The alternative was Polylib. However it was GPLv2 only and there was no chance to change the license. (I heard that it was changed recently). So there was not too much choice. Furthermore, technically polylib is a very old implementation that has a plain interface that is not that easy to understand. Polyhedron are e.g. represented as two dimensional matrices. Also its support for integer polyhedron is limited and sometimes wrong. On the other hand there is PPL. A nicely developed library, that since the most recent release also includes a PIP solver. It has a nice constraint based interface, good documentation and is GPLv3 licensed. Unfortunately integer polyhedron are not that easy to use in PPL. Recently there showed up a new library called ISL. It is developed by Sven Verdoolaege and is state of the art in terms of integer polyhedron. It is plain C and also supports a nice constraint based interface. Furthermore it has native support for existentially quantified variables. It already proved useful in CLooG [1] and is also used in Polly [2] because of its liberal LGPL license. You said you are planning to work on Source to Source compilation, and you are going to develop a dependency analysis. In this case I highly recommend you to check if this is not already available. There is candl from Cedric Bastoul that does dependency analysis and furthermore ISL has an integrated dependency solver. You just might want to use it directly. Furthermore I would be interested in the toolchain you are developing and if there is any possibility to integrate it with existing tools. We are working on an open Polyhedral interchange format called openscop/scoplib that will allow different polyhedral tools to interchange their data. So you could e.g. write the frontend/backend and could plug in tools supporting SCoPlib. Currently these tools exist that support SCoPlib: * Graphite: Frontend/Backend in GCC * Polly: Frontend/Backend in LLVM * Clan: C Source frontend * Candl: Dependency analysis * Pluto: Integrated toolchain for source to source compilation/ Please ask if you need further information or you want to introduce us to your project. Cheers Tobi [1] http://www.cloog.org [2] http://wiki.llvm.org/Polyhedral_optimization_framework
Re: RFC: ARM Cortex-A8 and floating point performance
On 16/06/2010 17:09, Andrew Pinski wrote:
On i?86 we have -mfpmath={sse,x87}, I suppose you could add
-mfpmath=neon for arm (properly conflicting with -mfloat-abi=hard
and requiring neon support).
Except unlike sse, neon does not fully support IEEE support. So this
should only be done with -ffast-math :). The point that it is slow is
not good enough to change it to be something that is wrong and fast.
How relevant is full IEEE support? I would imagine that only a tiny
minority of programs actually need it. But I would also imagine that
the great majority of programs are compiled without -ffast-math, even
though that would be perfectly good for them, and generate smaller and
faster code on almost all platforms.
So if -ffast-math were the default, would many people actually see wrong
code? Obviously such a change could not be done arbitrarily - as you
say, slow code is better than wrong code. It would have to be done
through stages for successive gcc releases of adding a "-fieee-math"
flag (synonymous with -fno-fast-math), and giving warning messages if
neither "-fieee-math" or "-ffast-math" were specified, before it could
be changed. And it would only apply to the -std=gnu... standards. But
the end result is that the majority of users would generate faster code.
Re: Floating Point Representation in libgcc (is IEEE?)
On Tue, Jun 15, 2010 at 2:13 PM, Joern Rennecke wrote:
>
> It is using whatever floating point format the target has.
> If you don't have hardware floating point support, then you get to
> choose the format when you design your ABI.
Yes, my target has no fp.
Thanks! This is not mine to decide if I just use a gcc floating point
library like fp-bit and soft-fp, right?
> There are two C implementations of IEEE software floating point in the
> GCC runtime:
> - fp-bit.c, which is fairly old and slow, but requires little work to use
> if longlong.h supports your processor (which is also needed for GNU mp).
> It only has round-to-nearest, no signals, but subnormals work except for
> one rounding issue with division.
> - soft-fp. This is supposed to be a bit faster, but you need to define
> various primitives. The default configuration is similar in features
> to fp-bit.c, but you can customize it for support of signals ('exceptions')
> and other rounding modes.
>
I started using fp-bit.c since I read somewhere (I wonder where I read
this) that soft-fp won't work if BITS_PER_UNIT != 8.
Is there any documentation explaining the implementation of floating
points in fp-bit.c and soft-fp.c? Mainly their internal
representation.
--
PMatos
Re: GCC porting questions
Hello again, I managed to get the thing working and I have two last issues to solve. 1. My machine does not have any kind of floating point instructions. When I write in the C source code float f = 0.5f; The compiler crashes with "Segmentation fault". Running a gdb on it, the output becomes Program received signal SIGSEGV, Segmentation fault. 0x775e343a in vfprintf () from /lib/libc.so.6 I do not have a multiply instruction either but when I write "int c = a * b;" the compiler properly inserts a LIBCALL to __mulsi3. Any idea what to do with the float? 2. When I try "char c = 'c';", the compiler fails an assert: test0.c:17: internal compiler error: in emit_move_multi_word, at expr.c:3273 This is strange since a char is smaller than an int, it should not be calling emit_move_MULTI_word. I have #define UNITS_PER_WORD 4 #define MIN_UNITS_PER_WORD 1 /* Promote those modes that are smaller than an int, to int mode. */ #define PROMOTE_MODE(MODE, UNSIGNEDP, TYPE) \ ((GET_MODE_CLASS (MODE) == MODE_INT \ && GET_MODE_SIZE (MODE) < UNITS_PER_WORD) \ ? (MODE) = SImode : 0) in my header file. Again, I do not know how to proceed. Thank you again for your time, R.
Re: GCC porting questions
"Radu Hobincu" writes: > The compiler crashes with "Segmentation fault". > 2. When I try "char c = 'c';", the compiler fails an assert: It's time to break out the debugger and look at the source code and figure out what the compiler is doing. Neither of these problems ring any sort of bell for me. Ian
gcc-4.5-20100617 is now available
Snapshot gcc-4.5-20100617 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20100617/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_5-branch revision 160949 You'll find: gcc-4.5-20100617.tar.bz2 Complete GCC (includes all of below) gcc-core-4.5-20100617.tar.bz2 C front end and core compiler gcc-ada-4.5-20100617.tar.bz2 Ada front end and runtime gcc-fortran-4.5-20100617.tar.bz2 Fortran front end and runtime gcc-g++-4.5-20100617.tar.bz2 C++ front end and runtime gcc-java-4.5-20100617.tar.bz2 Java front end and runtime gcc-objc-4.5-20100617.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.5-20100617.tar.bz2The GCC testsuite Diffs from 4.5-20100610 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.5 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.
strange use of function_invariant_p (Was: Re: Followup for reg_equiv_invariant patch: Fix PR39871)
Quoting Bernd Schmidt : On 06/15/2010 12:55 PM, Bernd Schmidt wrote: On 06/15/2010 08:00 AM, Joern Rennecke wrote: [constants like (plus (REG:SI SP_REG) (symbol_ref foo))] function_invariant_p will accept them. I guess we can change that and not lose anything. This is what I committed after retesting on ARM (with -O2 -fpic included in TORTURE_OPTIONS). You are not only rejecting invalid pic constants, you reject everything that's not CONST_INT. That could also include a (const (unspec ...)) for some integer the target has to calculate after register allocation / frame layout. I was wondering if we'd use function_invariant_p in a context where allowing CONST is important - e.g. could we have something like (const (plus (const_int anchor) (const_int offset))) from LEGITIMIZE_RELOAD_ADDRESS. I've stumbled over this piece of code in reload1.c:elimination_effects: 30134 crux else if (reg_renumber[regno] < 0 && reg_equiv_constant 30134 crux && reg_equiv_constant[regno] 47226rth && ! function_invariant_p (reg_equiv_constant[regno])) 30134 crux elimination_effects (reg_equiv_constant[regno], mem_mode); 30134 crux return; When will this condition ever trigger? If this is not dead code, then at least it is lacking a comment.
Re: data type 'struct loop' in MELT
On Sat, 2010-05-15 at 07:51 +0200, Basile Starynkevitch wrote:
> On 05/14/2010 10:27 PM, Michael Raitza wrote:
> >
> > Up to now I have basic support up and running. The hash map to the loop
> > is missing and I have not figured out yet what I need it for, but Basile
> > mentioned it to be necessary to reliably attach data to the loop data
> > type.
>
>
> Actually, this is not really MELT specific but also concerns any plugin.
(I was somehow waiting for your patch, but I suppose you don't made the
legal work to be autorized to commit to GCC).
So I just added preliminary support for GCC loop-s inside MELT, and
committed svn revision 160959.
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
