Skip to content

Commit

Permalink
more-tweaks-to-md
Browse files Browse the repository at this point in the history
  • Loading branch information
danakj committed Nov 29, 2024
1 parent 71ca1d2 commit 6bb4429
Showing 1 changed file with 23 additions and 20 deletions.
43 changes: 23 additions & 20 deletions toolchain/docs/check.md
Original file line number Diff line number Diff line change
Expand Up @@ -84,39 +84,42 @@ instruction, as described in
[sem_ir/typed_insts.h](/toolchain/sem_ir/typed_insts.h) (also see
[adding features for Check](adding_features.md#check)):

- An `InstKind kind;` member if the instruction has a `Kinds` constant making
it a shorthand for multiple individual instructions.

- A `SemIR::TypeId type_id;` member that describes the type of the instruction
is present on all instructions that produce a value. This includes namespace
instructions, which are modeled as producing a value of "namespace" type,
even though they can't be used as a first-class value in Carbon expressions.

- Up to two additional, kind-specific members, which are typically ids or
indexes derived from `IdBase`. For example `SemIR::Assign` has members
`InstId lhs_id` and `InstId rhs_id`. And `SemIR::ClassElementAccess` has an
`ElementIndex` into the fields of the class to define which field it is
accessing. See the comment in
[sem_ir/typed_insts.h](/toolchain/sem_ir/typed_insts.h) for more details.
- Up to two additional [kind-specific members](#instruction-operands). For
example `SemIR::Assign` has members `InstId lhs_id` and `InstId rhs_id`. And
`SemIR::ClassElementAccess` has an `ElementIndex` into the fields of the
class to define which field it is accessing.

Instructions are stored as type-erased `SemIR::Inst` objects, which store the
instruction kind and the (up to) four fields described above. This balances the
size of `SemIR::Inst` against the overhead of indirection. All instructions have
with them a `LocId` that tracks their source location, and is stored separately
on the `InstStore` and retrieved by `GetLocId()`.

A `SemIR::InstBlock` can represent a code block. However, it can also be created
when a series of instructions needs to be closely associated, such as a
parameter list.
A `SemIR::InstBlockId`, used to index into `SemIR::InstBlockStore`, can
represent a code block. However, it can also be created when a series of
instructions needs to be closely associated, such as a parameter list.

A `SemIR::Builtin` represents a language built-in, such as the unconstrained
facet type `type`. We will also have built-in functions which would need to form
the implementation of some library types, such as `i32`. Built-ins are in a
stable index across `SemIR` instances.
A number of instruction types in
[sem_ir/typed_insts.h](/toolchain/sem_ir/typed_insts.h) are builtin
instructions, such as `SemIR::TypeType` which represents the unconstrained facet
type `type`. We will also have built-in functions which would need to form the
implementation of some library types, such as `i32`. Built-ins have stable ids
in the `SemIR::InstStore` across `SemIR` instances.

### Instruction operands

The kind-specific members on a typed instruction struct can be of any type
listed in the `SemIR::IdKind` enumeration defined in
[sem_ir/id_kind.h](/toolchain/sem_ir/id_kind.h). The most commonly used kinds
refer to other instructions:
[sem_ir/id_kind.h](/toolchain/sem_ir/id_kind.h), typically derived from
`IdBase`. The most commonly used kinds refer to other instructions:

- `SemIR::InstId`: Refers to a specific instance of an instruction. For
example, this should be used if the operand may have side-effects or a
Expand All @@ -134,11 +137,11 @@ documentation for the ID type for more details.

### Parameters and arguments

Parameters and arguments will be stored as two `SemIR::InstBlock`s each. The
first will contain the full IR, while the second will contain references to the
last instruction for each parameter or argument. The references block will have
a size equal to the number of parameters or arguments, allowing for quick size
comparisons and indexed access.
Parameters and arguments will be stored as two blocks (referred to by
`SemIR::InstBlockId`) each. The first will contain the full IR, while the second
will contain references to the last instruction for each parameter or argument.
The references block will have a size equal to the number of parameters or
arguments, allowing for quick size comparisons and indexed access.

## SemIR textual format

Expand Down

0 comments on commit 6bb4429

Please sign in to comment.