Can we fix reverse operator overloading (opSub_r et. al.)?

Rainer Deyke rainerd at eldwood.com
Sat Jul 11 01:34:48 PDT 2009


BCS wrote:
> Ok try another case:
> 
> y = a*b + c*a;
> 
> for scalers, the compiler can (and should) convert that 3 ops to 2:
> 
> y = a*(b+c);
> 
> for a matrix you can't. And I'm sure there are matrix cases where you
> can get improvements by doing algebraic manipulations before you inline
> that would be darn near impossible to get the compiler to figure out
> after you inline.

There are two possible cases:
  - The algebraically manipulated expression is functionally equivalent
to the original expression.  In this case, the optimizer should produce
the exact same code whether for both expressions, so the high-level
algebraic manipulation is unnecessary.  (Yes, I'm asking a lot from the
optimizer.)
  - The algebraically manipulated expression is /not/ functionally
equivalent to the original expression.  In this case the algebraic
manipulation is invalid, and should not be performed.

Optimizing complex expressions is not algorithmically more difficult
than optimizing simple expressions, it just takes more memory and CPU time.


-- 
Rainer Deyke - rainerd at eldwood.com



More information about the Digitalmars-d mailing list