Immutables converted to immediates

[Iain Buclaw]

On Wednesday, 28 June 2023 at 17:27:37 UTC, Cecil Ward wrote:
> GDC is generating a structure in the code segment and then 
> fetching it even though the values of the elements ought to be 
> known at compile-time. I’m not sure why. The actual code, 
> x86-64 in this case, consists of a load of fetches from the 
> code segment into successive registers before the start of the 
> loop, and the loop then consists of a load of instructions like 
> cmp [r8+4*rax], r9, where r9, r10 etc we’re loaded up from the 
> fetches from [rip+disp] before th4 loop, a minor strength 
> reduction compared to a compare-immediate, as it has plenty of 
> registers free. The mystery is why the fetches from [rip+disp] 
> even exist, given that they are known values.

Right, `immutable` (as well as `const`) has rather wobbly 
meanings, because you can have immutable data/fields that are 
initialized by a constructor - so in the worst case it can't be 
rodata at all.

For example:
```
immutable uint[] arr;

shared static this()
{
     arr = [1,2,3];
}
```
Here, we can't possibly know what the length of arr will end up 
being at run-time.

Based on the current wording of [the 
spec](https://dlang.org/spec/const3.html#const_and_immutable),

2. `immutable` applies to data that cannot change. Immutable data 
values, once constructed, remain the same for the duration of the 
program's execution.

3. `const` applies to data that cannot be changed by the const 
reference to that data. It may, however, be changed by another 
reference to that same data.


I guess there's scope for applying read-only semantics to both 
const and immutable locals/parameters.  For static data, only 
immutables that aren't set in a ctor can be read-only.