111
|
1 TODOs
|
|
2 -----
|
|
3
|
|
4 API
|
|
5 ===
|
|
6 * error-handling:
|
|
7 * have a client-provided error-handling callback for the context, and
|
|
8 call it, rather than asserting/crashing etc, to make the API resilient and helpful
|
|
9
|
|
10 * probably should turn off signal handlers and backtracing, leaving that to
|
|
11 the client code
|
|
12
|
|
13 * enums and ABI: give enums specific numbers, in ranges, to make it
|
|
14 possible to maintain a logical ordering whilst preserving ABI.
|
|
15
|
|
16 * expose the statements in the API? (mostly so they can be stringified?)
|
|
17
|
|
18 * support more arithmetic ops and comparison modes
|
|
19
|
|
20 * access to a function by address::
|
|
21
|
|
22 extern gcc_jit_function *
|
|
23 gcc_jit_context_get_function (ctxt,
|
|
24 void *); /* need type information */
|
|
25
|
|
26 so you can access "static" fns in your code.
|
|
27
|
|
28 * ability to turn a function into a function pointer::
|
|
29
|
|
30 gcc_jit_function_as_rvalue ()
|
|
31
|
|
32 * expressing branch probabilies (like __builtin_expect)::
|
|
33
|
|
34 extern gcc_jit_rvalue *
|
|
35 gcc_jit_rvalue_likely (gcc_jit_rvalue *rvalue,
|
|
36 int is_likely);
|
|
37
|
|
38 though would:
|
|
39
|
|
40 extern void
|
|
41 gcc_jit_block_set_likelihood (gcc_jit_block *block,
|
|
42 int hotness);
|
|
43
|
|
44 be better? (for expressing how hot the current location is)
|
|
45
|
|
46 * add a SONAME to the library (and potentially version the symbols?)
|
|
47
|
|
48 * do we need alternative forms of division (floor vs rounding)?
|
|
49
|
|
50 * are we missing any ops?
|
|
51
|
|
52 * error-checking:
|
|
53
|
|
54 * gcc_jit_context_new_unary_op: various checks needed
|
|
55
|
|
56 * gcc_jit_context_new_binary_op: various checks needed
|
|
57
|
|
58 * gcc_jit_context_new_comparison: must be numeric or pointer types
|
|
59
|
|
60 * gcc_jit_context_new_array_access: "index" must be of numeric type.
|
|
61
|
|
62 * gcc_jit_lvalue_access_field: must be field of correct struct
|
|
63
|
|
64 * gcc_jit_rvalue_access_field: must be field of correct struct
|
|
65
|
|
66 * gcc_jit_block_add_assignment_op: check the types
|
|
67
|
|
68 * Implement more kinds of casts e.g. pointers
|
|
69
|
|
70 Bugs
|
|
71 ====
|
|
72 * fixing all the state issues: make it work repeatedly with optimization
|
|
73 turned up to full.
|
|
74
|
|
75 * make the dirty dirty hacks less egregious...
|
|
76
|
|
77 * test under valgrind; fix memory leaks
|
|
78
|
|
79 * re-architect gcc so we don't have to reinitialize everything every time
|
|
80 a context is compiled
|
|
81
|
|
82 Test suite
|
|
83 ==========
|
|
84 * measure code coverage in testing of libgccjit.so
|
|
85
|
|
86 Future milestones
|
|
87 =================
|
|
88 * try porting llvmpipe to gcc
|
|
89
|
|
90 * inline assembler?
|
|
91
|
|
92 * Detect and issue warnings/errors about uses of uninitialized variables
|
|
93
|
|
94 * Warn about unused objects in a context (e.g. rvalues/lvalues)? (e.g.
|
|
95 for gcc_jit_context_new_call vs gcc_jit_block_add_eval)
|
|
96
|
|
97 Nice to have
|
|
98 ============
|
|
99 * Currently each function has a single stmt_list, which is built in
|
|
100 postprocessing by walking the list of blocks. Presumably we could
|
|
101 have each block have its own stmt_list, avoiding the need for this
|
|
102 traversal, and having the block structure show up within tree dumps.
|
|
103 Alternatively, could we skip tree and go straight to gimple?
|
|
104
|
|
105 * ability to give contexts names, for ease of debugging?
|
|
106
|
|
107
|
|
108 Probably not needed
|
|
109 ===================
|
|
110 * "switch" and "case" ?
|
|
111
|
|
112 * sizeof (should this be an API hook?) do we even need it? presumably
|
|
113 client code can just do the sizeof() in its own code.
|
|
114
|
|
115 * do we need unary plus?
|
|
116
|
|
117 etc etc
|