* [jit] Update TODO.rst
@ 2014-02-10 14:55 David Malcolm
0 siblings, 0 replies; 3+ messages in thread
From: David Malcolm @ 2014-02-10 14:55 UTC (permalink / raw)
To: jit, gcc-patches; +Cc: David Malcolm
Committed to branch dmalcolm/jit:
gcc/jit/
* TODO.rst: Update.
---
gcc/jit/ChangeLog.jit | 4 +++
gcc/jit/TODO.rst | 69 +++++++++++++++++++++++++++++++++++++--------------
2 files changed, 55 insertions(+), 18 deletions(-)
diff --git a/gcc/jit/ChangeLog.jit b/gcc/jit/ChangeLog.jit
index 6950b13..253f239 100644
--- a/gcc/jit/ChangeLog.jit
+++ b/gcc/jit/ChangeLog.jit
@@ -1,3 +1,7 @@
+2014-02-10 David Malcolm <dmalcolm@redhat.com>
+
+ * TODO.rst: Update.
+
2014-02-06 David Malcolm <dmalcolm@redhat.com>
* libgccjit++.h: Include <ostream> rather than <iostream>, since
diff --git a/gcc/jit/TODO.rst b/gcc/jit/TODO.rst
index 0572b78..c149dde 100644
--- a/gcc/jit/TODO.rst
+++ b/gcc/jit/TODO.rst
@@ -18,9 +18,27 @@ Initial Release
* more types:
* unions
* function ptrs
+ * explicitly opaque structs, perhaps:
-* how do you encode "x[5]=y;"? should gcc_jit_context_new_array_lookup()
- return an lvalue rather than an rvalue?
+ extern gcc_jit_type *
+ gcc_jit_context_new_opaque_struct (gcc_jit_context *ctxt,
+ const char *name);
+
+ * ability to create self-referential structs, or cycles in the graph:
+
+ struct foo { struct bar *m_bar; }
+ struct bar { struct foo *m_foo; }
+
+ * get int type with given number of either bits or bytes:
+
+ extern gcc_jit_type *
+ gcc_jit_context_get_int_type (gcc_jit_context *ctxt,
+ int num_bytes,
+ int is_signed);
+
+ * ability to bind a pre-existing global variable
+
+* expose the statements in the API? (mostly so they can be stringified?)
* explicit casts::
@@ -53,13 +71,6 @@ Initial Release
and, indeed, clarify all of the other operations.
-* 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 *
@@ -74,22 +85,16 @@ Initial Release
be better? (for expressing how hot the current location is)
+* ability to give contexts names, for ease of debugging?
+
* can we call into GCC builtins? What might people need?
* docs
-* fixing all the state issues
-
-* make the dirty dirty hacks less egregious...
-
-* pkgconfig .pc file
-
* add a SONAME to the library (and potentially version the symbols?)
* add myself as maintainer
-* valgrind; fix memory leaks
-
* do we need alternative forms of division (floor vs rounding)?
* are we missing any ops?
@@ -104,7 +109,10 @@ Initial Release
* gcc_jit_context_new_rvalue_from_int: must be a numeric type
- * gcc_jit_context_zero: must be a numeric type
+ * gcc_jit_context_zero: must be a numeric type. If we do this should
+ we introduce a gcc_jit_context_null for pointer types? (you can do
+ this via gcc_jit_context_new_rvalue_from_ptr, but having an explicit
+ hook is friendlier).
* gcc_jit_context_one: must be a numeric type
@@ -133,10 +141,35 @@ Initial Release
* gcc_jit_loop_end: verify that loops are validly nested?
+Bugs
+====
+* INTERNAL functions don't seem to work (see e.g. test-quadratic, on trying
+ to make calc_disc be internal leads to:
+ /tmp/libgccjit-4FZm6B/fake.so: undefined symbol: calc_discriminant
+ works at -O3 (because it inlines away the call); fails at -O0
+
+* fixing all the state issues: make it work repeatedly with optimization
+ turned up to full.
+
+* make the dirty dirty hacks less egregious...
+
+* pkgconfig .pc file
+
+* 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
+* add a multi-threaded test (perhaps based on test-combination.c, with a
+ thread pool working through multiple instances of the various underlying
+ tests, each thread having a separate gcc_jit_context)
+
+* verify that nested loops work OK
+
Future milestones
=================
* try porting llvmpipe to gcc
--
1.7.11.7
^ permalink raw reply [flat|nested] 3+ messages in thread
* [jit] Update TODO.rst
@ 2014-09-23 18:33 David Malcolm
0 siblings, 0 replies; 3+ messages in thread
From: David Malcolm @ 2014-09-23 18:33 UTC (permalink / raw)
To: jit, gcc-patches; +Cc: David Malcolm
Committed to branch dmalcolm/jit:
gcc/jit/ChangeLog.jit:
* TODO.rst: Rename "Initial Release" section to "API", and
remove completed items: builtins, docs, pkgconfig file, fuzz
testing. Move ability to name contexts and stmt_list per block
ideas to a new "Nice to have" section and note that it might be
better to go straight to gimple.
Move code coverage to "Test suite" section.
Add a "Probably not needed" section, moving some items to it.
Note that we're still missing shift operators.
Add idea that we could warn about unused objects in a context.
---
gcc/jit/ChangeLog.jit | 12 ++++++++++++
gcc/jit/TODO.rst | 46 ++++++++++++++++++++++++----------------------
2 files changed, 36 insertions(+), 22 deletions(-)
diff --git a/gcc/jit/ChangeLog.jit b/gcc/jit/ChangeLog.jit
index 279050b..1f408b3 100644
--- a/gcc/jit/ChangeLog.jit
+++ b/gcc/jit/ChangeLog.jit
@@ -1,5 +1,17 @@
2014-09-23 David Malcolm <dmalcolm@redhat.com>
+ * TODO.rst: Rename "Initial Release" section to "API", and
+ remove completed items: builtins, docs, pkgconfig file, fuzz
+ testing. Move ability to name contexts and stmt_list per block
+ ideas to a new "Nice to have" section and note that it might be
+ better to go straight to gimple.
+ Move code coverage to "Test suite" section.
+ Add a "Probably not needed" section, moving some items to it.
+ Note that we're still missing shift operators.
+ Add idea that we could warn about unused objects in a context.
+
+2014-09-23 David Malcolm <dmalcolm@redhat.com>
+
* docs/examples/tut03-toyvm/toyvm.c: Include <dejagnu.h>.
Add missing typedef of compilation_state.
(toyvm_function_parse): Add "name param.
diff --git a/gcc/jit/TODO.rst b/gcc/jit/TODO.rst
index 4aea38c..086d084 100644
--- a/gcc/jit/TODO.rst
+++ b/gcc/jit/TODO.rst
@@ -1,8 +1,8 @@
TODOs
-----
-Initial Release
-===============
+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
@@ -49,18 +49,14 @@ Initial Release
be better? (for expressing how hot the current location is)
-* ability to give contexts names, for ease of debugging?
-
-* can we call into GCC builtins? What might people need?
-
-* docs
-
* 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?
+ * shift operators
+
* error-checking:
* gcc_jit_context_new_unary_op: various checks needed
@@ -77,11 +73,6 @@ Initial Release
* gcc_jit_block_add_assignment_op: check the types
-* 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.
-
* Implement more kinds of casts e.g. pointers
Bugs
@@ -91,8 +82,6 @@ Bugs
* make the dirty dirty hacks less egregious...
-* pkgconfig .pc file
-
* test under valgrind; fix memory leaks
* re-architect gcc so we don't have to reinitialize everything every time
@@ -102,23 +91,36 @@ 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
-* fuzz testing
-
* inline assembler?
-* measure code coverage in testing of libgccjit.so
+* Detect and issue warnings/errors about uses of uninitialized variables
-* "switch" and "case" ?
+* Warn about unused objects in a context (e.g. rvalues/lvalues)?
-* Detect and issue warnings/errors about uses of uninitialized variables
+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" ?
-* do we need unary plus?
-* shift operators?
* 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.7.11.7
^ permalink raw reply [flat|nested] 3+ messages in thread
* [jit] Update TODO.rst
@ 2013-10-18 3:57 David Malcolm
0 siblings, 0 replies; 3+ messages in thread
From: David Malcolm @ 2013-10-18 3:57 UTC (permalink / raw)
To: gcc-patches, jit; +Cc: David Malcolm
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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2014-09-23 18:33 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-02-10 14:55 [jit] Update TODO.rst David Malcolm
-- strict thread matches above, loose matches on Subject: below --
2014-09-23 18:33 David Malcolm
2013-10-18 3:57 David Malcolm
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).