Optimizing Immutable Data?

David Nadlinger via digitalmars-d-ldc digitalmars-d-ldc at puremagic.com
Fri Jul 10 12:12:33 PDT 2015


> Found it, from 42:20 to 43:00.
> https://youtu.be/ScHZsO1RzAI?t=42m20s

Thanks for the link.

As Kai pointed out, we do store immutable globals in the read-only data segment (or rather, emit them as LLVM `constant`s and let the backend figure out how to best take advantage of that).

What I thought about when Amaury brought up the topic are LLVM’s function attributes like `readonly` (see http://llvm.org/docs/LangRef.html). These are a bit harder to take advantage of, as last time I tried to, LLVM optimizes aggressively based on them in the sense that it assumes that any violations (such as after casting away immutable) are undefined behavior and thus cannot be reached.

There is a similar story with `pure` and `nothrow`. As long as the D spec is not perfectly clear that violating them is undefined behavior, these will remain hard to exploit for us. For example, `nothrow` is useless for optimization as long as code can actually throw Errors and expect them to unwind correctly. Now, in this specific case, Walter agrees that it should be legal to just abort on Errors in release builds, but the general theme remains. For example, we can't optimize on `pure` in debug builds because there might be `debug` blocks that circumvent purity, and so on.

We really need to clarify the language specification here so that people no longer assume that it is okay to do things that DMD lets them get away with.

 — David



More information about the digitalmars-d-ldc mailing list