Optimisation possibilities: current, future and enhancements

[Chris Wright via Digitalmars-d]

On Fri, 26 Aug 2016 10:32:55 +0000, kink wrote:
> Inlining and subsequent constant folding are only available if the
> callee isn't an external.

The optimizations being discussed are a result of purity guarantees that 
have nothing to do with inlining. The example showed constant folding as 
a way to get code that the compiler could obviously optimize (assuming it 
took advantage of purity) without that fact necessarily being obvious to 
the programmer.

These purity guarantees are available even if the compiler has no access 
to the source code of the pure function.

As a more concrete example, let's suppose I am dynamically linking to a 
compression library and compiling with a D interface file rather than 
full source. It has as one of its functions:

extern(D) size_t maxEncodedSize(size_t inputSize) pure;

I have a couple structs that happen to be the same size:

struct EntityID {
  ulong id;
  ulong family;
}
struct GPSCoordinates {
  double latitude, longitude;
}

I need to compress both of them and send them over the wire in one 
bundle, and I want to allocate a buffer in advance, so I write:

auto size =
    maxEncodedSize(EntityID.sizeof) +
    maxEncodedSize(GPSCoordinates.sizeof);
ubyte[] buf = new ubyte[size];

With pure, the compiler can rewrite that to:

ulong size = maxEncodedSize(16) << 1;
ubyte[] buf = new ubyte[size];

No inlining. No constant folding.