How to do executable individualization using optimization options ?
If the optimization options provided in a different way, the same source codes would be compiled into different executables. In the different executables, the register allocation or instruction orders might be easily changed, but I think that's not that big change. What I'd like to do is to make their CFG different, while their impact on executing performance is reasonable. I'm reading through the compiler books and gcc internal documentations, but it's really hard for me to pin point what I really need to read and understand. So, my question is what kind of optimizing options in gcc could be used to do such jobs ? or would you recommend good references for this ? Regards, Byoungyoung Lee
Re: new plugin events
Richard Guenther wrote: On Fri, Nov 6, 2009 at 10:41 PM, Basile STARYNKEVITCH wrote: Richard Guenther wrote: (stop reading now, what follows is pure cynicism - I have to do it, because the following can't be let un-responded, rather than un-answered) Actually, I tend to believe that the plugin infrastructure should ideally permit to replace almost every single file in GCC by an equivalent file in the plugin. Take for example the pass manager (file gcc/passes.c) I understood that ICI have their own pass manager (By the way, I Basile don't care about the pass manager). So ICI guys would probably be happy to bypass all the functions in the gcc-4.5/gcc/passes.c and provide their own variant of these. My intuition is that this should be doable. I meant that some developers (not me) might dream of replace one single file X.c with their XX.c. For ICI, I understood that X.c is gcc/passes.c (and I don't know what is their XX.c replacing it) I don't understand the cynicism adjective (which I feel too aggressive). In other words, I believe that the plugin functionality should permit experimentation on most features of GCC. Of course I do not mean all of them at once, I just mean making an experiment where one single feature or functionality X [to simplify, an important GCC function or source file) of GCC is replaced by something provided by the plugin. It should be possible already if you build GCC with -fPIC. You then can LD_PRELOAD a plugin replacing all functions you want to replace. Thanks to the wonders of ELF. I probably am happy enough with the current set of hooks. I might wish in a year some hooks for CPP, but I understood Diego need them, so I believe they will appear. But I am not sure that every GCC experiment is pluginable today (I really don't know). Take for instance all the papers in the recent GCC summits (let's say after 2007). All of them describe code related to GCC. I am not sure that every such code could fit as a plugin. I believe it should. Ah, you mean like doing the tuples conversion as plugin? Or to build the cgraph infrastructure and IPA optimization infrastructure as plugin? I guess what you say is - "stop developing gcc! develop plugins!"? To be more precise, I believe that some few plugins (not the ones I Basile will write) might perhaps replace the branch role as experimental ground for GCC. And I don't see any issue here, on the contrary. Plugins are for their users perhaps easier to try than a whole GCC branch. What's the difference between writing a plugin and writing a branch nobody will use? So perhaps people would start plugins instead of starting their branch. Why should that be bad? I feel it is very positive! Perhaps all of GCC code is bypassable by a plugin which would handle PLUGIN_START_UNIT, copy or call all of the existing code of GCC inside it, and exit without returning... So probably, plugin could do anything. What's the point? We have plugins for the kernel for this - it's called programs, the plugin architecture is processes. No plugins for the kernel are called modules. The command to list the set of loaded kernel modules is lsmod (not ps). The debian kernel I am using now have 93 modules loaded. But I believe we should provide a lot more hooks for them. Then add a GCC option you build GCC with, -finstrument-functions. Wait - that already exists! Or do you maybe mean a more structured way to expose GCC internals? Plugins are important for a very social, non-technical reason: nobody today is compiling GCC -except the GCC community & the linux distribution makers. The art of compiling monster software like GCC is almost lost. People don't compile free software anymore. (this has changed since the 1980s. At the time of SunOS3.5, people did compile gcc & emacs). And I recently discovered that compiling GCC is too difficult a task for most GCC users (at least outside academia). GCC plugin will help experimental extensions towards this population of GCC users (not able or not wanting to compile GCC). Another important motivation for plugins is the licence (more exactly the legal requirement of FSF ownership). Coding GPLv3 code is accepted by many managers & organizations (because the GPLv3 is a mainstream licence), but transfering copyright to FSF is painful to most big organizations - because it is an unusual procedure -. I insist that the copyright to FSF transfer is a big brake to enter GCC development. And this brake is not effective inside plugins. Plugins can be simply GPLv3, but not FSF copyrighted. I am sure it makes an important difference for putative developpers (more precisely for their bosses). Bullshit. Replacing "monster software like GCC" with "moster plugins like melt" isn't going to help. It will just fragment the developer communities. You might tell everything about MELT, but not that is is monstrous. It is a small one-man work. To get the figures right, MELT code (the one written
Re: new plugin events
On Sat, Nov 7, 2009 at 11:49 AM, Basile STARYNKEVITCH wrote: > Richard Guenther wrote: >> Ah, you mean like doing the tuples conversion as plugin? Or to >> build the cgraph infrastructure and IPA optimization infrastructure >> as plugin? I guess what you say is - "stop developing gcc! develop >> plugins!"? > > To be more precise, I believe that some few plugins (not the ones I Basile > will write) might perhaps replace the branch role as experimental ground > for GCC. And I don't see any issue here, on the contrary. Plugins are for > their users perhaps easier to try than a whole GCC branch. What's the > difference between writing a plugin and writing a branch nobody will use? So > perhaps people would start plugins instead of starting their branch. Why > should that be bad? I feel it is very positive! Because it encourages forking, especially because of... > I insist that the copyright to FSF transfer is a big brake to enter GCC > development. And this brake is not effective inside plugins. Plugins can be > simply GPLv3, but not FSF copyrighted. I am sure it makes an important > difference for putative developpers (more precisely for their bosses). ...this. If you don't like to transfer copyright to the FSF, fine. But don't expect the FSF GCC program (i.e. us) to assist you in subverting itself. Plugins should add special functionality that is needed for some niche application of GCC, but not replace internals of GCC itself. Ciao! Steven
Re: new plugin events
Steven Bosscher wrote: On Sat, Nov 7, 2009 at 11:49 AM, Basile STARYNKEVITCH wrote: Richard Guenther wrote: Ah, you mean like doing the tuples conversion as plugin? Or to build the cgraph infrastructure and IPA optimization infrastructure as plugin? I guess what you say is - "stop developing gcc! develop plugins!"? To be more precise, I believe that some few plugins (not the ones I Basile will write) might perhaps replace the branch role as experimental ground for GCC. And I don't see any issue here, on the contrary. Plugins are for their users perhaps easier to try than a whole GCC branch. What's the difference between writing a plugin and writing a branch nobody will use? So perhaps people would start plugins instead of starting their branch. Why should that be bad? I feel it is very positive! Because it encourages forking, especially because of... Not really. (Historically, GCC had few forks, EGCS mostly. And forks are possible because of the GPL. The FSF copyright don't disallow them. Look at Xemacs vs Emacs, or SXemacs vs Xemacs. GPL-ed forks of GCC are inpractical, because GCC is too big.. They are not prohibited by legal means. Of course I am not a laywer and may be wrong.) My view is more pragmatical. Getting the FSF copyright is really a hard effort (nothing to do with coding; a lot to do with lawyers and other people with which communication is difficult for a hacker.). So it is a *huge* barrier to enter the GCC community. It is so big a barrier that I know several persons who gave up. So I am convinced it is a barrier which restrict the arrival of new GCC hackers. I believe that if some Joe Hacker did develop a GPlv3 GCC plugin, then if the plugin has some success -this is two big ifs so is not probable but it could happen- he would later want to push that plugin into GCC core [or at least parts of it] and to transfer copyright to FSF. But getting that it that order -Joe Hacker do have a concrete, running, useful, GPLv3 plugin already [this is more than a year of interesting work], and Joe Hacker want to push it into GCC, and so Joe Hacker need to transfer copyright to FSF [this is 3 months of boring work] - is in my guess less hard than getting a paper signed before coding the very first line of code. It is simpler for a lawyer to understand that some particular existing GPLv3 piece code should be transfered to FSF that to sign a contract on unidentified future source code. I insist that the copyright to FSF transfer is a big brake to enter GCC development. And this brake is not effective inside plugins. Plugins can be simply GPLv3, but not FSF copyrighted. I am sure it makes an important difference for putative developpers (more precisely for their bosses). ...this. If you don't like to transfer copyright to the FSF, fine. But don't expect the FSF GCC program (i.e. us) to assist you in subverting itself. Plugins should add special functionality that is needed for some niche application of GCC, but not replace internals of GCC itself. I entirely agree, and all the MILEPOST & ICI effort are a niche application (and also MELT). Besides, both MILEPOST & MELT are FSF owned branches of GCC. [Nobody cares]. I can phrase my views in another way. I don't know much about ICI, but the few things I understood about ICI make me believe (half blinded believe, I don't understand the details) that ICI could be useful for GCC. There is a copyright transfer between INRIA (I mean the people behind ICI) and FSF. So no legal issues here. Assuming that some parts of ICI could be useful to GCC, how can we help them in that process? If they try to send a big patch, I am certain nobody will review it. So ICI people could send big patches -they already did that- and nobody is listening. My suggestion to ICI friends is : just propose quickly your needed plugin events, and make your ICI a GPLv3 plugin. When you can show that your ICI plugin to an *unmodified* gcc-4.5 brings some value, GCC people will perhaps start to listen and look inside. The points are: * nobody cares about experimental GCC branches (FSF copyrighted), and nobody looks inside, unless the branch happens to be created by some major GCC guru guy like Diego Novillo or Richard Guenther or Steven Bossher or Joseph Myers (or a dozen of important GCC guys). But branches created by some random hacker like me Basile or ICI people are virtually non-existent. Nobody cares about them, nobody retrieves them, nobody builds them, nobody looks inside them. I am entirely sure that if I put a naughty joke in some comment of my MELT branch, nobody would notice. But I won't do that anyway... Also, even if there is some brillant idea in some experimental GCC branch, nobody will be aware of it. So in my view most branches are only random bytes on disks. Likewise, nobody care about a thousand line patch sent by ICI. * plugins are hopefully much easier to build than branches (because they are much smaller). S
RE: new plugin events
Hi Basile et al, > My suggestion to ICI friends is : just propose quickly your needed plugin > events, and make > your ICI a GPLv3 plugin. > When you can show that your ICI plugin to an *unmodified* gcc-4.5 brings some > value, GCC > people will perhaps start to > listen and look inside. Just to mention that I am a bit confused because I actually don't expect to have problems moving ICI to the mainline unless we find some big bugs that can change GCC behavior (but I really don't think so). We had many online and offline discussions to move ICI to the mainline GCC in the last few years with GCC colleagues/maintainers. We just sadly got delayed at INRIA this summer due to different reasons but Joern is now working with us for 2 months fully time to clean and test ICI and submit patches as soon as they are ready. It's true that we actually need a few hooks and Joern will communicate about that shortly BUT these hooks are already used in real plugins for real performance tuning (in a way as current hooks are used in Dehydra for real program analysis in several companies). Our performance results are gradually added to the online performance database at http://cTuning.org/cdatabase for EEMBC, SPEC and other programs across multiple architectures which real users and companies are using to optimize their real code... A few days ago I got a feedback from Loongson group that they considerably speeded up EEMBC on their latest processor using GCC 4.4.x and they should upload the results to the database shortly ... They have been actively working with us using and extending ICI ... That's why only after we showed real results, we would now like to have MINIMAL ICI in mainline GCC but patches for other extensions including GSOC'09 projects will be submitted to GCC only after testing ... We will keep in touch about that, Grigori
How to do executable individualization using optimization options ?
If the optimization options provided in a different way, the same source codes would be compiled into different executables. In the different executables, the register allocation or instruction orders might be easily changed, but I think that's not that big change. What I'd like to do is to make their CFG different, while their impact on executing performance is reasonable. I'm reading through the compiler books and gcc internal documentations, but it's really hard for me to pin point what I really need to read and understand. So, my question is what kind of optimizing options in gcc could be used to do such jobs ? or would you recommend good references for this ? Regards Byoungyoung Lee
Re: new plugin events
On Sat, Nov 7, 2009 at 1:24 PM, Grigori Fursin wrote: > Hi Basile et al, > >> My suggestion to ICI friends is : just propose quickly your needed plugin >> events, and make >> your ICI a GPLv3 plugin. >> When you can show that your ICI plugin to an *unmodified* gcc-4.5 brings >> some value, GCC >> people will perhaps start to >> listen and look inside. > > Just to mention that I am a bit confused because I actually don't expect to > have problems moving > ICI to the mainline unless we find some big bugs that can change GCC behavior > (but I really don't > think so). > We had many online and offline discussions to move ICI to the mainline GCC in > the last few years > with GCC > colleagues/maintainers. We just sadly got delayed at INRIA this summer due to > different reasons but > Joern > is now working with us for 2 months fully time to clean and test ICI and > submit patches as soon as > they are ready. > > It's true that we actually need a few hooks and Joern will communicate about > that shortly BUT these > hooks are > already used in real plugins for real performance tuning (in a way as current > hooks are used in > Dehydra > for real program analysis in several companies). And I don't expect problems in adding hooks that ICI needs. I expect that ICI is a reason to improve GCCs pass manager - and I expect that we will improve GCCs pass manager not by simply adding hooks to it to "fix" it from inside plugins, but I expect that we'll get a more powerful pass manager _inside_ GCC. I also expect or at least hope that more parts of the compilation process get driven by the pass manager rather than by ad-hoc code gluing several phases of pass manager driven stages. Richard.
RE: new plugin events
That's very reasonable and it's our eventual goal too so we will start discussions about that in detail whenever ICI is clean. By the way, just to mention that I am working with a student (Yuri) to provide/understand/describe/characterize performance dependencies and interaction between passes using ICI to be able to make selection and ordering of passes more systematic and avoid having the same multiple passes in the compilation sequence just because they may potentially improve the code. We use ICI with GSOC'09 extensions and is it so far very simple to manipulate passes through plugins (we use XML outside to save all IP passes and passes per function). This is a long term project, but as soon as we have some promising results, we will tell you ;) ... Cheers, Grigori > -Original Message- > From: Richard Guenther [mailto:richard.guent...@gmail.com] > Sent: Saturday, November 07, 2009 3:06 PM > To: Grigori Fursin > Cc: Basile STARYNKEVITCH; Steven Bosscher; Diego Novillo; Rafael Espindola; > gcc; Joern > Rennecke; Zbigniew Chamski > Subject: Re: new plugin events > > On Sat, Nov 7, 2009 at 1:24 PM, Grigori Fursin > wrote: > > Hi Basile et al, > > > >> My suggestion to ICI friends is : just propose quickly your needed plugin > >> events, and make > >> your ICI a GPLv3 plugin. > >> When you can show that your ICI plugin to an *unmodified* gcc-4.5 brings > >> some value, GCC > >> people will perhaps start to > >> listen and look inside. > > > > Just to mention that I am a bit confused because I actually don't expect to > > have problems > moving > > ICI to the mainline unless we find some big bugs that can change GCC > > behavior (but I really > don't > > think so). > > We had many online and offline discussions to move ICI to the mainline GCC > > in the last few > years > > with GCC > > colleagues/maintainers. We just sadly got delayed at INRIA this summer due > > to different > reasons but > > Joern > > is now working with us for 2 months fully time to clean and test ICI and > > submit patches as > soon as > > they are ready. > > > > It's true that we actually need a few hooks and Joern will communicate > > about that shortly > BUT these > > hooks are > > already used in real plugins for real performance tuning (in a way as > > current hooks are used > in > > Dehydra > > for real program analysis in several companies). > > And I don't expect problems in adding hooks that ICI needs. I expect > that ICI is a reason to improve GCCs pass manager - and I expect that > we will improve GCCs pass manager not by simply adding hooks to it > to "fix" it from inside plugins, but I expect that we'll get a more powerful > pass manager _inside_ GCC. I also expect or at least hope that more > parts of the compilation process get driven by the pass manager rather > than by ad-hoc code gluing several phases of pass manager driven > stages. > > Richard.
Re: new plugin events
Richard Guenther wrote:
On Sat, Nov 7, 2009 at 1:24 PM, Grigori Fursin wrote:
Hi Basile et al,
My suggestion to ICI friends is : just propose quickly your needed plugin
events, and make
your ICI a GPLv3 plugin.
When you can show that your ICI plugin to an *unmodified* gcc-4.5 brings some
value, GCC
people will perhaps start to
listen and look inside.
Just to mention that I am a bit confused because I actually don't expect to
have problems moving
ICI to the mainline unless we find some big bugs that can change GCC behavior
(but I really don't
think so).
We had many online and offline discussions to move ICI to the mainline GCC in
the last few years
with GCC
colleagues/maintainers. We just sadly got delayed at INRIA this summer due to
different reasons but
Joern
is now working with us for 2 months fully time to clean and test ICI and submit
patches as soon as
they are ready.
It's true that we actually need a few hooks and Joern will communicate about
that shortly BUT these
hooks are
already used in real plugins for real performance tuning (in a way as current
hooks are used in
Dehydra
for real program analysis in several companies).
And I don't expect problems in adding hooks that ICI needs. I expect
that ICI is a reason to improve GCCs pass manager - and I expect that
we will improve GCCs pass manager not by simply adding hooks to it
to "fix" it from inside plugins, but I expect that we'll get a more powerful
pass manager _inside_ GCC. I also expect or at least hope that more
parts of the compilation process get driven by the pass manager rather
than by ad-hoc code gluing several phases of pass manager driven
stages.
We probably all agree on goals, but perhaps less on timeline.
My feeling (but I admit I don't understand well what stage 3 means precisely for gcc 4.5.0, in particular w.r.t. plugins
& pass management, and why exactly stage 2 was skipped in 4.5) was up to now:
1. Only very small patches can go into 4.5. So ICI pass manager won't go into 4.5.0, and any improved pass manager won't
go into 4.5.0, only in 4.6.0. This probably means in last quarter of 2010 or first quarter of 2011, since 4.4.0 was
released in april 2009, and 4.3.0 was released in march 2008 and 4.2.0 was released in may 2007 and 4.1.0 at end of
february 2006. I am guessing 4.5.0 would be released for christmas 2009 at the earliest, so 4.6.0 would go out at end of
2010 in the best case.
2. I was hoping that the few PLUGIN_* hooks absolutely needed by ICI could go into 4.5. My intuition is that it really
means small unobtrusive patches which might be accepted before Christmas 2009.
In other words, are there hope to delay 4.5.0 release for a month to get the ICI-improved pass manager inside it? In
case the answer is yes, will we keep the same interface, so that the interface for PLUGIN_PASS_MANAGER_SETUP won't
change with the improved pass manager?
register_callback (plugin_info->base_name, PLUGIN_PASS_MANAGER_SETUP, NULL,
&pass_info);
with the same pass_info as documented today in
http://gcc.gnu.org/onlinedocs/gccint/Plugins.html#Plugins ?
So perhaps I am simply not understanding what means the current stage 3 of trunk (ie future 4.5). I admit I did not
understood exactly why stage 2 disappeared (or perhaps we call today stage 3 what was called stage 2 or stage 3 a year
ago?). And perhaps I am wrongly guessing the release date of 4.5.0. Of course, if 4.5.0 is released in june 2010 things
are different!
I suppose that ICI friends will be happy if they can hope to push a new pass manager inside 4.5. My personal guess was
that this is hopeless - they need to wait for 4.6. I would be delighted to be wrong, and as Richard and others I would
be extremely happy with a new pass manager.
I think MELT can cope with any reasonable evolution of the pass manager.
I believe (only my opinion) that ICI people care a lot about being able or not to push an improved pass manager inside
4.5 or only inside 4.6. That makes a one year difference, and I guess one year is not insignificant to them.
Regards.
PS. BTW, I find that speaking of stages with number is confusing (especially since now stage 3 goes right after stage
1). I would much prefer named stages, like "major change stage", "minor improvement stage", "bug fix stage".
--
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} ***
RE: new plugin events
Basile, I understand your constraints and concerns. I personally would also be happy to see ICI and pass manager in GCC soon, BUT it was delay on our side that prevented submission/checking of the patch, so I am just taking a pragmatic approach of preparing an ICI patch first (well, actually not me but Joern who is now working full time on that), testing it and then submitting it and discussing with everyone and you if it's reasonable. ONLY THEN, depending if the changes are small and if GCC 4.5.0 is not yet closed, we will negotiate to move it to the mainline. But at the moment, before submitting it, it's just a gamble if it can go through or not and I personally don't want to do that because we will annoy all other GCC people who are working hard to make current GCC stable ... So, let's continue ICI discussions as soon as the ICI patch is ready ;) ... Cheers, Grigori > -Original Message- > From: Basile STARYNKEVITCH [mailto:bas...@starynkevitch.net] > Sent: Saturday, November 07, 2009 3:45 PM > To: Richard Guenther > Cc: Grigori Fursin; Steven Bosscher; Diego Novillo; Rafael Espindola; gcc; > Joern Rennecke; > Zbigniew Chamski > Subject: Re: new plugin events > > Richard Guenther wrote: > > On Sat, Nov 7, 2009 at 1:24 PM, Grigori Fursin > > wrote: > >> Hi Basile et al, > >> > >>> My suggestion to ICI friends is : just propose quickly your needed plugin > >>> events, and make > >>> your ICI a GPLv3 plugin. > >>> When you can show that your ICI plugin to an *unmodified* gcc-4.5 brings > >>> some value, GCC > >>> people will perhaps start to > >>> listen and look inside. > > >> Just to mention that I am a bit confused because I actually don't expect > >> to have problems > moving > >> ICI to the mainline unless we find some big bugs that can change GCC > >> behavior (but I really > don't > >> think so). > >> We had many online and offline discussions to move ICI to the mainline GCC > >> in the last few > years > >> with GCC > >> colleagues/maintainers. We just sadly got delayed at INRIA this summer due > >> to different > reasons but > >> Joern > >> is now working with us for 2 months fully time to clean and test ICI and > >> submit patches as > soon as > >> they are ready. > >> > >> It's true that we actually need a few hooks and Joern will communicate > >> about that shortly > BUT these > >> hooks are > >> already used in real plugins for real performance tuning (in a way as > >> current hooks are > used in > >> Dehydra > >> for real program analysis in several companies). > > > > And I don't expect problems in adding hooks that ICI needs. I expect > > that ICI is a reason to improve GCCs pass manager - and I expect that > > we will improve GCCs pass manager not by simply adding hooks to it > > to "fix" it from inside plugins, but I expect that we'll get a more powerful > > pass manager _inside_ GCC. I also expect or at least hope that more > > parts of the compilation process get driven by the pass manager rather > > than by ad-hoc code gluing several phases of pass manager driven > > stages. > > We probably all agree on goals, but perhaps less on timeline. > > My feeling (but I admit I don't understand well what stage 3 means precisely > for gcc 4.5.0, in > particular w.r.t. plugins > & pass management, and why exactly stage 2 was skipped in 4.5) was up to now: > > 1. Only very small patches can go into 4.5. So ICI pass manager won't go into > 4.5.0, and any > improved pass manager won't > go into 4.5.0, only in 4.6.0. This probably means in last quarter of 2010 or > first quarter of > 2011, since 4.4.0 was > released in april 2009, and 4.3.0 was released in march 2008 and 4.2.0 was > released in may > 2007 and 4.1.0 at end of > february 2006. I am guessing 4.5.0 would be released for christmas 2009 at > the earliest, so > 4.6.0 would go out at end of > 2010 in the best case. > > 2. I was hoping that the few PLUGIN_* hooks absolutely needed by ICI could go > into 4.5. My > intuition is that it really > means small unobtrusive patches which might be accepted before Christmas 2009. > > In other words, are there hope to delay 4.5.0 release for a month to get the > ICI-improved pass > manager inside it? In > case the answer is yes, will we keep the same interface, so that the > interface for > PLUGIN_PASS_MANAGER_SETUP won't > change with the improved pass manager? > register_callback (plugin_info->base_name, PLUGIN_PASS_MANAGER_SETUP, > NULL, &pass_info); > with the same pass_info as documented today in > http://gcc.gnu.org/onlinedocs/gccint/Plugins.html#Plugins ? > > > So perhaps I am simply not understanding what means the current stage 3 of > trunk (ie future > 4.5). I admit I did not > understood exactly why stage 2 disappeared (or perhaps we call today stage 3 > what was called > stage 2 or stage 3 a year > ago?). And perhaps I am wrongly guessing the release date of 4.5.0. Of > course, if 4.5.0 is > released in june 2010 things > are d
Updating Primary and Secondary platform list for gcc-4.5 ???
I was looking through the gcc-4.5 primary and secondary platform list to ensure we have coverage for MPC testing. It occurs to me that some of the OS versions are outdated. I've included the list from the page http://gcc.gnu.org/gcc-4.5/criteria.html Should we update: 1. solaris2.10 -> 2.11 2. hpux11.11 -> ??? 3. aix5.2 -> 5.3 For the purposes of MPC testing I also want to know: 1. Is mipsisa64-elf cross-config only? I.e. MPC portability testing is only relevant to the host platform where GCC is run. So we don't have to worry about this one? 2. i386-unknown-freebsd and i686-apple-darwin are generic, but config.guess will supply specific version numbers. What version should MPC be shown to work on? Any one of them would do? 3. For freebsd and darwin, do we want to include specific version numbers for our platform list, or leave them generic? Thanks, --Kaveh Primary Platform List arm-eabi i386-unknown-freebsd i686-pc-linux-gnu mipsisa64-elf powerpc64-unknown-linux-gnu sparc-sun-solaris2.10 x86_64-unknown-linux-gnu Secondary Platform List hppa2.0w-hp-hpux11.11 powerpc-ibm-aix5.2.0.0 i686-apple-darwin i686-pc-cygwin i686-mingw32 ia64-unknown-linux-gnu s390-linux-gnu
Re: Updating Primary and Secondary platform list for gcc-4.5 ???
> I was looking through the gcc-4.5 primary and secondary platform list > to ensure we have coverage for MPC testing. It occurs to me that some > of the OS versions are outdated. > > I've included the list from the page > http://gcc.gnu.org/gcc-4.5/criteria.html > > Should we update: > > 1. solaris2.10 -> 2.11 Why move to a not-yet-released version? -- Eric Botcazou
Re: MPC version 0.8 released!
"Kaveh R. GHAZI" writes: Please test this version and report back in this thread (not to me privately) the results of "make check". Also include your target triplet, and the versions of your compiler, gmp and mpfr. Wow we've gotten a lot of results, thanks everyone! But we're still missing a few of the GCC primary and secondary platforms for the mpc-0.8 final release. Some of you provided results for the missing systems either for the mpc-0.8dev prerelease or a previous full release. I would very much appreciate it if you would try out the latest package. The platforms still needed for mpc-0.8 release testing are: i386-unknown-freebsd (have results for mpc-0.8dev) i686-pc-cygwin (have results for mpc-0.8dev) hppa2.0w-hp-hpux11.11 (have results for mpc-0.8dev) i686-apple-darwin (have results for mpc-0.7) powerpc-ibm-aix5.3.0.0 (have results for mpc-0.7) i686-mingw32 (have results for mpc-0.7) Thanks! --Kaveh -- Kaveh R. Ghazi
Re: How to do executable individualization using optimization options ?
Byoungyoung Lee writes: > If the optimization options provided in a different way, > the same source codes would be compiled into different executables. > > In the different executables, > the register allocation or instruction orders might be easily changed, > but I think that's not that big change. > What I'd like to do is to make their CFG different, while their impact > on executing performance is reasonable. > > I'm reading through the compiler books and gcc internal documentations, > but it's really hard for me to pin point what I really need to read > and understand. > > So, my question is what kind of optimizing options in gcc could be > used to do such jobs ? > or would you recommend good references for this ? Sorry, I don't understand the question. Are you asking what gcc options will produce a different CFG? If so, this question would be better asked on gcc-h...@gcc.gnu.org. One answer is that you will get a slightly different CFG from options like -funroll-loops. In general there are a number of options which could change the CFG. But I'm not sure why you are asking the question. Ian
Re: MPC version 0.8 released!
On Sat, 7 Nov 2009, Kaveh R. Ghazi wrote: > The platforms still needed for mpc-0.8 release testing are: > > i386-unknown-freebsd (have results for mpc-0.8dev) Watch gcc-testresults, my first submission of building GCC trunk with mpc-0.8 (release) should appear there in a third of a day. Also, after I updated the math/mpc port in FreeBSD yesterday, FreeBSD users who remain up-to-date generally will adopt this. Gerald
Re: Updating Primary and Secondary platform list for gcc-4.5 ???
On Sat, 7 Nov 2009, Kaveh R. GHAZI wrote: > 2. i386-unknown-freebsd and i686-apple-darwin are generic, but > config.guess will supply specific version numbers. What version > should MPC be shown to work on? Any one of them would do? For FreeBSD, I'd specify versions 6.x and above. Older versions should work down to 3.x or 4.x, but it is not worth bothering unless someone is into retro computing. On the contrary, FreeBSD 6.x to some extent, and now 7.x primarily and now also 8.x are tested and used regularily. > 3. For freebsd and darwin, do we want to include specific version > numbers for our platform list, or leave them generic? I think it's fine keeping things as are. If you prefer, we can also make it "whatever Gerald or Loren are currently testing" for FreeBSD, of course. ;-) Gerald
Re: MPC version 0.8 released!
Kaveh R. Ghazi wrote: >> "Kaveh R. GHAZI" writes: >> >>> Please test this version and report back in this thread (not to me >>> privately) the results of "make check". Also include your target >>> triplet, and the versions of your compiler, gmp and mpfr. > i686-pc-cygwin === All 57 tests passed === $ cygcheck -cd gcc4 gmp mpfr Cygwin Package Information Package Version gcc4 4.3.4-1 gmp 4.3.1-3 mpfr 2.4.1-4 cheers, DaveK
Re: MPC 0.8 prerelease tarball (last release before MPC is mandatory!)
On Thu, Oct 29, 2009 at 12:18 PM, Kaveh R. GHAZI wrote: > A prerelease tarball of the upcoming mpc-0.8 is available here: > http://www.multiprecision.org/mpc/download/mpc-0.8-dev.tar.gz > > This release is feature complete with respect to C99 and GCC's needs. > So I expect to make this version be the one made mandatory for the > gcc-4.5 release. If there are any remaining bugs especially > portability problems to GCC's primary or secondary platforms, I'd like > to get those reported and fixed before this release is final. > > Please test this MPC package and report back the results of running > "make check" along with your target triplet, the compiler version you > used, and the versions of gmp/mpfr used to compile it. You do not > necessarily need to bootstrap mainline GCC with this MPC, but if you > have the spare time and cycles it would be nice too. MPC-0.8 build fails on AIX due to libtool. The changes to libtool between MPC-0.7 and MPC-0.8 rely on Bash-specific features. Manually editing libtool to use Bash allowed the build to succeed. David
Re: MPC version 0.8 released!
On Sat, 7 Nov 2009, Gerald Pfeifer wrote: >> i386-unknown-freebsd (have results for mpc-0.8dev) > Watch gcc-testresults, my first submission of building GCC trunk with > mpc-0.8 (release) should appear there in a third of a day. http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg00664.html Gerald
RE: MPC version 0.8 released!
> -Original Message- > From: Kaveh R. Ghazi [mailto:gh...@caip.rutgers.edu] > Sent: Saturday, November 07, 2009 10:40 AM > To: Gerald Pfeifer; dave.korn.cyg...@googlemail.com; > d...@hiauly1.hia.nrc.ca; David Edelsohn; Weddington, Eric > Cc: gcc@gcc.gnu.org > Subject: Re: MPC version 0.8 released! > > Wow we've gotten a lot of results, thanks everyone! But > we're still missing > a few of the GCC primary and secondary platforms for the mpc-0.8 final > release. Some of you provided results for the missing > systems either for > the mpc-0.8dev prerelease or a previous full release. I > would very much > appreciate it if you would try out the latest package. > > i686-mingw32 (have results for mpc-0.7) > mpc-0.8 passed all tests on i686-mingw32: === All 57 tests passed === gcc.exe (GCC) 3.4.5 (mingw-vista special r3) gmp 4.3.1 mpfr 2.4.1 Eric Weddington
Re: MPC 0.8 prerelease tarball (last release before MPC is mandatory!)
From: "David Edelsohn" MPC-0.8 build fails on AIX due to libtool. The changes to libtool between MPC-0.7 and MPC-0.8 rely on Bash-specific features. Manually editing libtool to use Bash allowed the build to succeed. Hi David, Can you please be more specific about this problem? I've seen several build reports on non-gnu systems that don't use bash as the default shell, including my own solaris2.9 box. None of them fail on bash-isms. So I'm curious what the actual failure is on AIX. The more recent libtool was suggested to avoid some issues on darwin, so I prefer not to opt for a downgrade if at all possible. If there is some non-portable shell construct, we should file a bug report with the libtool maintainers. Another option in the mean time is that if ksh or some other shell supplied by default works on AIX we could recommend using that via CONFIG_SHELL. What do you suggest as possible ways forward? Thanks, --Kaveh
