codegen: don't use PSym for locals

[zerbina]

Summary

Use a dedicated intermediate representation for local var/let,
parameters, and the result variable in the code generator IR.

This is the first step towards removing all PSym usage from the
backend/code-generators. The goal is to further decouple sem from the
code generators, making it possible evolve both (especially their IRs)
more independently from each other.

Details

General design

• cgir.Local stores all relevant information about a local
• the information about all locals is owned by and stored as part of
  Body
• a local is referenced from the CgNode IR via the cnkLocal node,
  which stores a LocalId value
• the result variable and parameters are also treated as locals.
  In most cases, they don't require any extra handling, so them having
  their own data types and node kinds would only complicate things
• for simplicity, for the Body of a procedure, the first local slot is
  always reserved for the result variable, even if the procedure has no
  return type. At least for now, this approach makes it easier to
  ad-hoc compute the IDs for parameters from just their position, which
  is still needed in some cases

In terms of data representation, a Local stores the type, alignment,
flags (currently still TSymFlags), and the name (which may be unset).
Unlike the MIR, no special distinction is made between temporaries and
user-defined locals.

In addition, Local also stores whether the corresponding user-defined
local is immutable (the isImmutable field). This additional
information is meant to help the code generators optimize: for example,
the JavaScript code generator doesn't use indirection for let locals,
even if they have their address taken.

For extending the data about locals, each code generator uses an
OrdinalSeq[LocalId, T] where T is a data type tailored to the needs
of the respective code generator. This data-oriented design allows for
easy extension without having to modify the base IR itself.

Overview of the changes

All places where cnkSym nodes were previously handled are adjusted to
also handle cnkLocal nodes. This usually means moving the local/
parameter/result specific handling to a new cnkLocal branch.

Merging two bodies (cgir.merge) also has to take locals into account:
the list with the locals from the source body is appended to that of the
destination body, and the cnkLocal node in the merged source body are
updated.

The code generators (cgen and jsgen) that support incremental code-
generation for procedures need to synchronize their OrdinalSeq with
the body's Store, after a partial procedure was updated. For this
purpose, the relevant code generators are extended with the genPartial
procedure.

Changes to CgNode rendering

• in order to properly render locals, cgirutils.render now requires a
  Body instead of only a CgNode
• the name disambiguation logic is generalized to support disambiguating
  the names of PSym- and Local-based symbols (through use of the new
  internal Symbol type)

In the output, compiler-inserted locals are now rendered as
:aux_$LocalId (auxiliary local) instead of :tmp_$id. The
--expandArc-using tests are adjusted accordingly.

Initialization of Locals

The setup of the Local data for a Body happens in cgirgen:

• locals reach cgirgen as PSyms, meaning that they need to be
  translated. When appearing in 'def's, the symbol of a local is
  translated to a Local, a LocalId is allocated, and a mapping
  between the PSym and LocalId is established (via the localsMap)
• for procedures, generateIR is responsible for setting up the
  Locals representing the result variable and parameters
• special handling is required for except T as e, where T is an
  imported exception type: these also act as definitions of new locals

Creating or translating temporaries no longer requires creating new
PSyms, which also means that there's one less source of IdGenerator
interaction in cgirgen. The IdGenerators should ideally be sealed at
the end of semantic analysis, and this is a step towardst this goal.

C code-generator changes

• instead of in a SymbolMap, the TLoc for locals is stored in
  an OrdinalSeq
• the special handling to account for definitions of locals being
  visited multiple times for .inline procedures becomes obsolete and
  is removed
• cnkLocal nodes cannot appear in construction expressions, and
  they thus don't need special handling in hashTree
• testing whether a local location is uninitialized no longer relies on
  TSym.locId; inspect the TLoc.k value is enough (locEmpty
  signals an empty/uninitialized location)
• for detecting parameters, reifiedOpenArray now requires access to
  a BProc instance
• for detecting parameters, the mapTypeChooser template accepting a
  CgNode also requires access to a BProc instance
• the dispatching based on the specific symbol kind (skParam,
  skTemp, skResult, etc.) becomes obsolete and is removed
• the parameter and result variable setup in cgen.startProc is
  adjusted
• the separate handling of parameters when writing NDI files is
  removed; parameters are part of the locals now
• checking for skTemp symbols when writing NDI files is also not
  necessary anymore: it is replaced with checking whether the local has
  both a user-provided and mangled name.

