blob: 5b244a346c88b8c29ed64b3fd1102648f9f57cf0 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
|
TODO:
- Get all run-pass and run-fail tests passing resolve
- Lots of fixes to do here
- Audit TODOs in codebase
- MIR Optimisations
- Remove variables that are just assigned from arguments
- Clean up AST
- Almost done, just a few little niggles left
- Optimise typecheck.
- Mostly done with trait resolve cleanup
## Big change TODOs
- Support MIR-only RLibs
- Defer C codegen until final binary generation?
- Dylib support (requires trans API restructure)
- Will improve disk usage for tests (can dynamically link libstd)
- Fix Span annotations
- Spans are missing on HIR items, sub-par reporting in typecheck and later
- Spans can be off by a line or two
- Refactor parse to use a consume model lexer
- Optimise optimise (and typecheck)
- Partially down with trait resolution optimisation. Needs further profiling
- Complete structed C codegen
- Upside: It'll look cool
- Unknown: Will it be faster?
- RTL/register-based SSA interrim backend
- Convert MIR into a form that can be handed over to LLVM or Cranelift (or GIMPLE)
- Use alloca-s for non-pointer/integer/borrowed locals
## Smaller changes
- Make type ascritpion its own node type
- AST and HIR
- Then remove per-node type annotations from AST
- Cache specialisation tree
- TODO: Profile to determine if this is a slow point.
- Delete HIR after MIR generation
- Problem: HIR is sometimes touched again after MIR gen
- May just be able to do the delete in the main MIR gen phase
- Split types and patterns in HIR function arguments
- Upsides:
- Less data in the serialsed .hir file
- Note: Patterns aren't actually stored in metadata
- Simpler logic post MIR generation
- Reduced use of .first/.second
- Memory usage reduction for external functions
- Downsides:
- Lots of code touched
- Extra complexity in typecheck and MIR lowering?
- Sort trait impls in a similar way to type impls
- ```c++
template<T> struct ImplGroup {
std::map<SimplePath, T> named;
std::vector<T> primitives;
std::vector<T> generic;
}
std::map<SimplePath, ImplGroup<TraitImpl>> trait_impls;
``` <!-- `-->
- Problem: Trait lookup on ivars?
- TODO: Profile a large crate again to see what the overhead of searching
trait impls is.
- Should help with widely implemented traits (e.g. Debug)
- Downside: Another SimplePath per impl cluster, plus the vector size - Not
too big but something to be aware of (7 pointers overhead plus indirection).
## Optimisations
- Argument propagation: replace assignments from `Argument(_)` if target is only
written once
- Dead assignment removal (Delete `<val> = Use(<val>)`
- Tuple destructure removal
- Spot `#1 = (...,)`, `#2 = (#1).n` where #1 is Write-once, borrow-none
- Remove useless borrows (remove write-once &T lvalues if they're never used by
value - only used via deref)
<!-- vim: ft=markdown
-->
|
