add misc notes

debug_tooling

@@ -0,0 +1,43 @@
+idea:
+  The runtime system collects data on demand.
+  The user can specify the focus of inspection via a query language.
+
+  The raw data is fed to the UI tool.
+  e.g. grafana or custom implementation
+
+debug trap triggers:
+  - function call
+  - release of specific resource or node
+
+debug and profiling queries:
+  - control flow traces
+
+visualize:
+  - hot spots of cfg
+  - longest reference chain
+  - longest thunk
+  - memory usage
+  - open resources
+  - longest reference loop
+
+summary:
+  collectable data X query language X visualization
+  many - connection - many
+
+
+prototype:
+  - visualize grin reference graph, with strict and lazy distinction
+
+query language?
+  graphql?
+  purescript?
+  gluon?
+  haskell?
+
+ideal query language:
+  typed + inference
+  code completion (type based)
+  very simple
+
+approach:
+  iterative, agile, free

grin/src/node_support.todo

@@ -0,0 +1,44 @@
+done - calculate node types (node layout)
+done - build llvm typemap for variables
+done - in llvm codegen track type of values
+done - introduce heap pointer
+    can be:
+      (A) global variable, handled with atomic operations
+      (B) passed as local parameter
+    decision: (B)
+
+done - read inline eval
+done - read inline apply
+done - read update specialisation
+done - read node layout calculation
+done - read tag assignement
+done - risc codegen
+done - figure out how to handle the heap and the heap pointer
+
+- read llvm alias analysis documentation
+- read llvm gc features
+
+- read llvm language reference (multiple times)
+
+- check bedrock node representation
+- check ghc llvm backend node representation
+- check jhc node representation
+
+- study how to achieve discriminative unions in llvm (e.g. node_test_reg3.ll or node_test_reg3.ll.1)
+
+QUESTION:
+  would llvm map a <8 x i1> vector to a byte?
+  can i1 be 1 bit aligned?
+
+to understand in LLVM:
+  - meta nodes; optimization and debugging related
+
+  - exception handling
+
+  - atomic operations
+
+
+node representation alternatives:
+  - (A) mega struct that contains the data payload for all constructors
+  - (B) call site allocated result on stack that is filled by the callee + attached aliasing information
+  decision: (A)

grin/src/todo.micro

@@ -0,0 +1,47 @@
+HPT + LLVM codegen
+
+LLVM types:
+ misc:
+  - void
+  - function
+  - label
+  - metadata
+
+ simple:
+  - int
+  - float
+  - vector
+  - pointer
+
+ aggregate:
+  - array
+  - struct
+
+Node layout:
+  done - pass in registers
+  done - store on heap
+
+HINT: Node in Node is not supported ; only Node pointer in Node but no node value
+
+TODO:
+  - collect tag info
+  - update specialization
+  done - tag (node type) to LLVM
+  done - pass heap pointer
+  done - return node in register
+  done - store node on heap
+
+NODE ZOO ; documented llvm examples of:
+  - node construction
+  - node return
+
+STAGE 1:
+  done - working hpt
+  done - llvm codegen from lo grin
+  done - working codegen for sum_simple and sum_opt without any hardcoded values or assumptions
+  - working simplification transformations, using hpt
+
+Big tasks for MVP:
+  - HPT IR LLVM
+  - read back heap and return value to haskell
+  - High level GRIN to LLVM (maybe similar to HPT IR LLVM)

node_visualization

