At Dconf, one of the speakers made an off-hand comment that LDC could use an LLVM feature to optimize immutable variables by storing them differently than mutable data. The LDC developer that was there made a response, but the mic didn't pick it up.

Is this something that has already been done? Should a bug report be filed so this is tracked?

On Monday, 6 July 2015 at 18:40:11 UTC, Jack Stouffer wrote:
> At Dconf, one of the speakers made an off-hand comment that LDC could use an LLVM feature to optimize immutable variables by storing them differently than mutable data. The LDC developer that was there made a response, but the mic didn't pick it up.
>
> Is this something that has already been done? Should a bug report be filed so this is tracked?

David was at Dconf. It would be nice if he could repeat his answer here. I am currently unsure to which LLVM feature the speaker referred.

Suppose in module imm.d:

int x = 6;
immutable(int) y = 42;

This is translated to the following IR:

@_D3imm1xi = thread_local global i32 6
@_D3imm1yyi = constant i32 42

which is already different.

Regards,
Kai

On Monday, 6 July 2015 at 19:20:58 UTC, Kai Nacke wrote:
> David was at Dconf. It would be nice if he could repeat his answer here. I am currently unsure to which LLVM feature the speaker referred.

Unfortunately, I don't recall any details – there were many discussions at DConf. I'm afraid I need a little help as to which specific remark Jack means.

 — David

On Tuesday, 7 July 2015 at 21:19:19 UTC, David Nadlinger wrote:
> Unfortunately, I don't recall any details – there were many discussions at DConf. I'm afraid I need a little help as to which specific remark Jack means.

I saw it on the original live stream. I am currently watching the Dconf videos as they are released on YouTube so I'm sure I will find it eventually.

On Friday, 10 July 2015 at 14:06:59 UTC, Jack Stouffer wrote:
>

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

> 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

Thanks for the response.

On Friday, 10 July 2015 at 19:12:43 UTC, David Nadlinger wrote:
> For example, we can't optimize on `pure` in debug builds because there might be `debug` blocks that circumvent purity, and so on.

Do you then correctly optimize this in release builds?

> 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.

Are there any open bug reports on bugzilla for the nothrow problem? I know that Brian Schott has succeeded in getting a lot of specification problems resolved by tracking them in https://issues.dlang.org/show_bug.cgi?id=10233.