develooper Front page | perl.perl5.porters | Postings from February 2008

Re: optimisations you just can't do (was Re: Interesting self contained task)

Nicholas Clark
February 25, 2008 14:34
Re: optimisations you just can't do (was Re: Interesting self contained task)
Message ID:
On Mon, Feb 25, 2008 at 02:47:21PM -0600, David Nicol wrote:
> On Mon, Feb 25, 2008 at 5:59 AM, Nicholas Clark <> wrote:
> >  So attempting to do a late optimisation of unpack (or anything else) in
> >  Perl_scalar(), won't cause the resulting constant to be propagated outwards
> >  into any surrounding constant expression.
> >
> >  I guess the "right" time to do this (if at all) would be another
> >  post-everything optimisation phase, which either:
> >
> >  a: Knows that it can't use the op_next pointers, and forcibly re-links once
> >    at the end if anything changed.
> >  b: Pessimistically re-links each time any individual optimisation triggers.
> a "smart compilation" or "smart lexing" pass?  What if pack/unpack were flagged
> as something that required special attention at lexing time, so a constant would
> get re-expressed as such sufficiently early? (call it "weak macros")

I think you've snipped too much of my message here.

1: pack isn't a problem.

(If I understand the term "lexing" and hence "lexing" in the context of perl),

2: lexing is *way* too early. One can't know whether unpack can be constant
   folded until the (yacc) parser has worked outwards from it.

3: Anything special-cased at the right time for unpack *also* then needs a
   second go at constant folding. Because the current implementation of
   constant folding is carefully implemented so that it only ever has to work
   on one operator (or function) at a time [I don't know if this is a
   standard approach, or something clever from Larry], any second go at
   constant folding would have to be implemented in some other fashion.

Nicholas Clark Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About