Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

optimising, and per file flags

3 views
Skip to first unread message

Nicholas Clark

unread,
Jan 12, 2003, 10:45:37 AM1/12/03
to perl6-i...@perl.org
IIRC Leo added an option to Configure.pl to turn on optimising.

Prior to this, on IRC Dan said to me that we need to avoid the hack that perl5
found itself in, when it had to retro-fit the ability to change the compiler
flags per file.

Currently I don't think we have this ability. I was wondering if we could do
it by specifying the optimiser flags in the form of

/.../=xxx
!...!=xxx

yyy

where the first two give a regular expression for the object file(s) we wish
flags xxx to apply to. The alternative of !! for m!! should be allowed so
that paths can be specified in the object files as needed, without shell
escaping. All paths should be in Unix forward slash format, to reduce
potential confusion. If there are no flags, then yyy applies to all other
files.

I think this works, except that I'm not sure how to have whitespace in xxx
but let us have multiple regexps. I *think* we need to do this by having
optimiser options be an array - specify the array on the command like by
having multiple --optimise= flags, and interactively just keep accepting more
flags, terminating at the first global flags yyy line.

[We could even provide --optimize= as a synonym for the the Americans :-)]

The reason I bring this up - I've just found this while browsing the
gcc info pages:

`-fgcse'
Perform a global common subexpression elimination pass. This pass
also performs global constant and copy propagation.

_Note:_ When compiling a program using computed gotos, a GCC
extension, you may get better runtime performance if you disable
the global common subexpression elmination pass by adding
`-fno-gcse' to the command line.

