rework Aro type and value system to use this InternPool data structure

[andrewrk]

I was thinking about sending a patch to Aro to test pilot this idea:

https://github.com/ziglang/zig/blob/21135387fb7c2dbaf70a72f2c97341e9c1307045/src/InternArena.zig

I have a hunch that it would provide the following improvements:

• more convenient for Aro development
• more convenient for Aro API user (zig)
• improved performance, especially for a C compiler
• reduced memory usage

Would such a patch be welcome, or would you recommend against it?

[Vexu]

The type system especially is in a serious need of being redesigned but while using InternPool would give performance and memory usage improvements, it wouldn't directly solve the biggest pain point in the current system which is the complexity brought by Type.attributed and Type.typeof.

[ehaas]

In case we do end up using this I started adding features on a branch https://github.com/ehaas/arocc/blob/interned-types/src/NewType.zig

I added variable-length encoding for u64 and an encoding for slices (e.g. function parameters). Using this interned type would also make it easy to do something like clang does where the const/volatile/restrict qualifiers are stored in the top 3 bits (also one bit is reserved for "this has extended qualifiers, look for the data elsewhere", but I haven't checked to see if those are ObjC / C++ specific). That means we can only have about 2**28 unique unqualified types but that should be enough for anyone.

Would still need to figure out Attribute storage, storage for strings (if we include them in the type e.g. record field names), and of course port everything to the new system.

[andrewrk]

Does C let you put const/volatile/restrict on non pointer types? If not, it would be possible to fold these flags into the enum tag, taking up 8 enum tags for pointer rather than 1.

[ehaas]

I think it might be needed for typeof types e.g.

typeof(const int) *foo = 0;