This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[jit] Update TODO.rst


I've committed this to dmalcolm/jit:

gcc/jit/
	* TODO.rst: Update.
---
 gcc/jit/ChangeLog.jit |   4 ++
 gcc/jit/TODO.rst      | 116 ++++++++++++++++++++++++++++++++++++++++++++++++--
 2 files changed, 117 insertions(+), 3 deletions(-)

diff --git a/gcc/jit/ChangeLog.jit b/gcc/jit/ChangeLog.jit
index 54953b6..162c3de 100644
--- a/gcc/jit/ChangeLog.jit
+++ b/gcc/jit/ChangeLog.jit
@@ -1,3 +1,7 @@
+2013-10-17  David Malcolm  <dmalcolm@redhat.com>
+
+	* TODO.rst: Update.
+
 2013-10-16  David Malcolm  <dmalcolm@redhat.com>
 
 	* TODO.rst (gcc_jit_context_new_local): Remove completed item.
diff --git a/gcc/jit/TODO.rst b/gcc/jit/TODO.rst
index d750b2a..f126fcc 100644
--- a/gcc/jit/TODO.rst
+++ b/gcc/jit/TODO.rst
@@ -1,25 +1,135 @@
-TODOs:
+TODOs
+-----
 
+Initial Release
+===============
 * 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
 
+* segfault seen in libbacktrace, when an ICE occurs
+
+* 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.
+
 * more language features:
 
   * more types:
     * unions
     * function ptrs
 
+* how do you encode "x[5]=y;"?  should gcc_jit_context_new_array_lookup()
+  return an lvalue rather than an rvalue?
+
+* separate out "x->field" from "x.field":
+    (x.field) = ...;   : (lvalue, str) -> lvalue
+    ... = (x.field);   : (rvalue, str) -> rvalue
+    (x->field) = ...;  : (lvalue, str) -> lvalue
+    ... = (x->field);  : (rvalue, str) -> rvalue
+
+* explicit dereferencing::
+
+    extern gcc_jit_lvalue *
+    gcc_jit_rvalue_dereference (gcc_jit_rvalue *);
+
+  for e.g. *ptr = 42;
+
+* explicit casts::
+
+    extern gcc_jit_rvalue *
+    gcc_jit_rvalue_cast (gcc_jit_rvalue *, gcc_jit_type *);
+
+  e.g. (void*) to (struct foo*)
+
+* access to more primitive types::
+
+    enum gcc_jit_types {
+       GCC_JIT_TYPE_SIGNED_INT,
+       // etc
+    };
+
+    extern gcc_jit_type *
+    gcc_jit_context_get_type (gcc_jit_context *,
+                              enum gcc_jit_types type);
+
+* 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 call an rvalue function pointer, perhaps keeping the
+  existing API to avoid needing to build a function ptr from a
+  function.
+
+* ability to turn a function into a function pointer::
+
+    gcc_jit_function_as_rvalue ()
+
+* clarify gcc_jit_function_add_eval()::
+
+    (void)expression;
+
+  and, indeed, clarify all of the other operations.
+
+* the C unary prefix "&" operator::
+
+    extern gcc_jit_rvalue *
+    gcc_jit_lvalue_get_address (gcc_jit_lvalue *lvalue);
+
+* array types, in case they're needed for structs::
+
+    extern gcc_jit_type *
+    gcc_jit_context_new_array_type (gcc_jit_context *ctxt,
+                                    gcc_jit_type *type,
+                                    int num_elements);
+
+* 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_function_set_likelihood (gcc_jit_function *func,
+                                     int hotness);
+
+  be better?  (for expressing how hot the current location is)
+
+* can we call into GCC builtins?  What might people need?
+
 * docs
 
 * fixing all the state issues
 
 * make the dirty dirty hacks less egregious...
 
-* try porting llvmpipe to gcc
-
 * pkgconfig .pc file
 
 * add a SONAME to the library (and potentially version the symbols?)
 
+* add myself as maintainer
+
+* valgrind; fix memory leaks
+
+
+Future milestones
+=================
+* try porting llvmpipe to gcc
+
+* fuzz testing
+
+* inline assembler?
+
+* measure code coverage in testing of libgccjit.so
+
 etc etc
-- 
1.7.11.7


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]