This is a list of TODOs for working on the JIT. gcc/jit/ * TODO.rst: New. --- gcc/jit/TODO.rst | 119 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 119 insertions(+) create mode 100644 gcc/jit/TODO.rst
diff --git a/gcc/jit/TODO.rst b/gcc/jit/TODO.rst new file mode 100644 index 0000000..09c4d9d --- /dev/null +++ b/gcc/jit/TODO.rst @@ -0,0 +1,119 @@ +TODOs +----- + +API +=== +* error-handling: + * have a client-provided error-handling callback for the context, and + call it, rather than asserting/crashing etc, to make the API resilient and helpful + +* probably should turn off signal handlers and backtracing, leaving that to + the client code + +* enums and ABI: give enums specific numbers, in ranges, to make it + possible to maintain a logical ordering whilst preserving ABI. + +* expose the statements in the API? (mostly so they can be stringified?) + +* support more arithmetic ops and comparison modes + +* access to a function by address:: + + extern gcc_jit_function * + gcc_jit_context_get_function (ctxt, + void *); /* need type information */ + + so you can access "static" fns in your code. + +* ability to turn a function into a function pointer:: + + gcc_jit_function_as_rvalue () + +* expressing branch probabilies (like __builtin_expect):: + + extern gcc_jit_rvalue * + gcc_jit_rvalue_likely (gcc_jit_rvalue *rvalue, + int is_likely); + + though would: + + extern void + gcc_jit_block_set_likelihood (gcc_jit_block *block, + int hotness); + + be better? (for expressing how hot the current location is) + +* add a SONAME to the library (and potentially version the symbols?) + +* do we need alternative forms of division (floor vs rounding)? + +* are we missing any ops? + +* error-checking: + + * gcc_jit_context_new_unary_op: various checks needed + + * gcc_jit_context_new_binary_op: various checks needed + + * gcc_jit_context_new_comparison: must be numeric or pointer types + + * gcc_jit_context_new_array_access: "index" must be of numeric type. + + * gcc_jit_lvalue_access_field: must be field of correct struct + + * gcc_jit_rvalue_access_field: must be field of correct struct + + * gcc_jit_block_add_assignment_op: check the types + +* Implement more kinds of casts e.g. pointers + +Bugs +==== +* fixing all the state issues: make it work repeatedly with optimization + turned up to full. + +* make the dirty dirty hacks less egregious... + +* test under valgrind; fix memory leaks + +* re-architect gcc so we don't have to reinitialize everything every time + a context is compiled + +Test suite +========== +* get DejaGnu to build and run C++ testcases + +* measure code coverage in testing of libgccjit.so + +Future milestones +================= +* try porting llvmpipe to gcc + +* inline assembler? + +* Detect and issue warnings/errors about uses of uninitialized variables + +* Warn about unused objects in a context (e.g. rvalues/lvalues)? (e.g. + for gcc_jit_context_new_call vs gcc_jit_block_add_eval) + +Nice to have +============ +* Currently each function has a single stmt_list, which is built in + postprocessing by walking the list of blocks. Presumably we could + have each block have its own stmt_list, avoiding the need for this + traversal, and having the block structure show up within tree dumps. + Alternatively, could we skip tree and go straight to gimple? + +* ability to give contexts names, for ease of debugging? + + +Probably not needed +=================== +* "switch" and "case" ? + +* sizeof (should this be an API hook?) do we even need it? presumably + client code can just do the sizeof() in its own code. + +* do we need unary plus? + +etc etc -- 1.8.5.3