Types of stack slots; stack components of types

[ekpyron]

[copied from matrix]
The stack information seems to assume that there is a one-to-one correspondance between high-level types and stack slots, which is not the case (e.g. calldata references for dynamic types consist of a pointer and a size - function pointers consist of an address and a selector - etc.). What we do in solc is that each type is associated with zero or more (optionally named) stack items. I.e. a calldata pointer to a dynamic array would have an offset and a length stack field. So the format should probably be more fine-grained here.
Also this information will actually be tricky for us to produce right away - we generate evm bytecode from Yul and currently only associate Yul variables to source locations in Solidity, nothing else. That is once we're in Yul we only know that a Yul variable (which ends up as a stack slot) "stems from" some source location in Solidity (like a variable there), but have lost further structure like which part of a type it is. It should be possible for us, in principle, to preserve more structure here, though. While writing this, I actually see that the componentOf part means to account for this as an extension - but I'd recommend making this the default case, i.e. not associating "program" stack slots with type-IDs, but with components of types - then we can skip the additional "unique ID for logical values" - and some types just consist of one component, but that's just fine. The decomposition into stack components could even already be part of the type description - then "program" stack items could just refer to it as a pair of (typeID, componentID).

[ekpyron]

To maybe be clearer here:
An example is dynamic calldata arrays, which, on stack, have an offset and length component.

The format currently would have them both be stack slots of type "calldata array", but assigns both of them the same "unique ID", but different "component names", in the "componentOf" part.

I, conversely, suggest to give the "calldata array type", multiple (even potentially themselves typed, see below) stack components, and then have a stack item refer to those components as (typeID, componentID).

An example of a multi-component type, in which typed components make sense, is an external function pointer, which consists of one slot that's an address (which behaves identically to the plain address type) and a selector, which has type uint32 - note that the latter is indeed valuable information, since it could also be bytes4, which would induce different alignment.
Another example are tuple types.