Has anyone [er, I'm thinking of Leo :-)] tried benchmarking computed goto
without this flag? And with the various align functions, such as
-falign-jumps ?

Nicholas Clark

Dan Sugalski

unread,
Jan 12, 2003, 9:15:26 PM1/12/03
to Nicholas Clark, perl6-i...@perl.org
At 3:45 PM +0000 1/12/03, Nicholas Clark wrote:
>Prior to this, on IRC Dan said to me that we need to avoid the hack that perl5
>found itself in, when it had to retro-fit the ability to change the compiler
>flags per file.

Right, I want to do it right to begin with, as we'll undoubtedly have
to do it anyway.

This is all compiler and platform dependent. Pulling out GCC as an
example, -O3 is too much for one or two of perl 5's source modules,
but only on certain platforms and certain GCC versions. I have no
doubt that we'll trip some C compiler bugs somewhere as well, so we
might as well plan for it now.
--
Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk

Leopold Toetsch

unread,
Jan 13, 2003, 11:14:54 AM1/13/03
to Nicholas Clark, perl6-i...@perl.org
Nicholas Clark wrote:

> IIRC Leo added an option to Configure.pl to turn on optimising.


Yep.


> Has anyone [er, I'm thinking of Leo :-)] tried benchmarking computed goto
> without this flag? And with the various align functions, such as
> -falign-jumps ?


-O3 -fno-gcse doesn't compile the core_ops_cg.c either with 2.95.2
So in all bemchmarks, this file was (when used) w/o optimizations.

We should have per file compile flags and selectable per compiler, brrr,
2.95.3 can compile the file -O3.

The -malign flags seem to have reasonable defaults.

> Nicholas Clark

leo


Nicholas Clark

unread,
Jan 13, 2003, 11:50:23 AM1/13/03
to Leopold Toetsch, Nicholas Clark, perl6-i...@perl.org
On Mon, Jan 13, 2003 at 05:14:54PM +0100, Leopold Toetsch wrote:
> The -malign flags seem to have reasonable defaults.

As in you've read what they are, and they seem reasonable, or you've
actually tested the timings when playing with them?

colon has too much load ("damn users" (of which I'm one)) right now to play
with benchmarking, but setting alignment to 16 bytes did seem to make perl
run the regression tests more quickly.

Nicholas Clark

Steve Fink

unread,
Jan 13, 2003, 12:22:07 PM1/13/03
to Nicholas Clark, perl6-i...@perl.org
On Jan-12, Nicholas Clark wrote:
> IIRC Leo added an option to Configure.pl to turn on optimising.
>
> Prior to this, on IRC Dan said to me that we need to avoid the hack that perl5
> found itself in, when it had to retro-fit the ability to change the compiler
> flags per file.
>
> Currently I don't think we have this ability. I was wondering if we could do
> it by specifying the optimiser flags in the form of
>
> /.../=xxx
> !...!=xxx
>
> yyy
>
> where the first two give a regular expression for the object file(s) we wish
> flags xxx to apply to. The alternative of !! for m!! should be allowed so
> that paths can be specified in the object files as needed, without shell
> escaping. All paths should be in Unix forward slash format, to reduce
> potential confusion. If there are no flags, then yyy applies to all other
> files.

Would it be better to do it the other way around? We could put a
marker at the end of each source file (mixed in with the emacs/vi flag
section?) that specifies a set of compiler flags (or nothing at all if
the default is ok.)

If so, then I'd probably also use named sets ("big-jumptable-flags")
or maybe even named modifiers ("default but violates-aliasing and
trips-gcc2.95-O3-bug"). This would allow better descriptions of why
the flags were being modified, and allow each compiler to deal with
the situation differently (for "violates-aliasing", gcc would add
-fno-strict-aliasing, lcc wouldn't do anything.)

I'm assuming the Configure system extracts the information from the
source files and generates a makefile entry per source file with the
appropriate compiler flags.

Leopold Toetsch

unread,
Jan 13, 2003, 1:10:40 PM1/13/03
to Nicholas Clark, Nicholas Clark, perl6-i...@perl.org
Nicholas Clark wrote:

> On Mon, Jan 13, 2003 at 05:14:54PM +0100, Leopold Toetsch wrote:
>
>>The -malign flags seem to have reasonable defaults.
>>
>
> As in you've read what they are, and they seem reasonable, or you've
> actually tested the timings when playing with them?


The impact is very small, though -malign-jumps=1 give worse results. But
2,3,4 or no options at all are too similar to say, it does something.


> Nicholas Clark


leo


Nicholas Clark

unread,
Jan 16, 2003, 3:58:02 PM1/16/03
to Steve Fink, perl6-i...@perl.org
On Mon, Jan 13, 2003 at 09:22:07AM -0800, Steve Fink wrote:
> On Jan-12, Nicholas Clark wrote:
> > IIRC Leo added an option to Configure.pl to turn on optimising.
> >
> > Prior to this, on IRC Dan said to me that we need to avoid the hack that perl5
> > found itself in, when it had to retro-fit the ability to change the compiler
> > flags per file.

> Would it be better to do it the other way around? We could put a


> marker at the end of each source file (mixed in with the emacs/vi flag
> section?) that specifies a set of compiler flags (or nothing at all if
> the default is ok.)
>
> If so, then I'd probably also use named sets ("big-jumptable-flags")
> or maybe even named modifiers ("default but violates-aliasing and
> trips-gcc2.95-O3-bug"). This would allow better descriptions of why
> the flags were being modified, and allow each compiler to deal with
> the situation differently (for "violates-aliasing", gcc would add
> -fno-strict-aliasing, lcc wouldn't do anything.)

I don't think that this will fly. The sort of flags we need to change are
things like this (Unicos):

if /etc/cpu -i | grep -q cfp
then
ccflags="$ccflags -h rounddiv"
fi

# Avoid an optimizer bug where a volatile variables
# isn't correctly saved and restored --Mark P. Lutz
pp_ctl_cflags='ccflags="$ccflags -h scalar0 -h vector0"'
# Otherwise the unpack %65c checksums will fail.
pp_pack_cflags='optimize="$ccflags -h scalar0 -h vector0"'

or this (Irix 6, based on a test of compiler version)

# workaround for an optimizer bug
# Made to work via UU/config.sh thing (or, rather, config.sh, since we're in
# a callback) from README.hints, plus further stuff; doesn't handle -g still,
# unfortunately - Allen
case "`$cc -version 2>&1`" in
*7.2.*)
test -z "$op_cflags" && echo "op_cflags=\"optimize=\\\"\$optimize -O1\\\"\"" >> config.sh
test -z "$op_cflags" && op_cflags="optimize=\"\$optimize -O1\""
test -z "$opmini_cflags" && echo "opmini_cflags=\"optimize=\\\"\$optimize -O1\\\"\"" >> config.sh
test -z "$opmini_cflags" && opmini_cflags="optimize=\"\$optimize -O1\""
;;
*7.3.1.*)
test -z "$op_cflags" && echo "op_cflags=\"optimize=\\\"\$optimize -O2\\\"\"" >> config.sh
test -z "$op_cflags" && op_cflags="$op_cflags optimize=\"\$optimize -O2\""
test -z "$opmini_cflags" && echo "opmini_cflags=\"optimize=\\\"\$optimize -O2\\\"\"" >> config.sh
test -z "$opmini_cflags" && opmini_cflags="optimize=\"\$optimize -O2\""
;;
esac

and other evil to work round compiler bugs found mainly by sweating blood.
(I don't know about the Irix bugs, but I do remember that working out
what the cause of Unicos bugs were wasn't fun. And I was mostly following
along at home by e-mail, not being able to offer Mark much more than
moral support. When unpack is going into an infinite loop on a Cray 6000 miles
away that you don't have any access to, there isn't much more you can do)

> I'm assuming the Configure system extracts the information from the
> source files and generates a makefile entry per source file with the
> appropriate compiler flags.

I'm also assuming a makefile entry for all source files with non-default
compiler flags, and a .c$(OBJ_EXT): rule for the default

So I'm thinking that we'll have a lot of per platform compiler specific
cruft that will need to be generalised programatically.

But more importantly we need a way for anyone to manually configure parrot
with wacky flags for a single file. Otherwise responses to perl6bug are going
to be along the lines of "edit the section in the source file, and add a new
(complex) rule that will trigger on your platform. Then reconfigure. Then
check the Makefile to see if that rule really did trigger".

Nicholas Clark

0 new messages