IssueTracker

One design decision worth elaboring on is whether or not to rename InstIntrinsicsCall to InstIntrinsics. With InstIntrinsicsCall no longer derived from InstCall, to get rid of the Target parameter, it can never get lowered into a call (at least not a call for which the target is unknown to the backend). In high-level languages, intrinsics look like function calls, but at Subzero's IR level they look more like instructions. Hence dropping the "Call" from the name would make sense. Alternatives discussed with Antonio include:

• Keep the InstCall target operand separate from the Srcs operand list, so the goal of aligning the source operands of load/store-like intrinsics with those of regular load/store instructions is still achieved. Unfortunately this causes complications for liveness analysis, since the target operand of a regular call can be a function pointer produced by other instructions which need to be considered live. We could teach Subzero to treat the target operand as an additional source operand, but it's a bit risky and might require more than liveness analysis to be updated.
• Move the target operand to the last position of Srcs[]. This works without affecting things like liveness analysis, but is still a bit risky since we must ensure nothing looks for the target operand at index 0. It would also still be an unused undefined value for intrinsics.
• Add virtual methods for accessing load/store operands. Currently there are no virtual methods for Inst, and since we process many thousands of these it could have a performance impact to make virtual calls. Also note it already uses a Kind enum to perform its own RTTI.

It's worth noting that to LLVM, intrinsics are definitely considered functions: https://llvm.org/docs/LangRef.html#intrinsic-functions. They can even only be invoked through a call instruction. Despite Subzero's design clearly having been inspired by LLVM, it uses a separate class for representing intrinsics. InstIntrinsicCall also takes an Intrinsics::IntrinsicInfo argument at construction, whereas with LLVM that information is part of the call target.

Hence I intend on moving forward with renaming it to InstIntrinsics, and adding some comments to clarify that it represents a extension instruction which few parts of the compiler have to know the exact functionality about.