periscop/openscop

A Specification and a Library for Data Exchange in Polyhedral Compilation Tools

openscop's Issues

autoconf failure at version 0.9.6

This is with autoconf 2.71 on a Fedora 38 and with the git tip. It looks like you have an error in your m4 macros somewhere.

commit a1c6c2c7ed7ebc3babdb0584b7f61198ce481e47 (HEAD, origin/master, origin/HEAD)
Author: Harenome Ranaivoarivony-Razanajato <[email protected]>
Date:   Thu Jun 15 10:48:30 2023 +0200

    bump version 0.9.6

./autogen.sh 
autoreconf: export WARNINGS=
autoreconf: Entering directory '.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal -I m4
autoreconf: configure.ac: tracing
autoreconf: running: libtoolize --copy
autoreconf: configure.ac: not using Intltool
autoreconf: configure.ac: not using Gtkdoc
autoreconf: running: aclocal -I m4
autoreconf: running: /usr/bin/autoconf
configure:13751: error: possibly undefined macro: _AC_LANG_ABBREV
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.
configure:13752: error: possibly undefined macro: m4_default
autoreconf: error: /usr/bin/autoconf failed with exit status: 1

Attached configure that was generated before it failed. (configure renamed as configure.txt to allow upload)

Running it a second time makes the issue disappear, but running ./configure:

checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking for doxygen... doxygen
checking for texi2pdf... no
checking for C compiler vendor... gnu
./configure: line 13197: syntax error near unexpected token `$xlc_opt,'
[configure.txt](https://github.com/periscop/openscop/files/11782357/configure.txt)

./configure: line 13197: `         AX_CHECK_COMPILE_FLAG($xlc_opt,

Move beta-related functionality from Clay to OSL

A significant amount of theoretical work on polyhedral tools is written in terms of beta-prefixes and beta-vectors, while the only tool that seems to have this concept implemented is Clay. It seems reasonable for me to introduce an entity osl_beta and move multiple clay_beta_* functions to OSL so that other tools can use it. For example, finding a statement by its beta is rather useful functionality. For example, Candl expects statements sorted by beta-vectors, but can not do it itself without duplicating Clay functionality. Beta is a scop-related notion, rather than Clay-specific. Introducing more functionality to osl may make it heavier, but I don't think it will make reading/writing any slower since betas are extracted from osl_* structures upon request.

build warnings

I see the appended warnings when building with gcc 8.3.1.

$ gcc --version
gcc (GCC) 8.3.1 20190223 (Red Hat 8.3.1-2)
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

CC source/extensions/libosl_la-loop.lo
source/extensions/irregular.c: In function ‘osl_irregular_sprint’:
source/extensions/irregular.c:177:7: warning: passing argument 1 to restrict-qualified parameter aliases with argument 3 [-Wrestrict]
sprintf(buffer, "%s%d ", buffer, irregular->nb_predicates[i]);
^~~~~~~
source/extensions/irregular.c:179:9: warning: passing argument 1 to restrict-qualified parameter aliases with argument 3 [-Wrestrict]
sprintf(buffer, "%s%d ", buffer, irregular->predicates[i][j]);
^~~~~~~
source/extensions/irregular.c:181:7: warning: passing argument 1 to restrict-qualified parameter aliases with argument 3 [-Wrestrict]
sprintf(buffer, "%s\n", buffer);
^~~~~~~
source/extensions/irregular.c:185:5: warning: passing argument 1 to restrict-qualified parameter aliases with argument 3 [-Wrestrict]
sprintf(buffer, "%s%d\n", buffer, irregular->nb_control);
^~~~~~~
source/extensions/irregular.c:186:5: warning: passing argument 1 to restrict-qualified parameter aliases with argument 3 [-Wrestrict]
sprintf(buffer, "%s%d\n", buffer, irregular->nb_exit);
^~~~~~~
source/extensions/irregular.c:188:7: warning: passing argument 1 to restrict-qualified parameter aliases with argument 3 [-Wrestrict]
sprintf(buffer, "%s%d ", buffer, irregular->nb_iterators[i]);
^~~~~~~
source/extensions/irregular.c:190:9: warning: passing argument 1 to restrict-qualified parameter aliases with argument 3 [-Wrestrict]
sprintf(buffer, "%s%s ", buffer, irregular->iterators[i][j]);
^~~~~~~
source/extensions/irregular.c:191:7: warning: passing argument 1 to restrict-qualified parameter aliases with argument 3 [-Wrestrict]
sprintf(buffer, "%s\n%s\n", buffer, irregular->body[i]);
^~~~~~~
source/extensions/irregular.c:196:41: warning: passing argument 1 to restrict-qualified parameter aliases with argument 3 [-Wrestrict]
irregular->nb_control + i]);
^~~~~~~~~
source/extensions/irregular.c:199:43: warning: passing argument 1 to restrict-qualified parameter aliases with argument 3 [-Wrestrict]
irregular->nb_control+i][j]);
^~~~~~~~~
source/extensions/irregular.c:201:43: warning: passing argument 1 to restrict-qualified parameter aliases with argument 3 [-Wrestrict]
irregular->nb_control + i]);

compiler build warning

With GCC 8.3.1 and -Wextra, I see the following warning with the current master tip 39396a0

source/relation.c: In function ‘osl_relation_interface’:
source/relation.c:3010:23: warning: cast between incompatible function types from ‘struct osl_relation * ()(int, int)’ to ‘void * ()(void)’ [-Wcast-function-type]
interface->malloc = (osl_malloc_f)osl_relation_malloc;
^
CC source/libosl_la-vector.lo

Make install ignores $PREFIX

The Makefile script doesn't use $PREFIX when I use make install, instead, it tries to install on /usr/local/.

