Commit Graph
4 Commits
Author SHA1 Message Date
Richard Smith 3776c068de Unify instruction naming between SemIR and LLVM IR (#3898)
Factor out `SemIR::InstNamer` and also use it when lowering to LLVM IR.
Automatically name all instructions created with our `IRBuilder` based
on the name computed by the `InstNamer`, and likewise name basic blocks
using the label generated by the `InstNamer`.

Move some of the existing naming logic out from lower into `InstNamer`
so that it's also used in SemIR. In particular, we now name call
instructions after their callee, or after the builtin name for calls to
builtins.

Computing and adding these names isn't completely free. This instruction
naming is designed to be optional, so that we can turn it off for builds
where the LLVM IR will only be converted to assembly and won't be seen
by a human, but so far it's enabled unconditionally. We can tune that
later as needed.
2024-04-19 02:19:30 +00:00
Richard Smith 428d11323a Directly convert from an initializer to a value where possible. (#3306)
If the initializing representation is the same as the value
representation, don't materialize a temporary and perform a value
binding. Instead, directly extract the value, using a new
`value_of_initializer` node.

This removes a lot of redundant `alloca`s from our generated LLVM IR.
2023-10-31 20:59:28 +00:00
Richard Smith 842b471e67 Perform in-place initialization for tuples and structs (#3246)
This implements initializing expression semantics for structs and
tuples, following #2006 and discussions since.

Tuple and (and analogously, struct) literals are treated as having a
mixed expression category that is later resolved based on how the
literal is used, as either a tuple initializer or a tuple value, at
which point we create a `TupleInit` or `TupleValue` that represents the
formation of the tuple initializer or tuple value from the tuple
literal.

There's quite a lot of TODOs here, and the SemIR representation is still
not quite right, but this seems like a good place to checkpoint some
incremental progress.
2023-09-20 21:20:14 +00:00
Richard Smith e81d171226 Switch to modeling array initialization analogously to a function call. (#3205)
Instead of modeling array initialization as a thin wrapper around tuple
initialization, handle it like a function call, with a return slot as
part of its input. This better matches how initialization via a call to
`ImplicitAs::Convert` will eventually work, and in particular lets us do
in-place initialization of arrays rather than always creating a
temporary.
2023-09-14 00:49:55 +00:00