Skip to content
Snippets Groups Projects
  1. Jun 01, 2015
  2. May 29, 2015
  3. May 22, 2015
  4. Apr 10, 2015
  5. Apr 08, 2015
  6. Apr 07, 2015
  7. Mar 30, 2015
  8. Mar 24, 2015
  9. Mar 20, 2015
  10. Mar 18, 2015
    • Erwan Jahier's avatar
      lic2soc: try a few optimisation wrt Soc.gao scheduling and test opening. · 7d0da0b8
      Erwan Jahier authored
      Indeed, in order to sort Soc.gao, I currently process in 3 stages ;
      1. compute a total ordering of Actions.t according to the deps
      2. transform Actions.t into Soc.gao (List.map)
      3. factorize Soc.gao by looking at consecutive gao that have the same guard
      
      With this change, between steps 1 and 2, I reorder the list of actions
      so that group of independent actions are sorted according to their
      clock. The idea is of course to provide to step 3 more opportunities
      of factorization.
      
      The result is not very convincing yet.
      
      I've also tried to sort the actions wrt their clock before performing
      the toposort. Seems not too bad.
      
      I've kept the old behavior by default though.
      7d0da0b8
  11. Mar 03, 2015
  12. Feb 27, 2015
  13. Feb 26, 2015
  14. Feb 24, 2015
  15. Feb 23, 2015
    • Erwan Jahier's avatar
      --2c--stack: fix a bug in code generated for array concat. · 5f3d50f1
      Erwan Jahier authored
      Now all the tests that were ok in the heap mode are also ok in the
      stack mode !
      
      However the code generated for programs that use fillred and co is weird.
      
      For instance, in should_work.pipeline.lus, in
      fillred_oneStep_pipe_10_step, accu_in is used both as an input and an
      output, which seems wrong in the stack mode as no copy is performed.
      
      Is it working by chance ?
      5f3d50f1
  16. Feb 13, 2015
    • Erwan Jahier's avatar
      --2c--stack: fix a bug in code generated for array concat. · f5802db0
      Erwan Jahier authored
      Now all the tests that were ok in the heap mode are also ok in the
      stack mode !
      
      However the code generated by fillred and co is weird.
      
      For instance, in should_work.pipeline.lus, in
      fillred_oneStep_pipe_10_step, accu_in is used both as an input and an
      output, which seems wrong in the stack mode as no copy is performed.
      
      Is it working by chance ?
      f5802db0
    • Erwan Jahier's avatar
      soc2c: fix a bug occuring when copying arrays with memcpy(). · fffd1850
      Erwan Jahier authored
      Indeed, in order to copy an array, I used to generate something like
      
         memcpy(out, in, sizeof(in));
      
      but if 'out' and 'in' are arrays, and if 'in' is an argument of a function,
      sizeof() considers it as a pointer, not an array !!!!
      
      note that if 'in' is a local var, sizeof(in) works fine.
      
      To fix it, I use the type of the dest (instead of the id) as argument of sizeof.
      
      nb : The pb never occured before, as in the heap mode only the ctx is
      passed a args of step functions.
      fffd1850
  17. Feb 12, 2015
  18. Feb 09, 2015
  19. Jan 27, 2015
  20. Jan 26, 2015
  21. Jan 22, 2015
  22. Jan 21, 2015
    • Erwan Jahier's avatar
      Check node declaration wrt safety and memory. · b29c70ff
      Erwan Jahier authored
        More precisely, a node that has memory ougth to be declared using
        "node", and using "function" otherwise.
      
        Moreover, a node that performs side-effects (i.e., if it calls an
        extern node that performs side effects) ougth to be declared as
        "unsafe".
      
        Safe/unsafe mismatches raise an error.
      
        Memory mismatches raise an error in one way (a "function" that uses
        memory), and a warning in the other way (a "node" that uses no
        memory).
      
      Also fix some errors done when transmitting the unsafe flag (well, it's
      the first time I use it!).
      b29c70ff
    • Erwan Jahier's avatar
      Fix a couple of bugs in the -oite option. · 6af23f41
      Erwan Jahier authored
      - predef Lustre op were declared as memoryful.
      - expr like "if true then ..." were badly translated
      - The clock and types of some expressions created by L2lOptimIte had
        a bad arity (in presence of tuples)
      - in order to perform the -oite optim, also check that each branch is safe.
      6af23f41
  23. Jan 20, 2015
  24. Jan 19, 2015
    • Erwan Jahier's avatar
      Add a --optimize-ite/-oite option that transforms if/then/else into merge when possible. · d783b03e
      Erwan Jahier authored
      Indeed it is possible when each branch of the ite updates no memory.
      This is done in the new L2lOptimIte module.
      
      For the time being, it does detect when the node has no memory. It
      only looks at the declaration: nodes have memory, and not functions.
      
      I should infer that information and raise warnings or errors if what
      I infer is not compatible with waht is declared (will come later).
      
      Also split ActionsDep into ActionsDep and Action.
      
      Also fix a bug in L2lsplit where deeply nested (>2) merge were not
      splitted.
      d783b03e
Loading