Front page | perl.perl6.internals |
Postings from July 2001
Re: -g vs. -O
From: Dan Sugalski
July 6, 2001 07:39
Re: -g vs. -O
Message ID: firstname.lastname@example.org
At 05:38 AM 7/6/2001 -0700, Benjamin Stuhl wrote:
>Alright, here's an issue I was musing on after dinner
>yesterday: There are huge sets of optimizations that could
>be made *if* the user promises not to do certain things.
>For instance, who needs a symbol table when the user has
>promised not to do any symbolic lookups?
eval. And by extension do, require, and use. Any OO program that we can't
fully bind method calls at compile time. (Gotta find those methods
somehow...) Rational runtime error messages. Precompiled modules most likely.
>-g : include all information required for debugging (symbol
> tables, etc.) and do not perform optimizations
This will be the default for compile-and-go perl.
>-O# : controls just how complex the optimizations we try to
> make are, given the constraints we're under from what
> the user did _not_ promise to abstain from
>-fpromise : this is a bit different from gcc, where it
> controls individual optimizations - instead, in
> Parrot it enumerates the promises the user
> (eg. I solemnly swear to never use symbolic
> references, count on specific op patterns, or
> use any number large enough to require
>If certain promises become very common, they could possibly
>get their own flag or something.
I loathe the GCC style flags--I'd much rather we have something more
verbose with automagic shortest-unique-abbreviation code.
I'm not sure we need a separate flag for optimization level and
assumptions, but if we do something more like what Compaq C does:
Yes, I know it's wordier, but the above can be abbreviated to:
which isn't bad at all.
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
email@example.com have teddy bears and even
teddy bears get drunk