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	218.0 M	+0.93%
compile hello.d -O (instr)	234.5 M	236.5 M	+0.86%
compile Phobos (instr)	5,131.8 M	5,146.4 M	+0.28%
compile Phobos codegen (instr)	1,472.9 M	1,474.2 M	+0.09%
compile vibe.d (instr)	15,146.4 M	15,183.1 M	+0.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	-1.69%
peak RSS (compile Phobos)	639 MB	625 MB	-2.26%
peak RSS (compile vibe.d)	1982 MB	1937 MB	-2.24%

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