Immutables converted to immediates

[Cecil Ward]

On Saturday, 1 July 2023 at 20:52:14 UTC, Iain Buclaw wrote:
> 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()
> {

Thanks for that Iain, I didn’t know that but I suspected as much. 
It would be good if immutables could be just turned into 
immediate values where individual elements are known. It would 
also be good if larger immutables could be placed in real ROM or 
else in a readonly no-execute data segment, where the system 
architecture permits.