Re: C++ bootstrap of GCC - still useful ?
> The immediate blocker to using C++ in gcc is the Ada frontend. > --enable-build-with-cxx and --enable-languages=ada do not work together. Could you elaborate? -- Eric Botcazou
Advice for changing OpenMP translation
Hello, I am trying to improve OpenMP task implementation. At first I thought I just have to modify ABIs (such as GOMP_task) internal but I realised I have to change the translation of OpenMP. My question is how to change the translation of OpenMP. (I guess I should edit gcc/omp-low.c:create_omp_child_function() but how?) I checked the current translation by $ gcc -O2 -fopenmp -fdump-tree-ompexp omp_fib.c and realised a problem that limits flexibility of internal implementation. I want "GOMP_taskexit" ABI which is called just before functions bound to tasks (*._omp_fn.[0-9]) ends. Here a task finishes its work. My task scheduling implementation needs GOMP_taskexit ABI. For example, when the last child task of a parent task finishes its work, it tells to the parent that all of children finished their work so the parent should resume its work. Tell me how to add "GOMP_taskexit" ABI. Sho Nakatani
Announce: GCC MELT plugin 0.8 rc3 for GCC 4.6
Hello All,
The release candidate 3 of the MELT plugin version 0.8 for GCC 4.6 is
available as a gzipped source tar archive, from
http://gcc-melt.org/melt-0.8rc3-plugin-for-gcc-4.6.tgz of size 3356872
bytes, of md5sum 7fb95a2469948ee9ffeb10cb523ab134 (july 10th 2011). It
is extracted from MELT branch svn revision 176124
###
NEWS for 0.8rc3 MELT plugin for gcc-4.6
July 10th, 2011: Release candidate 3 of MELT plugin 0.8 for GCC 4.6
as melt-0.8rc3-plugin-for-gcc-4.6
See http://gcc-melt.org/
New features (w.r.t. MELT plugin 0.7):
* support for pragmas for MELT
* the MELT garbage collector is called less often, using the
PLUGIN_GGC_START hook.
* several new c-iterators and c-matchers.
* added static analyzing pass gccframe, useful for melt-runtime.c
* reject nested defun-s, you should use letrec or let...
* the MELT plugin is built with its MELT-Plugin-Makefile
* debug_msg, assert_msg ... should work, thanks to MELT_HAVE_DEBUG
preprocessor flag, even when melt.so is a plugin for a GCC without
checks enabled.
* melt-runtime.h has a melt_gcc_version integer variable and
melt-runtime.c should be given MELT_GCC_VERSION preprocessor
constant.
* runfile mode compiles quickly (with debug_msg support). Add new mode
translatequickly to compile quickly (with debug_msg & assert_msg
support).
* the MELT building procedure builds various variants of MELT modules,
The 'optimized' variant is built with -O2 but don't support
(debug_msg ...) or (assert_msg ...). The 'quicklybuilt' variant is
built with -O0 and supports debug_msg & assert_msg. The
'debugnoline' variant is mostly useful with gdb, and also supports
debug_msg & assert_msg. These variants should be interoperable, you
could have a warmelt* module with 'optimized' variant and an
xtramelt* module in 'quicklybuilt' bariant.
* use the MELT_STAGE_ZERO=melt-stage0-static workaround
(bug not yet really fixed for plugins on x86 i686, ie 32 bits
machines; but this workaround is a temporary fix.)
Many bugfixes
(but some bugs remain)
###
I did not really fix the bug reported by Allan McRae on 32 bits x86 but I did
incorporate
a workaround. The plugin is building on 32 bits x86 Linux/Debian/Sid
Comments are welcome.
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 mine, sont seulement les miennes} ***
Re: Improve addsi3 for CONST_INT
2011/7/8 Georg-Johann Lay : > Denis Chertykov wrote: >> 2011/7/7 Georg-Johann Lay: >>> Hi Denis. >> >> I think that it's a good question to discuss inside gcc mailing list. >> May be somebody more qualified person give a better suggestion than me. > > ...bringing this over to gcc mailing list > >>> I think about improving addsi3 insn when a const_int is added. >>> The hard case is when the register to add the value is not in "d". >>> In the current implementation the constant simply gets reloaded into >>> some register (provided it is not an "easy" const like 1 or -1). >>> >>> That's a waste because >>> >>> * a 32-bit register gets initialized with the const, but a 8-bit >>> d-register would be sufficient. >>> >>> * Instead of setting an intermediate register, the value could be >>> added byte-by-byte if one d-reg was available. >>> >>> A bit unsure about how to approach that, I'd ask you what you think >>> about it. I can think of three approaches: >>> >>> 1) Use a peep2 on sequence like >>> *reload_insi >>> *addsi3 >>> resp. >>> *movsi >>> *addsi3 >>> >>> 2) Add new insn with (clobber (match_scratch:QI "=&d")) >>> >>> 3) Allow all const_int in *addsi3. If peep2 comes up with >>> a d-clobber, that's fine. Else have to cook up a clobber >>> by saving a d-reg to tmp_reg similar to movsi implementation. >>> >>> Approach (1) has the advantage that it is "neutral" with respect >>> to reloading. However, reload will always allocate a SI register, >>> even if peep2 comes up with a scratch. >> >> But, CSE will always have a chance to optimize it. > > You mean CSE or reload-CSE? As I remember reload himself can optimize such cases, also postreload CSE. > > If same constant is used multiple times, CSE can arrange for that and > combine can can compose a addsi+clobber. combine will only insert the > constant if it can reduce the number of insns, i.e. if two insns need > the same constant it won't do the replacement. > >>> Approach (2) has the advantage that it has just "pressure 1 on d-regs" >>> whilst (1) and the current implementation have "pressure 4 or even >>> r-regs". >> >> IMHO it's good idea to check. >> >>> I am in favor of approach (3): It's easier pattern like (1) and it >>> does not put pressure on regs at all. Also (3) makes no additional >>> work to support SF or if there were fixed-point mode. >> >> It's a fake. >> Generally, all fake methods is a wrong way. (Look at fake addressing) > > Yes, it's a fake. Bot note that movsi "r,i" alternative is also a > fake, and maybe you remember my failed approach to use secondary > reloads for that: > http://gcc.gnu.org/ml/gcc/2011-03/msg00290.html > > A word on fake addressing (PR46278): > > You were right with that. > At the time you wrote the AVR port, there was nothing like > MODE_CODE_BASE_REG_CLASS or REGNO_MODE_CODE_OK_FOR_BASE_P. > And even today it's not possible to specify different costs for > different addressing modes (ADDRESS_COST won't do it because it wors > on anatomy of an address and not on the address reg(s) invented). > If there was a way to tell the costs to IRA/reload and these passes > cared for the costs, fake addressing would be no problem! > > There are architectures where > LOAD R, [A] > resp. > LOAD R, [B] > do exactly the same but have different costs because A can be used > implicitly and thus yields shorter code. There's no way to tell it to > the allocator. All you can do is define reg-alloc-order and hope for > the best. > >> I think that I WAS WRONG while I decide to create __zero_reg__ and >> __tmp_reg__. (It was derived from my low qualify at start of EGCS >> hacking) > > I thought about that topic already more than once. > I have no idea how it could be done better. > > OPTIMIZE_MODE_SWITCHING looks rempting but it runs prior to reload, > and many uses of ZERO or TMP generated in reload or peep2. > We would need a pass with similar abilities running after peep2. > > To test in ISR if ZERO or TMP is needed, insn attributes could help. > But the stack layout would have to be changed ad-hoc, new BE-pass was > needed and it's error-prone IMHO. > > Introducing new ZERO_REG like R2 would change the ABI and ISR > pro/epilogue would increase even more because some insns > change/restore ZERO. > > >>> Or do you think the improvement is not needed? >> >> I vote for 2, but I can be wrong. >> You know the best way ;-) Try all methods and compare results. >> (profile optimizing yourself ;-) >> >>> Thanks for your recommendation. >> >> I want to give you a recomendation: please, cleanup the port from >> using immediate numbers as register numbers. (in your patches you >> frequently use it) > > I intend to do more backend cleanup, the elfos patch just was the first. > >> Please, use constants ! >> I forgot to point to them in your last patches. >> e.i. >> >> /* We have no clobber reg but need one. Cook one up. >> That's cheaper than loading from constant pool. */ >> >>
MELT plugin 0.8rc for 4.6 on 32 bits x86
On Sat, 09 Jul 2011 10:08:06 +1000
Allan McRae wrote:
> On 09/07/11 01:43, Basile Starynkevitch wrote:
> > On Fri, 08 Jul 2011 19:50:11 +1000
> > Allan McRae wrote:
> >
> >> On 08/07/11 19:15, Basile Starynkevitch wrote:
> >>> On Fri, Jul 08, 2011 at 06:41:30PM +1000, Allan McRae wrote:
> empty-file-for-melt.c
> cc1: note: MELT is bootstrapping so ignore builtin source directory
> /usr/lib/gcc/i686-pc-linux-gnu/4.6.1/plugin/melt-source and module
> directory
> /usr/lib/gcc/i686-pc-linux-gnu/4.6.1/plugin/libexec/melt-modules
> *** WARNING *** there are active plugins, do not report this as a
> bug unless you can reproduce it without enabling any plugins.
> Event| Plugins
> PLUGIN_FINISH_UNIT | melt
> PLUGIN_FINISH| melt
> PLUGIN_GGC_START | melt
> PLUGIN_GGC_MARKING | melt
> PLUGIN_ATTRIBUTES| melt
> PLUGIN_START_UNIT| melt
> PLUGIN_PRAGMAS | melt
> cc1: internal compiler error: Segmentation fault
> Please submit a full bug report,
> >>>
> >>>
> >>> Did you install a previous release of MELT plugin (e.g. 0.8rc1 or 0.7)? If
> >>> you did, you have to remove it entirely (eg remove all files named
> >>> *melt*)?
> >>>
> >>
> >
> >
> > Alexandre Lissy discovered that by replacing, in file
> > melt-0.8rc2-plugin-for-gcc-4.6/melt-build.mk line 420,
> > MELT_STAGE_ZERO?= melt-stage0-dynamic
> > with
> > MELT_STAGE_ZERO = melt-stage0-static
> > the bug disappears.
> >
> > Allan, could you confirm that it is the case for you also? Thanks!
> >
>
> I can confirm the build completes with that change.
For your information, I corrected that bug (not only made the
workaround) on MELT svn rev. 176125.
So I think that the MELT plugin 0.8 final
(which I will probably release in a couple of days) will have that bug
corrected.
Before releasing the definitive MELT 0.8 plugin for 4.6, I want to be
sure that the new building machinery (based upon MELT-Plugin-Makefile,
i.e. using make) is working for someone else than me.
As soon as someone give me reports (either positive or negative) about
the build of MELT plugin 0.8 rc3 which I have announced an hour ago
http://gcc.gnu.org/ml/gcc/2011-07/msg00126.html &
http://groups.google.com/group/gcc-melt/browse_thread/thread/8901c8fcf47c8f32
I will be able to release the final 0.8 (but I am not working at all
tomorrow).
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 mine, sont seulement les miennes} ***
MELT plugin 0.8rc4 for 4.6
On Sun, 10 Jul 2011 19:00:14 +0200
Basile Starynkevitch wrote:
>
> For your information, I corrected that bug (not only made the
> workaround) on MELT svn rev. 176125.
>
> So I think that the MELT plugin 0.8 final
> (which I will probably release in a couple of days) will have that bug
> corrected.
I just released MELT plugin 0.8rc4 with that change. See http://gcc-melt.org/
and download
http://gcc-melt.org/melt-0.8rc4-plugin-for-gcc-4.6.tgz
When I have a successful build report, I will release it as MELT 0.8 plugin.
Same news (w.r.t to MELT 0.7) as in
http://gcc.gnu.org/ml/gcc/2011-07/msg00126.html
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 mine, sont seulement les miennes} ***
Re: C++ bootstrap of GCC - still useful ?
On 07/10/2011 06:45 AM, Ian Lance Taylor wrote: Toon Moene writes: As of a couple of months, I perform a bootstrap-with-C++ (--enable-build-with-cxx) daily on my machine between 18:10 and 20:10 UTC. I see that the build by a C++ compiler has been the subject of the GCC Gathering at Google: C++ style and migration crowlwriting and using C++ in gcc It is not quite clear what the outcome of this discussion was. Is there still interest in daily builds like mine ? Yes, it's definitely useful. The immediate blocker to using C++ in gcc is the Ada frontend. --enable-build-with-cxx and --enable-languages=ada do not work together. Ah, OK. Just drop me a note when a regular test including Ada starts to be useful (I probably have to skip some other front end language in favor Ada to stay within the two hour elapsed time window between two weather forecasting runs). BTW, the ultimate reason I asked was that it turned out that running an ordinary quad core PC to the max doesn't come for free. Last month I got past year's electricity bill - it turns out that I am now (16 hours of weather forecasting and 4 hours of GCC bootstrapping per day) using 3200 KWh a year - to the tune of 1100 Euros. So the question whether a run is useful is certainly relevant :-) -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
Re: C++ bootstrap of GCC - still useful ?
On Sun, Jul 10, 2011 at 1:03 PM, Toon Moene wrote: > BTW, the ultimate reason I asked was that it turned out that running an > ordinary quad core PC to the max doesn't come for free. > > Last month I got past year's electricity bill - it turns out that I am now > (16 hours of weather forecasting and 4 hours of GCC bootstrapping per day) > using 3200 KWh a year - to the tune of 1100 Euros. Ouch! :-/ > So the question whether a run is useful is certainly relevant :-) Indeed :-)
Re: Advice for changing OpenMP translation
On Sun, Jul 10, 2011 at 09:36:15PM +0900, Sho Nakatani wrote: > I am trying to improve OpenMP task implementation. > At first I thought I just have to modify ABIs (such as GOMP_task) internal > but I realised I have to change the translation of OpenMP. > > My question is how to change the translation of OpenMP. > (I guess I should edit gcc/omp-low.c:create_omp_child_function() but how?) > > I checked the current translation by > $ gcc -O2 -fopenmp -fdump-tree-ompexp omp_fib.c > and realised a problem that limits flexibility of internal implementation. > > I want "GOMP_taskexit" ABI which is called just before functions > bound to tasks (*._omp_fn.[0-9]) ends. > Here a task finishes its work. > My task scheduling implementation needs GOMP_taskexit ABI. Why? If your "GOMP_taskexit" is the last thing the *._omp_fn.[0-9] task body will do, what is the difference between that and just the point when the task body function returns? If you want to do something after GOMP_taskexit, you should explain what and why. Jakub
Re: C++ bootstrap of GCC - still useful ?
On Sun, 2011-07-10 at 20:03 +0200, Toon Moene wrote: > On 07/10/2011 06:45 AM, Ian Lance Taylor wrote: > > > Toon Moene writes: > > >> As of a couple of months, I perform a bootstrap-with-C++ > >> (--enable-build-with-cxx) daily on my machine between 18:10 and 20:10 > >> UTC. > >> > >> I see that the build by a C++ compiler has been the subject of the GCC > >> Gathering at Google: > >> > >> C++ style and migration crowlwriting and using C++ in gcc > >> > >> It is not quite clear what the outcome of this discussion was. > >> > >> Is there still interest in daily builds like mine ? > > > > Yes, it's definitely useful. > > > > The immediate blocker to using C++ in gcc is the Ada frontend. > > --enable-build-with-cxx and --enable-languages=ada do not work together. > > Ah, OK. > > Just drop me a note when a regular test including Ada starts to be > useful (I probably have to skip some other front end language in favor > Ada to stay within the two hour elapsed time window between two weather > forecasting runs). > > BTW, the ultimate reason I asked was that it turned out that running an > ordinary quad core PC to the max doesn't come for free. > > Last month I got past year's electricity bill - it turns out that I am > now (16 hours of weather forecasting and 4 hours of GCC bootstrapping > per day) using 3200 KWh a year - to the tune of 1100 Euros. > > So the question whether a run is useful is certainly relevant :-) Hi, Since I pay the electricty bill of some compile farm machines I understand you here :). New generation of hardware has made significant progress on energy efficiency: my latest built PC is a Intel core i7 2600 4 cores 8 threads 3.4 GHz 4x4 GB of RAM with 40 GB SSD + 2TB HDD, 80+ gold PSU and it idles around 30W and uses 110W full CPU load. PC cost is around 800 EUR in France (19.6% VAT included). According to your data it should reduce your bill by a factor of three (365W => 110W), so it should pay itself in around a year: 720 EUR less on your yearly electricity bill, assuming you counted only your PC power consumption in your figures. And bonus nearly no noise in a case with 2 or 3 120mm fans. I haven't had a chance to test AMD A8 processors but I will do soon. Sincerely, Laurent
Re: MELT plugin 0.8rc4 for 4.6
On 11/07/11 03:15, Basile Starynkevitch wrote: On Sun, 10 Jul 2011 19:00:14 +0200 Basile Starynkevitch wrote: For your information, I corrected that bug (not only made the workaround) on MELT svn rev. 176125. So I think that the MELT plugin 0.8 final (which I will probably release in a couple of days) will have that bug corrected. I just released MELT plugin 0.8rc4 with that change. See http://gcc-melt.org/ and download http://gcc-melt.org/melt-0.8rc4-plugin-for-gcc-4.6.tgz When I have a successful build report, I will release it as MELT 0.8 plugin. Same news (w.r.t to MELT 0.7) as in http://gcc.gnu.org/ml/gcc/2011-07/msg00126.html I can give a successful build report for melt-0.8rc4 on i686-pc-linux-gnu using "make all". Some issues I noticed with "make install" > make DESTDIR=/tmp/melt install ... install: target `/tmp/melt//usr/lib/gcc/i686-pc-linux-gnu/4.6.1/plugin/include/' is not a directory: No such file or directory This needs added to install-melt-includes: $(mkinstalldirs) $(DESTDIR)/$(MELTGCC_PLUGIN_DIR)/include/ Then I run into an error in install-melt-modules: install: cannot stat `melt-modules/*.so': No such file or directory In that directory I have three subdirectories containing built modules. I guess one of them is supposed to be used. All other install targets work fine. Allan
Re: GSOC - Student Roundup
On 06.07.2011 11:39, Pierre Vittet wrote: Hi, I am Pierre Vittet, one of the GSOC students. I am writing a plugin which is a simple statical analysis tools. The idea is to write some tests (like testing that a function call is tested to return somethings (not) null, or testing that a call to a given function is followed by a call to another function.), that can be parametrized by the user (to be run on the functions he wants to check). I feel it can be a useful tool (however I am ready to fight with false positives). I am using MELT (http://gcc-melt.org/) for this, I know that is quite a hot topic in the community and it is not much considered. MELT aims at abstracting GCC internal with a higher level language. I think that it can be a good way to enter into GCC, because it permits to parse quite quikly the GCC internal, gimple especially. The major feature of MELT is his pattern matching on tree ability. Part of my work is to improve MELT (as I need some features which were not implemented), such as having handling pragma in MELT plugins or gluing some GCC dominance functions (from gcc/dominance.c) However, like the others students which answered to this thread, the main difficulty is understanding and eventually modifying GCC itself. That is quite time consumming, as you can have, even to write a simple patch, to know well several parts of GCC (I am often grepping for a given struct or function). I also thing that each pass could be more detailled. Sometimes, it is hard to find a pass in the code from it's dump file name. I had to write a patch for the trunk, to add a data field to pragma handlers, this was quite a simple patch, however, I had to make it compatible with the fact that one of the function I was modifying was used many times in differents parts of GCC. Currently, I need to understand how works C++ mangling if I want my plugin to work with C++ (I am going to write a new mail about this), as I need to convert the string given by the user into the function(s) that it represents. About the state of my plugin, I have written the core of the module. It can use user's input from different entries (I have already written an entrie using the pragma, and an entrie using direct argument (given when invoking GCC), searchs if it matchs a corresponding test and generate a new GCC Pass from this. This new pass is inserted after ssa pass, as I got a representation which suits to me (I can find the information my tests need). But the choice of inserting here is quite empirical (would have you choice another pass?). The plugin is mainly tested for C code, even if I would like to have C++ working too. I have started implementing tests, for the moment I use a test which checks that there is a test checking for a NULL pointer (if resCall == NULL for exemple) after a given function call, and return a warning if there is no test. I have also started implementing a test checking that a given is immediatly followed by another given function. I would also try to add a test checking that a call to a given function is followed by a call to another function in the same function bodies, I know that I will have to handle the basic block hierarchie, that why I glued dominance functions into MELT. I think, I am in time, however, this is sometimes hard to evaluate: for exemple, I don't know really how much time, I will take to manage C++ function in my plugin. I feel sad, not being able to use IRC from my web access (in my school)... and so only communicating by mail with the GCC community. However, I thanks the community for their answer and support. The point to improve, I guess, is having more people reviewing patchs (even if, I understand that it requires a lot of time and skills). Thanks Pierre Vittet On 05/07/2011 21:08, Daniel Carrera wrote: Hello Philip + Dimitrios Thanks for your posts. I am another GSOC student. I am working on the Fortran front-end of GCC (gfortran). Like most GFortran developers, my background is more in the natural sciences (astrophysics in my case) rather than computer science. My project is to help add coarray support for GFortran. Coarrays are a cool new feature in the Fortran 2008 standard that give Fortran native support for parallel programming (as opposed to using MPI or OpenMP). Scientific simulations (especially in parallel clusters) are the bread and butter of Fortran. Learning how GCC works has been difficult but rewarding. My work is split between the libgfortran library, which is straight forward enough, and the Fortran front-end, which at first looked like gobbledygook. Today I can actually understand most front-end functions when I read them, but it took a long time to get to this point. GCC has a scary learning curve. The libgfortran library is more forgiving for the beginner. We are using MPI as the backend to implement coarrays and I have very much enjoyed learning MPI. So far my contributions hav
