Home My Page Projects Code Snippets Project Openings diderot
Summary Activity Tracker Tasks SCM

SCM Repository

[diderot] View of /branches/vis15/src/compiler/TODO
ViewVC logotype

View of /branches/vis15/src/compiler/TODO

Parent Directory Parent Directory | Revision Log Revision Log

Revision 4519 - (download) (annotate)
Mon Sep 5 17:30:22 2016 UTC (2 years, 11 months ago) by jhr
File size: 2103 byte(s)
  Working on merge: fixed global reductions to work with strand arrays
Test case failures:

ertest/test2/detiso3d: bad result
**[check visualization]**

ertest/test2/gradient2-x3: bad result
**[compare with tests/synthetic/grad_inner_d2]**

High-priority things to fix:

Support for spatial queries:
  - parallel version

Support for global reductions
  - parallel version
  - fusion
  - variance

code generation for const variables

running start methods in parallel target

Medium-priority things to fix:

Mechanism to dump basis library for documentation purposes

Improve parallel runtime in various ways:
  1) pre-allocate workers into a worker pool
  2) more efficient barrier sync and spin locks

Apply value numbering to globals to eliminate redundancy (e.g., inside3 test).

Support vector arguments to user functions and strand-creation

Bad propagation of error type leads to an extra error message
Also, when overloading fails, we should print a list of candidates
(see bug008.diderot).

Better naming of meta variables in types when printing error messages.

Code generation improvements:
  complex conditionals
  more use of vector arithmetic
  constant propagation

Allow field definitions at strand scope; to do so means that we need
to prune them away later (since fields don't have a runtime
representation).  We will also need to introduce new shadow
parameters when the field is defined in terms of a parameter.
	strand S (real r) { field#2(3)[] G = r*F; ... }

Low-priority things to fix:

Typechecker overhaul: use poly-types for basis, but mono-types for
typechecking expressions (e.g., SimpleTypes).  Use matching instead
of unification.  This approach would require passing the expected type
down into expression checking, but would allow a richer notation for
poly types (e.g., min constraints).

ViewVC Help
Powered by ViewVC 1.0.0