align allocations according to the actual type alignment, not an unconditional 16

[rainers]

In my phobos-build-all-unittest this saves about 4% of memory of what the the front end needs.

AFAICT alignment deviates from size_t.sizeof only for IntegerExp when building for 32-bit, though.

[github-actions]

DMD perf check

Metric	Base	PR	delta
compile hello.d (instr)	216.0 M	213.4 M	-1.20%
compile hello.d -O (instr)	234.5 M	231.9 M	-1.11%
compile Phobos (instr)	5,131.8 M	5,073.7 M	-1.13%
compile Phobos codegen (instr)	1,472.9 M	1,471.8 M	-0.08%
compile vibe.d (instr)	15,146.3 M	14,959.2 M	-1.24%
dmd binary size (stripped)	6.92 MB	6.95 MB	+0.40%
hello binary size	0.72 MB	0.72 MB	0.00%
peak RSS (compile hello.d)	44 MB	43 MB	-0.30%
peak RSS (compile Phobos)	637 MB	639 MB	+0.23%
peak RSS (compile vibe.d)	1982 MB	1979 MB	-0.18%

[rainers]

@thewilsonator Please wait with merging. I will investigate whether the measured 1% compile time increase is legit. If it is it might not be worth the memory savings of less than 2% (the overall memory includes the backend that uses about 30% of process memory in my tests).

[rainers]

I cannot reproduce locally as results on a mobile processor tend to vary pretty much. From the last test here, the performance drop seems to come from the virtual call of TypeInfo.talign() to get the proper alignment. Unfortunately I've been falling into the trap that TypeInfo_Class.talign() does not provide the alignment of the instance, but only the reference. The instance alignment is nowhere to be found in the TypeInfo.

So for instances of new SomeClass, an alignment of 8 is assumed now. This keeps the memory savings, but also provides slightly better performance (~1%).

[thewilsonator]

ping when this is good

[rainers]

an alignment of 8 is assumed now.

Unfortunately on posix, real.alignof is 16, and that's used in RealExp and ComplexExp. So I added a register function for large alignments. Let's see how this performs.

[rainers]

This no longer tries to guess the alignment from the TypeInfo, but uses #23595 if the host compiler supports it. Otherwise the default alignment of 16 is used.

Expression.copy() and Type.copy() still can take advantage of lower alignment as it is passed to allocmemoryNoFree directly. That doesn't account for much memory savings, though.

ping when this is good

@thewilsonator Given that the measured compilation times are reduced by more than 1% this is ready for another review. Merging should probably better wait until after #23595.