Name mangling for locals with user-provided names stays the same, but
for locals without user-defined names, an underscore (_) plus the
stringified integer value of the LocalId is now used. Within a
single procedure, this simple mangling guarantees unique identifiers.

Because parameters cannot easily be distinguished from other locals,
compat.isLvalue now always treats them as l-values. This only affects
the code generated (without impacting observable behaviour) for object
up- and down-conversion.

JS code-generator changes

• the new Loc type represents the code-generator's state for a local.
  It is made up of the mangled name and the location's storage
  description
• in order to free up the name, the locals field in TProc is renamed
  to defs
• Loc is intended to be eventually used for globals and constants too
• computing the storage mode once (StorageFlags) and then storing the
  result in Loc is simpler than storing the symbol flags and kind and
  recomputing the storage mode on each query
• Locs for locals are initialized (via setupLocalLoc) when a
  definition statement is encountered: these are currently 'def' nodes
  and 'except' branches for imported exceptions
• since storage relies on this information, a symbol kind has to be
  passed to setupLocalLoc
• genSymAddr is restructured into the generic addrLoc, which works
  with both Loc and PSym
• the core part of genSym is extracted into the generic accessLoc,
  which works with both Loc and PSym
• the interface of genVarInit is adjusted to work for both Loc and
  PSym

Once Loc is used for all location in the JS code generator, the
compatibility and adapter routines can be removed.

VM code-generator changes

• the new LocalLoc type represents the code-generator's state for a
  local. The type replaces the symbol-id-to-register table (locals)
  and the addressTaken set
• parameter setup (genParams) becomes simpler: no special handling
  for the result variable and environment parameter is needed anymore
• genSymAsgn is split into genAsgnToLocal and genAsgnToGlobal
• to reduce the amount of required changes, genSym and genSymAddr
  still support locals for now. This should be cleaned up separately

[mrgaturus]

In the output, compiler-inserted temporaries are now rendered as
:local_$LocalId instead of :tmp$id. The --expandArc-using tests
are adjusted accordingly.

i would prefer :tmp_$LocalId because :tmp has sightly better readability than :local when there are many locals and also may be more specific because those locals are temporal helpers to defined locals before arc expand

i like the idea of _$LocalID postfix because is useful to locate between all expanded sections

[zerbina]

i would prefer :tmp_$LocalId because :tmp has sightly better readability than :local when there are many locals and also may be more specific because those locals are temporal helpers to defined locals before arc expand

I'm not set on using the :local_ prefix, but :tmp would, in my opinion, be wrong. A local without a user-provided name is not necessarily a temporary variable. :tmp being used previously was more of a misnomer.

For better readability, only using _$LocalId, like how cgen renders them, could be a good alternative.

[saem]

Few minor items that you might want to change; otherwise good to go. Decoupling is going to be a big win.

Admittedly, I did struggle thinking through the broader logical changes, but that's 100% my struggle with focusing these past few days.

[saem]

Suggested change

	func synchronize*[I; A; B](x: var OrdinalSeq[I, A], s: Store[I, B]) =
	func rightSize*[I; A; B](x: var OrdinalSeq[I, A], s: Store[I, B]) =

I think this is slightly more indicative of the change in size and its destructive nature.

[zerbina]

Hm, maybe I'm misunderstanding, but I don't think it's a destructive operation. s must be larger than or equal in size to x, so no existing elements are destroyed/cut off.

[saem]

jeez, i seriously misread it.

rightSize might still fit, but up to you.

[zerbina]

I think I'll stay with synchronize for now. To me, rightSize sounds like a query rather than a modification.

[mrgaturus]

For better readability, only using _$LocalId, like how cgen renders them, could be a good alternative.

what about :aux_$LocalId?, i think "auxiliar" is a better meaning about what those locals do

[zerbina]

what about :aux_$LocalId?, i think "auxiliar" is a better meaning about what those locals do

I like it!

[zerbina]

/merge

Thank you for the review, @seam, and thank you for the aux suggestion, @mrgaturus.

[github-actions]

Merge requested by: @zerbina

Contents after the first section break of the PR description has been removed and preserved below:

---

Notes for Reviewers

• builds upon internal: split vmgen/linker state from TCtx #843, internal: prepare for code generator improvements #852, internal: make NDI mappings independent from PSym #906
• I'm incrementally replacing PSym usage over multiple PRs, as this makes it easier to test and review each step