Introducing a real query API : Thanks to the reflexive nature of the EMF API, it is possible to perform simple queries on the models. In particular, the EMFUtils helper class offer the possibility to collect all instances of a particular class within the model containment tree. This feature is widely used in the codebase although it suffers from serious performance penalty (full traversal + reflexive API), and negatively impact readability. The goal of this task is to analyze the code base to find the most common recurring usage patterns of the EMFUtils class and factor them out in a specific Helper class, where these query should be implemented properly (using switches and visitors ?). Special care should be taken to external/extended classes (i.e. classes not belonging to the core Gecos EMF model).

Gcc in the loop test infrastructure : the current Gecos testing infrastructure (based on Jenkins) cannot check whether the result of a pass/flow actually preserves the semantics of the original program. A first step toward this goal would be to provide the ability to compile and execute original transformed programs and check that they provide the same results for a given data-set.

Data movement code for Tiled programs : tiling parallelizaers such as pluto target cache coherent shared memory machine where temporal and spatial reuse is managed by a hardware cache. Many embedded processors favor scratchpad memory over caches, and cannot directly benefit from the locality improvement offered by the loop tiling transformation. To take advantage of this scratchpad memory, It is therefore necessary to explicitly transfer the data-set needed to execute a tile from and back-to memory. A preliminary parallelizing flow using scratchpad was developed in the context of the ALMA and COMPA projects. It however needs to be strengthened.

Array Footprint reduction pass : the C code regenerated from scilab contains many arrays (as in the origial scilab source code). In practice, these arrays are not live during the whole program, so they may be mapped to the same location (or overlapped locations) in memory. The problem is quite similar to register allocation and has already been studied in the context of Matlab. A preliminary version of this array optimization framework is available in the ????? plugin. It uses an ILP solver to determine the memory layout with minimum footprint.

A program slicing pass (also known as function outlining). It consists of slicing-out, in the scope of a given program block, all instruction contributing to one of several results. This transformation is described in many compiler textbooks and is really missing in Gecos. It is much easier to implement on a SSA based representation.

A directive based macro-task pipelining. Some HLS tools (Vivado HLS) offer the ability to expose coarse grain pipelining in nested loops through a #pragma DATAFLOW directive (See Vivado HLS user manual for more information). It would be very useful to have a similar feature in the Gecos S2S flow (with fewer limitations).

More Black-boxes in the SCOP extractor : the user should be allowed to sandbox instructions or blocks into a virtual Scop statement. This would be allowed through a compiler directive in which dataflow/memory dependencies could be explicitly exposed. This feature could build on the slicing framework (see above).