It seems it can be fixed changing ac_default_prefix in configure to ${PREFIX:-/usr/local}.

osl_generic_count / osl_generic_number duplicate

These two functions do exactly the same thing. On the linguistic basis, I prefer 'number' to 'count'. Any objections?

Member "next" in "osl_scop" struct: wrong doxygen comment

The doxygen comment of member "next" in "osl_scop" struct, file "include/osl/scop.h.in", line 107 is:

• Next statement in the linked list
  It should be (?):
• Next scop in the linked list (+ multiscop description)

Potential leak on scop extraction failure

With commit: 39396a0

Whenever I see clan_scop_extract failing (i.e., the return scop is NULL or scop->statement is NULL), I see a memory leak; here's the trace from valgrind:

==7501== 136 (128 direct, 8 indirect) bytes in 4 blocks are definitely lost in loss record 44 of 52
==7501== at 0x483880B: malloc (vg_replace_malloc.c:309)
==7501== by 0x482A1D: clan_symbol_malloc (symbol.c:198)
==7501== by 0x482EDF: clan_symbol_clone_one (symbol.c:514)
==7501== by 0x483081: clan_symbol_new_iterator (symbol.c:596)
==7501== by 0x47E461: yyparse (parser.y:627)
==7501== by 0x4801F4: clan_parse (parser.y:2430)
==7501== by 0x40C16E: main (main.c:553)

osl_strings_generate input - char * -> const char *

openscop/source/strings.c

Line 476 in 39396a0

osl_strings_p osl_strings_generate(char * prefix, int nb_strings) {

Could these be changed to take 'const char *' instead of 'char *'? Otherwise, these lead to compiler warnings when being used from C++.

warning: ISO C++ forbids converting a string constant to ‘char*’ [-Wwrite-strings]
osl_strings_p newnames = osl_strings_generate("t", nb_scatt);

Similar changes will be needed for other API functions.

Loop extension incompatible with scattering unions?

Loop extension uses consecutive integers to identify loops. Any other part of the SCoP does not feature any information about loops, which only appear at a code generation stage. Semantically, loop information should not belong to the polyhedral description.

Having a scattering union with two parts may result in a statement occurring in multiple loop nests.
For example, scheduling

for (i = 0; i < N; i++)
  for (j = 0; j < M; j++)
    S[i+j] += 1;

with

SCATTERING                                                                                                                                            
# Union with 2 parts                                                                                                                                  
2                                                                                                                                                     
# Union part No.1                                                                                                                                     
6 10 5 2 0 1                                                                                                                                          
# e/i| c1   c2   c3   c4   c5 |  i    j |  N |  1                                                                                                     
   0   -1    0    0    0    0    0    0    0    1    ## c1 == 1                                                                                       
   0    0   -1    0    1    0    1    0    0    0    ## -c2+c4+i == 0                                                                                 
   0    0    0   -1    0    0    0    0    0    0    ## c3 == 0                                                                                       
   0    0    0    0   -1    0    0    1    0    0    ## c4 == j                                                                                       
   0    0    0    0    0   -1    0    0    0    0    ## c5 == 0                                                                                       
   1    0    1    0   -1    0    0    0    0   -5    ## c2-c4-5 >= 0                                                                                  
# Union part No.2                                                                                                                                     
6 10 5 2 0 1                                                                                                                                          
# e/i| c1   c2   c3   c4   c5 |  i    j |  N |  1                                                                                                     
   0   -1    0    0    0    0    0    0    0    0    ## c1 == 0                                                                                       
   0    0   -1    0    0    0    1    0    0    0    ## c2 == i                                                                                       
   0    0    0   -1    0    0    0    0    0    0    ## c3 == 0                                                                                       
   0    0    0    0   -1    0    0    1    0    0    ## c4 == j                                                                                       
   0    0    0    0    0   -1    0    0    0    0    ## c5 == 0                                                                                       
   1    0   -1    0    0    0    0    0    0    4    ## -c2+4 >= 0

results in two distinct loops due to different beta-vectors.

But the loop extension (and, apparently, internal loop processing in Candl and CLooG) assumes a statement can only be nested in a single loop nest. This becomes problematic when introducing parallelism. In this example, for the first statement occurrence (beta-vector [0,0,0]), the inner loop is parallel and the outer is not while, for the second statement occurrence (beta-vector [1,0,0]), the outer loop is parallel and the inner is not. Yet the loop extension does not allow to express this, nor does it address any of the generated loop nests separately. Declaring the inner loop parallel for the first statement occurrence will automatically make the inner loop parallel for the second occurrence, which is wrong.

Possible solutions:

1. conservative approach -- tools that generate the loop extension should consider all possible loop nests surrounding the statement given its scattering union and disable parallelism when at least one of the loops at the same depth carries dependence;
2. change loop extension to use beta-prefixes -- they are uniquely identifying the loop even in presence of scattering unions;
3. get rid of the loop extension -- add semantics information to each dimension of each relation in the union, one of possible semantics being parallelism.

Pros and cons of these solutions:

1. loses granularity and does not allow to communicate some kinds of parallelism; does not require to modify existing tools that introduce the loop extension but no scattering unions;
2. introduces the knowledge of beta-prefixes in the format, requires moving beta-related stuff from Clay to OpenScop, requires modifying existing tools so that they conform to the new format;
3. conforming to the recent papers on union-of-relations, the cleanest solution; may make the format backwards-incompatible (unless semantics is introduced as a statement-level extension and maintained throughout modifications); may require existing tool modification, but two approaches can coexist during a transition period.

Add functions for conversion of precision to scop, relations, etc.

Also to test the issue/bug list feature for github :)!