Bytecode interpreter: Optimization opportunities

[tbaederr]

• When allocating a new InterpFrame, we do that as a unique_ptr, which causes a heap allocation. In the constructor, we immediately do another heap allocation for Locals. Can we do this in one allocation? Does it make sense to add an allocator for this to InterpState? Does the fact that we have a stack based allocation scheme (LIFO basically) help us at all here?
• We currently create Function instances for all builtin functions. However, we rarely use them later, since the classified argument calls, etc. don't always match what we actually have on the stack and we instead need to look at their CallExpr. Can we do without the Function instance for builtins?
• OffsetHelper in Interp.h currently pushes the new value to the stack, but some callers pop it immediately again to use the new pointer (e.g. in ArrayElemPtr, we call NarrowPtr). Stop doing that and instead return the new value.
• In Block::invokeCtor, we call memset() on the entire data of the block, and then follow it by calling the ctor function, which will overwrite the entire data again (hopefully). Remove that memset call. Simply doing that caused some problems for me in the past, so there's more to it than just that.
• We do create full Blocks for dummy pointers these days, even though we can never actually access their data. We only ever look at the InlineDescriptors we set via their CtorFn. Does it improve performance if we don't initialize the data fields of dummy blocks?
• The implementation for __builtin_bit_cast copies everything bit-by-bit into a buffer and out again. However, the majority of cases uses full byte values. We could optimize that. Probably even the target-endianness==host-endianness case.
• When copying Pointer instances (e.g. when iterating up the hierarchy of a Pointer), the pointer adds itself to the pointer chain of the block. This is often unnecessary.

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: Timm Baeder (tbaederr)

- When allocating a new `InterpFrame`, we do that as a `unique_ptr`, which causes a heap allocation. In the constructor, we immediately do another heap allocation for `Locals`. Can we do this in one allocation? Does it make sense to add an allocator for this to `InterpState`? Does the fact that we have a stack based allocation scheme (LIFO basically) help us at all here? - We currently create `Function` instances for all builtin functions. However, we rarely use them later, since the classified argument calls, etc. don't always match what we actually have on the stack and we instead _need to_ look at their `CallExpr`. Can we do without the `Function` instance for builtins? - `OffsetHelper` in `Interp.h` currently pushes the new value to the stack, but some callers pop it immediately again to use the new pointer (e.g. in `ArrayElemPtr`, we call `NarrowPtr`). Stop doing that and instead return the new value. - In `Block::invokeCtor`, we call `memset()` on the entire data of the block, and then follow it by calling the ctor function, which will overwrite the entire data again (hopefully). Remove that memset call. Simply doing that caused some problems for me in the past, so there's more to it than just that. - We do create full `Block`s for dummy pointers these days, even though we can never actually access their data. We only ever look at the `InlineDescriptors` we set via their `CtorFn`. Does it improve performance if we don't initialize the data fields of dummy blocks?