new optimizations for lunar - part1
Zbigniew Łuszpiński
zbiggy at o2.pl
Wed May 4 12:06:36 UTC 2005
> On Wednesday 04 May 2005 03:32 am, Auke Kok wrote:
> > Zbigniew Łuszpiński wrote:
> > >Hi everyone
> > >
> > >I made patch for lunar tools which:
> > >* removes deprecated (for x86, x64 architecture only!), slowdown gcc
> > > option: -mcpu=
> > >* adds new option -freorder-blocks
> > >
> > >Installation:
> > >Copy /var/lib/lunar to safe place (to have backup before patching)
> > >unpack newopti.diff.bz2 to /var/lib/
> > >go to /var/lib and execute: patch -p0 < newopti.diff
> > >
> > >After installation a new option will appear in Lunar Optimizations/Speed
> > >optimizations: Blocks -freorder-blocks
> > >
> > >Additional information:
> > >This patch I use on my computer and it works. Do not know what happen on
> > > other computers so be smart applying it.
> > >
> > >The -freorder-blocks function is rather safe optimization flag which is
> > >enabled by default in -O2 and -O3 optimizations and disabled in -O0, -O1
> > > and -Os. If someone like me uses -Os optimization and want to get
> > > little speedup can safely use -freorder-blocks. Compiled program can be
> > > little bigger than -Os but smaller than -O2 and much smaller than -O3.
> > > This is good trade-off (speed/size) in my opinion.
> > >
> > >-mcpu= makes code optimized for given processor but runable with 386. I
> > > think that nobody needs such crazy optimization. The -march= option
> > > implies -mcpu=. With gcc 3.4 you will even get ugly warning about
> > > deprecated -mcpu=.
> > >
> > >After throwing away -mcpu these options are useless:
> > >-mmmx, -msse, -msse2, -msse3, -m3dnow,
> > >the -march option implies them if specified CPU have support for them.
> > >The compilation process is little faster because gcc do not waste time
> > >processing many commandline options.
> > >Refer to gcc manual, mailinglist for more information about gcc options.
> > >
> > >This is my first patch for lunar publicly available so feel free to post
> > >comments.
> >
> > Zbigniew,
> >
> > thanks for your patch. I've quickly taken a look at it and have some
> > comments with regard to your changes:
> >
> > - -mcpu in lunar is set to the same architecture as -march, we do that
> > so that no unoptimized i386 code is present in i686 optimized programs,
> > so it makes sense to use -mcpu to 'remove compatibility code for slower
> > cpus'.
> >
> > -> however, I'll see if we can turn on/off the -mcpu option with a flag
> > as to achieve downwards compatible code anyways, as this may be of use
> > to people running the same binaries on multiple platforms.
> >
> > - the sse/sse2/mmx flags are useful to people who wish to use mmx/sse
> > with slower optimizations
> >
> > - the '-freorder-blocks' looks interesting, however I don't think there
> > are many people who use -Os or -O1 optimization right now, so the
> > usability is low again. However for the ISO's it might be of use, or
> > anyone who's experimenting with smaller but still optimized code.
> >
> > In any case the -mcpu idea is interesting and I'll try to see if I can
> > fit it in.
> >
> > Thanks for your patch!
> >
> > sofar
> >
> > _______________________________________________
> > Lunar mailing list
> > Lunar at lunar-linux.org
> > http://foo-projects.org/mailman/listinfo/lunar
>
> I do not want to lose the sse/sse2/mmx flags. :)
My patch do not remove sse/sse2/mmx options in menu - they are still there.
You can always enable/disable them. I only said if the -march= is enabled and
-mcpu= removed specyfing them is useless because they are already enabled by
-march= without using sse/sse2/mmx switches. Using e.g. -march=pentium-4 and
-mmmx -msse -msse2 will simply turn on mmx/sse/sse2 twice.
greets,
zbiggy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://foo-projects.org/pipermail/lunar/attachments/20050504/b27af809/attachment.bin
More information about the Lunar
mailing list