gcc/jit/TODO.rst

   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 * get DejaGnu to build and run C++ testcases
  85
  86 * measure code coverage in testing of libgccjit.so
  87
  88 Future milestones
  89 =================
  90 * try porting llvmpipe to gcc
  91
  92 * inline assembler?
  93
  94 * Detect and issue warnings/errors about uses of uninitialized variables
  95
  96 * Warn about unused objects in a context (e.g. rvalues/lvalues)?  (e.g.
  97   for gcc_jit_context_new_call vs gcc_jit_block_add_eval)
  98
  99 Nice to have
 100 ============
 101 * Currently each function has a single stmt_list, which is built in
 102   postprocessing by walking the list of blocks.  Presumably we could
 103   have each block have its own stmt_list, avoiding the need for this
 104   traversal, and having the block structure show up within tree dumps.
 105   Alternatively, could we skip tree and go straight to gimple?
 106
 107 * ability to give contexts names, for ease of debugging?
 108
 109
 110 Probably not needed
 111 ===================
 112 * "switch" and "case" ?
 113
 114 * sizeof (should this be an API hook?)  do we even need it? presumably
 115   client code can just do the sizeof() in its own code.
 116
 117 * do we need unary plus?
 118
 119 etc etc