Wyvern.Instruction.Phi (wyvern v1.0.4)

Copy Markdown

Summary

Functions

Phi.new/3 validates that all incoming values share type, but does not validate that incoming's labels are actually the predecessor blocks of the block the Phi sits in (nor that every predecessor is covered exactly once).

Types

incoming()

@type incoming() :: {Wyvern.Value.t(), Wyvern.Label.t()}

t()

@type t() :: %Wyvern.Instruction.Phi{
  dest: Wyvern.Instruction.Types.destination(),
  id: reference(),
  incoming: [incoming()],
  type: Wyvern.Type.t()
}

Functions

new(dest, type, incoming)

Phi.new/3 validates that all incoming values share type, but does not validate that incoming's labels are actually the predecessor blocks of the block the Phi sits in (nor that every predecessor is covered exactly once).

Doing that requires knowing the block's actual predecessors, which means walking the whole Function's blocks list to find which blocks end in a terminator targeting this block's label. We don't have that CFG-level analysis yet so it isn't checked here. Malformed phis (wrong/missing/duplicate predecessors) will produce syntactically valid but semantically broken LLVM IR (e.g. verifier will reject it) rather than raising during construction. We'll revisit this later.