[perl #58410] [TODO] Deprecate n_* variants of the math opcodes

[Klaas-Jan Stol via RT]

On Fri Aug 29 00:44:18 2008, allison at perl.org wrote:
> Geoffrey Broadwell via RT wrote:
> > 
> > What is the replacement for the old "regular" variants that use a
> > pre-existing destination?
> > 
> > A few years ago when I was doing copious Perl 5 PDL work, I found 
that
> > in certain loops I would get bottlenecked entirely by creation and
> > destruction of temporaries.  I might be doing several dozen math
> > operations per iteration, but I as the programmer knew that I only
> > needed a handful of temporaries, and these could be created outside 
the
> > loop.  The vast majority of the object cycling was quite obviously
> > wasted.  In some cases, I could work around this by considerably
> > uglifying the code and/or reaching through several layers of
> > abstraction, but sometimes there was no recourse except to drop to
> > PDL::PP (specially preprocessed C) or even C itself.
> > 
> > I'd like to be able to write decently-performing math libraries in 
PIR,
> > instead of having to drop down all the way to C.  Being forced to 
create
> > and destroy loads of temporaries I don't need will make this nigh
> > impossible, let alone putting a major strain on the GC subsystem.
> > 
> > Will there be some way to stay in PIR and still optimize away 
temporary
> > cycling?
> 
> Compared to the cost of the multiple dispatch that all the math ops 
do, 
> the cost of creating a temporary variable to hold the result is very 
minor.
> 
> That said, the semantics of whether the destination PMC is modified or 
> replaced by a new one is determined by the particular sub selected by 
> multiple dispatch. It's even possible (or will be once the MMD branch 
is 
> merged back in) to define a non-multi vtable function in a particular 
> PMC, to optimize away the cost of multiple dispatch.
> 
> Allison
> 

I think this has been resolved, but not sure.
Can anyone confirm?

cheers,
kjs