mirror of
https://github.com/grin-compiler/grin.git
synced 2024-08-17 09:50:43 +03:00
add misc notes
This commit is contained in:
parent
8f915f15f9
commit
bba5da1a17
43
debug_tooling
Normal file
43
debug_tooling
Normal file
@ -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
|
44
grin/src/node_support.todo
Normal file
44
grin/src/node_support.todo
Normal file
@ -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)
|
47
grin/src/todo.micro
Normal file
47
grin/src/todo.micro
Normal file
@ -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)
|
37
node_visualization
Normal file
37
node_visualization
Normal file
@ -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
|
194
todo.just-to-practice
Normal file
194
todo.just-to-practice
Normal file
@ -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
|
Loading…
Reference in New Issue
Block a user