github.com/amarpal/go-tools@v0.0.0-20240422043104-40142f59f616/go/ir/doc.go (about) 1 // Copyright 2013 The Go Authors. All rights reserved. 2 // Use of this source code is governed by a BSD-style 3 // license that can be found in the LICENSE file. 4 5 // Package ir defines a representation of the elements of Go programs 6 // (packages, types, functions, variables and constants) using a 7 // static single-information (SSI) form intermediate representation 8 // (IR) for the bodies of functions. 9 // 10 // THIS INTERFACE IS EXPERIMENTAL AND IS LIKELY TO CHANGE. 11 // 12 // For an introduction to SSA form, upon which SSI builds, see 13 // https://en.wikipedia.org/wiki/Static_single_assignment_form. 14 // This page provides a broader reading list: 15 // https://www.dcs.gla.ac.uk/~jsinger/ssa.html. 16 // 17 // For an introduction to SSI form, see The static single information 18 // form by C. Scott Ananian. 19 // 20 // The level of abstraction of the IR form is intentionally close to 21 // the source language to facilitate construction of source analysis 22 // tools. It is not intended for machine code generation. 23 // 24 // The simplest way to create the IR of a package is 25 // to load typed syntax trees using golang.org/x/tools/go/packages, then 26 // invoke the irutil.Packages helper function. See ExampleLoadPackages 27 // and ExampleWholeProgram for examples. 28 // The resulting ir.Program contains all the packages and their 29 // members, but IR code is not created for function bodies until a 30 // subsequent call to (*Package).Build or (*Program).Build. 31 // 32 // The builder initially builds a naive IR form in which all local 33 // variables are addresses of stack locations with explicit loads and 34 // stores. Registerization of eligible locals and φ-node insertion 35 // using dominance and dataflow are then performed as a second pass 36 // called "lifting" to improve the accuracy and performance of 37 // subsequent analyses; this pass can be skipped by setting the 38 // NaiveForm builder flag. 39 // 40 // The primary interfaces of this package are: 41 // 42 // - Member: a named member of a Go package. 43 // - Value: an expression that yields a value. 44 // - Instruction: a statement that consumes values and performs computation. 45 // - Node: a Value or Instruction (emphasizing its membership in the IR value graph) 46 // 47 // A computation that yields a result implements both the Value and 48 // Instruction interfaces. The following table shows for each 49 // concrete type which of these interfaces it implements. 50 // 51 // Value? Instruction? Member? 52 // *Alloc ✔ ✔ 53 // *BinOp ✔ ✔ 54 // *BlankStore ✔ 55 // *Builtin ✔ 56 // *Call ✔ ✔ 57 // *ChangeInterface ✔ ✔ 58 // *ChangeType ✔ ✔ 59 // *Const ✔ ✔ 60 // *Convert ✔ ✔ 61 // *DebugRef ✔ 62 // *Defer ✔ ✔ 63 // *Extract ✔ ✔ 64 // *Field ✔ ✔ 65 // *FieldAddr ✔ ✔ 66 // *FreeVar ✔ 67 // *Function ✔ ✔ (func) 68 // *Global ✔ ✔ (var) 69 // *Go ✔ ✔ 70 // *If ✔ 71 // *Index ✔ ✔ 72 // *IndexAddr ✔ ✔ 73 // *Jump ✔ 74 // *Load ✔ ✔ 75 // *MakeChan ✔ ✔ 76 // *MakeClosure ✔ ✔ 77 // *MakeInterface ✔ ✔ 78 // *MakeMap ✔ ✔ 79 // *MakeSlice ✔ ✔ 80 // *MapLookup ✔ ✔ 81 // *MapUpdate ✔ ✔ 82 // *NamedConst ✔ (const) 83 // *Next ✔ ✔ 84 // *Panic ✔ 85 // *Parameter ✔ ✔ 86 // *Phi ✔ ✔ 87 // *Range ✔ ✔ 88 // *Recv ✔ ✔ 89 // *Return ✔ 90 // *RunDefers ✔ 91 // *Select ✔ ✔ 92 // *Send ✔ ✔ 93 // *Sigma ✔ ✔ 94 // *Slice ✔ ✔ 95 // *SliceToArrayPointer ✔ ✔ 96 // *SliceToArray ✔ ✔ 97 // *Store ✔ ✔ 98 // *StringLookup ✔ ✔ 99 // *Type ✔ (type) 100 // *TypeAssert ✔ ✔ 101 // *UnOp ✔ ✔ 102 // *Unreachable ✔ 103 // 104 // Other key types in this package include: Program, Package, Function 105 // and BasicBlock. 106 // 107 // The program representation constructed by this package is fully 108 // resolved internally, i.e. it does not rely on the names of Values, 109 // Packages, Functions, Types or BasicBlocks for the correct 110 // interpretation of the program. Only the identities of objects and 111 // the topology of the IR and type graphs are semantically 112 // significant. (There is one exception: Ids, used to identify field 113 // and method names, contain strings.) Avoidance of name-based 114 // operations simplifies the implementation of subsequent passes and 115 // can make them very efficient. Many objects are nonetheless named 116 // to aid in debugging, but it is not essential that the names be 117 // either accurate or unambiguous. The public API exposes a number of 118 // name-based maps for client convenience. 119 // 120 // The ir/irutil package provides various utilities that depend only 121 // on the public API of this package. 122 // 123 // TODO(adonovan): Consider the exceptional control-flow implications 124 // of defer and recover(). 125 // 126 // TODO(adonovan): write a how-to document for all the various cases 127 // of trying to determine corresponding elements across the four 128 // domains of source locations, ast.Nodes, types.Objects, 129 // ir.Values/Instructions. 130 package ir