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

[Rainer Deyke]

Jarrett Billingsley wrote:
> 1) The compiler doesn't always have the code.  If you're linking
> against a library, where the operator overloads are not given in the
> headers, the compiler doesn't have their code.  Link-time optimization
> might be able to help here, but without the original syntax tree to
> work with, it's probably not going to be able to do the same things.
> 
> 2) The compiler doesn't necessarily have enough information to
> optimize properly.  Virtual calls destroy any guarantees.  OK, sure,
> you could say "vector and matrix types really should be structs and
> therefore not use virtual calls," but in the general case, the
> compiler can't figure these things out.

Yes and no in both cases.  Yes, the way way DMD is set up makes these
kind of optimizations exceedingly difficult.  Cross-library function
calls and slow and virtual function calls are slow.  I tend to assume
that all performance-critical code is templated anyway, which is
incompatible with both libraries and virtual functions.  Better to move
as many calculations as possible from run time to compile time.

On the other hand, JIT compilers for fully dynamic languages can perform
these types of optimizations.  A clever D implementation could do the same.

> You're right, however, that in the vast majority of cases, the
> compiler *could* optimize calls to these functions.  But you still
> might need some way of informing the compiler "hey!  I really _really_
> would like you to inline this."

I'm not really opposed to the idea of optional optimization hints, but
I'd like to see a compiler clever enough to not need them.


-- 
Rainer Deyke - rainerd at eldwood.com