@@ -0,0 +1,37 @@
+node editor:
+
+https://github.com/Ni55aN/D3-Node-Editor
+https://github.com/jagenjo/litegraph.js
+
+demo:
+  1. place nodes; save to json; parse in haskell
+  idea: reactive editing (connection between the editor and the compiler)
+
+  2. visualize compiled lambdacube pipeline
+
+high performance graph visualization:
+Sigma.js
+http://js.cytoscape.org/
+
+fancy graph visualization:
+https://d3js.org/
+https://github.com/wbkd/awesome-d3
+
+http://visjs.org/
+http://www.chartjs.org/samples/latest/
+http://graphalchemist.github.io/Alchemy/#/
+
+purescript:
+
+https://github.com/pelotom/purescript-d3
+
+
+to choose:
+
+https://constructive.co/insights/6-best-data-visualization-tools-2016-pt-1/
+https://constructive.co/insights/6-best-interactive-data-visualization-tools-2016-part-2/
+https://www.quora.com/What-is-best-for-graph-rendering-sigma-js-or-d3-js-Why
+
+current choice:
+  plotly (based on d3)
+  d3-node-editor

todo.just-to-practice

@@ -0,0 +1,194 @@
+MISSING:
+  done - case / tagged union: bind pattern variables for constant node pattern
+
+  done - CGType: Result should carry: Type + LLVMType + tagged union for T_NodeSet
+
+  done - recude the usage of getOperand to the minimum
+
+  done - case (full revisit) / calculate result type from alternatives
+      done - tagged union ; requires CG_Type
+      done - simple type  ; requires CG_Type
+
+  done - refactor switch codegen to be reusable
+
+  done - bind: pattern variables for constant node pattern
+      done - exract items from tagged union ; requires CGType
+      done - simplify code
+
+  done -  heap support in LLVMJIT
+      done - allocate heap with Foreign.Marshal.Alloc callocBytes
+      done - pass initial heap pointer to grinMain
+
+  - merge codeGenCase and codeGenTagSwitch if possible
+
+  done - heap pointer handling
+      done - add heap pointer to env
+      done - def   ; return the heap pointer ; adjust function ret type              = wrap type + insert heap pointer
+      done - app   ; extract the returning heap pointer ; adjust function ret type   = wrap type + extract heap pointer
+      done - case  ; join heap pointers from alternatives
+
+      done - store ; calculate the max location size, increase the pointer accordingly
+          REQUIREMENT: store resul must be binded to a variable ; store must not be the last operation!
+          TODO: ensure this with a simple transformation.
+
+operations for HPT result
+
+- get possible tags for variable
+- get possible tags for fetch result
+
+new value types (for HPT result)
+  - tag
+  - undefined (dependent types subsumes undefined) ; try to avoid undefined and prefer more precise type description
+  - type depend on tag variable ???
+
+LLVM codegen IDEA:
+  use
+    {Tag} -> Layout + component projection functions `prj :: Tag -> Int -> a`
+  instead of
+    Tag -> Layout
+
+LLVM codegen TODO:
+  done - calculate llvm types for all possible node set combination
+  done - value projection:
+          done - bind (var pat / cpat)
+          done - case
+
+  - llvm types
+    - Hash cons HPTResult
+    - build all possible llvm types
+    - create type projection function
+
+PRIORITIES:
+  done - working LLVM codegen for GRIN
+  - GRIN type system
+  - typed simplifications
+  - HPT improvements
+
+INSIGHT: HPT could work on typed GRIN on any source
+
+QUESTION:
+  (A) should GRIN expose the simple type groups of tagged unions?
+  or
+  (B) should GRIN stick to the concept of nodes and it's arguments and hide the register mapping of nodes?
+
+  (A)
+    pro:  visible representation, even advanced packing can be visible and explicit (many bools / bits in a byte)
+    cons: requires syntax for tagged unions with type categories
+  (B)
+    pro:  more functional programming like
+    cons: hide details
+
+  GOAL: be explicit and make everything observable
+  IDEA: implement smart data packing with typed builtin operations + packer transformations instead of smart backend
+
+  PREFERENCE: use vectorisation to map nodes to tagged unions ; instead of using dependent types
+
+HINT:
+  Due to having multiple types for node items (i.e. Int64 and Float) the node item indices must be tagged with the types.
+  The actual item index that maps a node item to a tagged union is Type x Index
+IDEA:
+  Extend CPatNode and VarPat node with type annotations:
+  VarPat:   m0 >>= \(tag; i64 a1, float a2; i64 b1) -- tag + int/float as first item + int as second item
+  CPatNode  (Ffun float x ; i64 y)
+
+  alternative syntax #1
+
+  VarPat:   m0 >>= \(tag {i64 a1, float a2} {i64 b1}) -- tag + int/float as first item + int as second item
+  CPatNode  (Ffun float x, i64 y)
+
+  alternative syntax #2 (efficient maping, the most explicit)
+
+  VarPat:   m0 >>= \(tag; i64 a1, b1; float a2)@{Ffun a2 a1, Cxx a1 b1} -- VarTagNode = tagged union content + mapping
+  CPatNode  (Ffun float x ; i64 y)
+
+  alternative syntax #3 (the minimal syntax adjustment) ; my vote
+
+  VarPat:   m0 >>= \(tag a1 b1 a2)@{Ffun a2 a1, Cxx a1 b1} -- VarTagNode = tagged union content + mapping
+  CPatNode  (Ffun x y)
+
+IDEA:
+  indexed fetch index should consist of Type x Index
+  i.e. FetchI Name (Maybe Int) (Maybe Tag)
+
+codegen improvements:
+  - vectorisation as tagged union conversion
+  - flat tagged union representation ; no struct unless it's a function call
+  - cut back codegen complexity
+      - remove full node case ; keep lit + tag
+      - remove untagged fetch/store/update ; support only tagged + indexed fetch
+  - better variable names ; keep original names as much as possible
+  - merge cases (optimised case codegen)
+  - support for product return types (without tag) ; i.e. (() 1 2.0 4u)
+  transformations:
+    - packer ; bools -> bytes, pointers -> ints
+    - explicit heap pointer introduction ; used by store arg + result
+
+primary goal: typed transformations, open the road for optimization transformations
+
+feb 14 - feb 25
+W: GRIN type system insight: prj :: Tag -> Int -> a OR prjNode :: {Node A, ..., Node Z} -> Tag -> Node Tag, prjItem :: Node Tag -> Int -> a
+T: video call with Igor ; start work on type compilation (HPTResult -> LLVM type) and node codegen
+F: ??
+S: ??
+S: ??
+M: tagged union copy
+T: evening - type theory seminar ; was good
+W: case codegen
+T: heap pointer handling ; working sum_simple.grin with llvm codegen!! :P
+F: grin type system
+S: grin type system vs tagged union vs vectorisation
+S: morning brainstorming
+M: vectorisation as conversion to tagged unions
+T: new approach: optimise high level grin ; implement some optimisations
+W: copy propagation, constant propagation, dead procedure elimination, use hylo to skip operations, dead variable elimination
+T:
+F:
+S:
+S:
+
+- linter that check all possible alternatives are handled by case alternatives
+- dead code elimination using HPTResult ; empty type is dead code i.e. {}
+sum opt optimising transformations:
+  done - evaluated case elimination
+  done - trivial case elimination
+  done - sparse case elimination
+  done - copy propagation
+  done - constant propagation
+  done - dead procedure elimination
+  done - dead variable elimination
+  done - common sub-expression elimination
+
+  - late inlining
+  - inline calls to eval
+=================================
+  - unboxing of return values
+  - arity raising
+  done - vectorisation + case simplification (skip)
+
+optimising transformations:
+  done - evaluated case elimination
+  done - trivial case elimination
+  done - sparse case elimination
+  done - update elimination
+  done - copy propagation
+  done - constant propagation
+  done - dead procedure elimination
+  done - dead variable elimination
+  done - common sub-expression elimination
+
+ medium:
+  - late inlining
+
+ complex:
+  - generalised unboxing
+  - arity raising
+
+============================
+
+ remaining (medium):
+  - dead parameter elimination
+  - case copy propagation
+  - case hoisting
+  - whnf update elimination ; requires sharing analysis
+
+IDEA: rerun HPT time to time on the transformed code during the optimisation process to get more accurate tag and type information