Re: -g vs. -O
At 01:59 PM 7/6/2001 -0500, David L. Nicol wrote: >Dan Sugalski wrote: > > > > At 12:51 PM 7/6/2001 -0500, David L. Nicol wrote: > > >Benjamin Stuhl wrote: > > > > > > > (eg. I solemnly swear to never use symbolic > > > > references, count on specific op patterns, or > > > > use any number large enough to require > > > > bignums.) > >Would these promises be better stated as in-code pragmata instead >of compiler switches? Lexically scoped optimization hints seem like rather a tricky thing to deal with. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: -g vs. -O
Dan Sugalski wrote:
>
> At 12:51 PM 7/6/2001 -0500, David L. Nicol wrote:
> >Benjamin Stuhl wrote:
> >
> > > (eg. I solemnly swear to never use symbolic
> > > references, count on specific op patterns, or
> > > use any number large enough to require
> > > bignums.)
Would these promises be better stated as in-code pragmata instead
of compiler switches?
{
no symrefs;
${$thing}; # assuming $thing is a reference is now safe
}
Re: -g vs. -O
At 12:51 PM 7/6/2001 -0500, David L. Nicol wrote:
>Benjamin Stuhl wrote:
>
> > (eg. I solemnly swear to never use symbolic
> > references, count on specific op patterns, or
> > use any number large enough to require
> > bignums.)
>
>These are things (aside from the number limit, but overflow catching
>is needed anyhow, so switching to bignums instead of crashing and
>burning seems like a reasonable default behavior) that could be
>easily identified and flagged (well, use of symbolic reference) at
>first-pass time.
>
>Except for
>
>
> ${$thing}
>
>if we don't know if $thing is a reference or a name -- but can that
>be figured out on first-pass?
No. Unfortunately not, at least not without a *lot* of analysis, far more
than is likely to be worthwhile. This:
$thing = bar();
${$thing};
shoots it down pretty hard. (While we'll be doing interprocedural analysis,
I think, doing it on the level that'd be required to figure that out with
any certainty isn't fast. It's also something of a research area AFAIK,
since very few languages have the sort of loose, late-binding (and that's
late as in "Waiting for Godot" late...) characteristics of perl. The ones
that do don't have much literature dedicated towards generating optimizing
compilers, at least not that I've found)
>Is there an entry point between this
>line and $thing's last use as an l-value, and can the expression
>that is getting assigned there be seen to clearly be a reference?
>
>Do we even care?
>
>if symbolic reference only gets fallen back to when, oops, something
>that is not a reference gets used as one, what exactly do we save? The
>check to verify that something is in fact a reference?
It hoses optimization. What do you do, for example, if symbolic references
like that end up replacing functions in the symbol table? (Kiss inlining
good bye) Or they add in new methods? (Shoot your method cache) Or just add
in new variables? (Which makes compile time validation of variable
interpolation in strings, or "used only once" errors, kinda wrong)
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: -g vs. -O
Benjamin Stuhl wrote:
> (eg. I solemnly swear to never use symbolic
> references, count on specific op patterns, or
> use any number large enough to require
> bignums.)
These are things (aside from the number limit, but overflow catching
is needed anyhow, so switching to bignums instead of crashing and
burning seems like a reasonable default behavior) that could be
easily identified and flagged (well, use of symbolic reference) at
first-pass time.
Except for
${$thing}
if we don't know if $thing is a reference or a name -- but can that
be figured out on first-pass? Is there an entry point between this
line and $thing's last use as an l-value, and can the expression
that is getting assigned there be seen to clearly be a reference?
Do we even care?
if symbolic reference only gets fallen back to when, oops, something
that is not a reference gets used as one, what exactly do we save? The
check to verify that something is in fact a reference?
Could that check be deferred into an exception handler?
--
David Nicol 816.235.1187
"It's widely known that the 'F' in RTFM is silent." -- Olie
Re: -g vs. -O
At 09:51 AM 7/6/2001 -0500, Jarkko Hietaniemi wrote: > > 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: > > > >-optimize=(level=5,inline) -assume=(nosub_redefinition,notype_change) > >The () will unleash the hell in UNIX shells. > > > Yes, I know it's wordier, but the above can be abbreviated to: > > > >-o=(5,in) -a=(nosub,notype) > > > > which isn't bad at all. > >Just drop the () and if someone needs spaces in the arguments they'll >use whatever the CLI needs to quote those. Fair enough. The parens are nice but hardly required. >And before someone pipes in with -O, I remind that we want to be >portable so we can't assume case-sensitive CLIs. Yep. Besides, case-sensitive single-character are a royal pain to remember (ignoring the whole "every program has a mildly different set" problem), and really are a bit of a hack wedged in to avoid multi-character switches. And since we're not going to, the potential confusion just doesn't seem worth the keystroke savings. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: -g vs. -O
> 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: > >-optimize=(level=5,inline) -assume=(nosub_redefinition,notype_change) The () will unleash the hell in UNIX shells. > Yes, I know it's wordier, but the above can be abbreviated to: > >-o=(5,in) -a=(nosub,notype) > > which isn't bad at all. Just drop the () and if someone needs spaces in the arguments they'll use whatever the CLI needs to quote those. And before someone pipes in with -O, I remind that we want to be portable so we can't assume case-sensitive CLIs. -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: -g vs. -O
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 >makes > (eg. I solemnly swear to never use symbolic > references, count on specific op patterns, or > use any number large enough to require >bignums.) > >If certain promises become very common, they could possibly >get their own flag or something. > >Thoughts? 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: -optimize=(level=5,inline) -assume=(nosub_redefinition,notype_change) Yes, I know it's wordier, but the above can be abbreviated to: -o=(5,in) -a=(nosub,notype) which isn't bad at all. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
-g vs. -O
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? (Yes, I know, the debugger, but only _if_ the user actually wants to debug the program.) Thus, I propose 3 command-line switches (highly reminiscent of gcc...): -g : include all information required for debugging (symbol tables, etc.) and do not perform optimizations -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 makes (eg. I solemnly swear to never use symbolic references, count on specific op patterns, or use any number large enough to require bignums.) If certain promises become very common, they could possibly get their own flag or something. Thoughts? -- BKS __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/
