Statement-wise first and last loop depth for optimize control

[Uday K Bondhugula]

The -f and -l options that specify the first and last loop depths to
optimize control for (by separation) are global, as we know. I'm running
into more and more cases where setting these options statement-wise
improves performance of generated code significantly. Also, more the
number of statements, more likely is the need of different settings for
different statements for best performance.

Is this feature on anyone's TODO list? How easy of difficult is it to
implement? A few things.

1. There may not be a good way to provide this feature via the
command-line interface. But if it can be added in the .cloog (the unused
0 0 0 at the end of stmt domain), one won't need a library interface as
well.

2. A user may end up setting these options in a way that may not be
meaningful. For eg., if two statements have fused loops, it doesn't make
sense to ask for that loop depth to be optimized for one statement and
not for the other. But cloog can freely assume to optimize or not
optimize, and this shouldn't be a problem at all.

Overall, it'll be great to have this feature.

-Uday

[Cédric Bastoul]

Hi Uday,

you are quite right, in fact this is in an old version of my TODO list. I should put it directly in CLooG's repository, see:

https://groups.google.com/group/cloog-development/browse_thread/thread/64822083b8b380fc/d5ce099bd97aee4e?hl=en&lnk=gst&q=todo+list#d5ce099bd97aee4e

Not only we should tune the -l/-f for each input domains, but we should also integrate an automatic way during code generation, depending on which level we are, how many statements are embedded in a given generated loop, a weight provided by the user, etc. I'll try to provide such a functionality like this before the summer, or before if you are highly motivated (help is welcome !) :-). Providing the input information will not be a problem, especially from OpenScop's input which is built to support extensions.

Cedric

-Uday

--
You got this message because you subscribed to the CLooG Development mailing list.
To send messages to this list, use cloog-development@googlegroups.com
To stop subscribing, send a mail to cloog-development+unsubscribe@googlegroups.com
For more options and to visit the group, http://groups.google.fr/group/cloog-development?hl=en

[Uday K Bondhugula]

I've added this functionality. Patch is attached and pasted below as well.

Thanks,
Uday

---------------------------------------------------------------------
From 0d8928337d81cdfeac82984716c70a5b3e946cda Mon Sep 17 00:00:00 2001
From: Uday Bondhugula <uday...@gmail.com>
Date: Thu, 31 May 2012 17:38:53 +0530
Subject: [PATCH 3/3] statement-wise -f/-l options for loop separation

option->f/l (-f -l command-line args) provided first and last levels to
optimize control overhead by separating / splitting loops at a global
level. This patch allow -f/-l options to be set on a stmt-wise basis.
options->fs, options->ls arrays are provided - they should be allocated
and de-allocated by user (with 'number of statement' integer elements).
For any given loop, the first and last depths of statements under it are
looked at to determine if the loop should be separated (max across all
fs' and ls' is taken). A user has to set fs meaningfully, i.e., for eg.,
if two statements i & j have a fused loop and fs[i], fs[j] specify
separation for that level for stmt i but not for stmt j, the input is
ambiguous and we will in this case not separate (since a max is taken).
options->fs/ls override f/l; if fs/ls are not set or are set
inconsistently (max across ls[i] < max across fs[i]), f/l take over.

fs/ls can only be set via the library interface for now.

Signed-off-by: Uday Bondhugula <uday...@gmail.com>
---
include/cloog/options.h | 3 ++
source/loop.c | 68
+++++++++++++++++++++++++++++++++++++++++++---
source/options.c | 2 +
3 files changed, 68 insertions(+), 5 deletions(-)

diff --git a/include/cloog/options.h b/include/cloog/options.h
index 2233579..e4f26d2 100644
--- a/include/cloog/options.h
+++ b/include/cloog/options.h
@@ -62,6 +62,9 @@ struct cloogoptions
/* OPTIONS FOR LOOP GENERATION */
int l ; /* Last level to optimize. */
int f ; /* First level to optimize. */
+
+ int *ls; /* Last level to optimize (statement-wise). */
+ int *fs; /* First level to optimize (statement-wise). */
int stop ; /* Level to stop code generation. */
int strides ; /* 1 if user wants to handle non-unit strides (then
loop
* increment can be something else than one), 0
otherwise.
diff --git a/source/loop.c b/source/loop.c
index d93d8a7..e028809 100644
--- a/source/loop.c
+++ b/source/loop.c
@@ -1800,6 +1800,46 @@ CloogLoop *cloog_loop_recurse(CloogLoop *loop,
return res;
}

+
+/* Get the max across all 'first' depths for statements in this
+ * stmt list, and the max across all 'last' depths */
+void cloog_statement_get_fl(CloogStatement *s, int *f, int *l,
+ CloogOptions *options)
+{
+ if (s == NULL) return;
+
+ int fs, ls;
+
+ if (options->fs != NULL && options->ls != NULL) {
+ fs = options->fs[s->number-1];
+ ls = options->ls[s->number-1];
+ *f = (fs > *f)? fs: *f;
+ *l = (ls > *l)? ls: *l;
+ }else{
+ *f = -1;
+ *l = -1;
+ }
+
+ cloog_statement_get_fl(s->next, f, l, options);
+}
+
+/* Get the max across all 'first' depths for statements under
+ * this loop, and the max across all 'last' depths */
+void cloog_loop_get_fl(CloogLoop *loop, int *f, int *l,
+ CloogOptions *options)
+{
+ if (loop == NULL) return;
+
+ CloogBlock *block = loop->block;
+
+ if (block != NULL && block->statement != NULL) {
+ cloog_statement_get_fl(block->statement, f, l, options);
+ }
+
+ cloog_loop_get_fl(loop->inner, f, l, options);
+ cloog_loop_get_fl(loop->next, f, l, options);
+}
+
/**
* cloog_loop_generate_general function:
* Adaptation from LoopGen 0.4 by F. Quillere. This function
implements the
@@ -1822,6 +1862,10 @@ CloogLoop *cloog_loop_recurse(CloogLoop *loop,
* - November 15th 2005: (debug) the result of the cloog_loop_generate
call may
* be a list of polyhedra (especially if stop
option is
* used): cloog_loop_add_list instead of
cloog_loop_add.
+ * - May 31, 2012: statement-wise first and last depth for loop separation
+ * if options->fs and option->ls arrays are set, it will override
what has
+ * been supplied via "-f/-l"
+ *
*/
CloogLoop *cloog_loop_generate_general(CloogLoop *loop,
int level, int scalar, int *scaldims, int nb_scattdims,
@@ -1831,13 +1875,27 @@ CloogLoop *cloog_loop_generate_general(CloogLoop
*loop,
int separate = 0;
int constant = 0;

+ int first = -1;
+ int last = -1;
+
+ now = NULL;
+
+ /* Get the -f and -l for each statement */
+ cloog_loop_get_fl(loop, &first, &last, options);
+
+ /* If stmt-wise options are not set or set inconsistently, use
-f/-l ones globally */
+ if (first <= 0 || last < first) {
+ first = options->f;
+ last = options->l;
+ }
+
/* 3. Separate all projections into disjoint polyhedra. */
if (level > 0 && cloog_loop_is_constant(loop, level)) {
res = cloog_loop_constant(loop, level);
constant = 1;
- } else if ((options->f > level+scalar) || (options->f < 0))
+ }else if ((first > level+scalar) || (first < 0)) {
res = cloog_loop_merge(loop, level, options);
- else {
+ }else{
res = cloog_loop_separate(loop);
separate = 1;
}
@@ -1853,7 +1911,7 @@ CloogLoop *cloog_loop_generate_general(CloogLoop
*loop,
/* 4. Recurse for each loop with the current domain as context. */
temp = res ;
res = NULL ;
- if (!level || (level+scalar < options->l) || (options->l < 0))
+ if (!level || (level+scalar < last) || (last < 0))
res = cloog_loop_recurse(temp, level, scalar, scaldims, nb_scattdims,
constant, options);
else
@@ -1877,8 +1935,8 @@ CloogLoop *cloog_loop_generate_general(CloogLoop
*loop,
* for an idea.
*/
if (options->backtrack && level &&
- ((level+scalar < options->l) || (options->l < 0)) &&
- ((options->f <= level+scalar) && !(options->f < 0)))
+ ((level+scalar < last) || (last < 0)) &&
+ ((first <= level+scalar) && !(first < 0)))
res = cloog_loop_generate_backtrack(res, level, options);

/* Pray for my new paper to be accepted somewhere since the following
stuff
diff --git a/source/options.c b/source/options.c
index ca7f2fa..c50e246 100644
--- a/source/options.c
+++ b/source/options.c
@@ -316,6 +316,8 @@ CloogOptions *cloog_options_malloc(CloogState *state)
/* OPTIONS FOR LOOP GENERATION */
options->l = -1 ; /* Last level to optimize: infinity. */
options->f = 1 ; /* First level to optimize: the first. */
+ options->ls = NULL ; /* Last level to optimize (stmt-wise,
user-set) */
+ options->fs = NULL ; /* First level to optimize
(stmt-wise, user-set) */
options->stop = -1 ; /* Generate all the code. */
options->strides = 0 ; /* Generate a code with unit strides. */
options->sh = 0; /* Compute actual convex hull. */
--
1.7.4.4

> cloog-development@_googlegroups.com_
> <mailto:cloog-de...@googlegroups.com>_ To stop subscribing,
> send a mail to
> <mailto:cloog-development%2Bunsu...@googlegroups.com>_cloog-development+unsubscribe@_googlegroups.com_
>
>
<mailto:cloog-development%2Bunsu...@googlegroups.com>_

> For more options and to visit the group,

> <http://groups.google.fr/group/cloog-development?hl=en>_http://groups.google.fr/group/_cloog-development?hl=en_
>
>
<http://groups.google.fr/group/cloog-development?hl=en>__
>
> _ _ _ -- This message has been scanned for viruses and dangerous
> content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean. _

[Cédric Bastoul]

Hi Uday,

here are my remarks:

- you have also to update cloog_options_print and cloog_options_free to take care about the new fields,

- can you also update the documentation about the CloogOption structure in source/cloog.texi according to what you described in the patch documentation ?

Other general remarks we may discuss about :

- Tobi pointed me some time ago that it's better to add new fields at the end of the structure to avoid binary compatibility problems as much as possible, but I must admit it seems better for the code itself to put them after -l/-f. Note sure what to do here.
- I have a mixed feeling about the fact that the size of the ls and fs arrays is not known in the CloogOption structure, this gives me the impression that it is not self-contained, but it's much probably not a problem (if it becomes a problem we may introduce, e.g., a "final" flag as the last element of each array).

Thanks for this useful option.

Cedric

<mailto:cloog-development@googlegroups.com>_ To stop subscribing,

send a mail to
<mailto:cloog-development%2Bunsu...@googlegroups.com>_cloog-development+unsubscribe@_googlegroups.com_

<mailto:cloog-development%2Bunsu...@googlegroups.com>_

For more options and to visit the group,
<http://groups.google.fr/group/cloog-development?hl=en>_http://groups.google.fr/group/_cloog-development?hl=en_

<http://groups.google.fr/group/cloog-development?hl=en>__

_ _ _ -- This message has been scanned for viruses and dangerous

content by *MailScanner* <http://www.mailscanner.info/>, and is

believed to be clean. _

--
You got this message because you subscribed to the CLooG Development mailing list.

To send messages to this list, use cloog-development@googlegroups.com
To stop subscribing, send a mail to cloog-development+unsubscribe@googlegroups.com

[Uday K Bondhugula]

> - I have a mixed feeling about the fact that the size of the ls and
> fs arrays is not known in the CloogOption structure, this gives me
> the impression that it is not self-contained, but it's much probably
> not a problem (if it becomes a problem we may introduce, e.g., a
> "final" flag as the last element of each array).

Yes, I was uncomfortable about this as well. Since we don't know the
number of statements in CloogOptions, the best solution I could find was
to allow the user to allocate and deallocate them. So,
cloog_options_free will do nothing about fs/ls.

-Uday

On 06/01/2012 02:21 PM, C�dric Bastoul wrote:
> Hi Uday, here are my remarks: - you have also to update
> cloog_options_print and cloog_options_free to take care about the new
> fields, - can you also update the documentation about the CloogOption
> structure in source/cloog.texi according to what you described in the
> patch documentation ?
>
> Other general remarks we may discuss about : - Tobi pointed me some
> time ago that it's better to add new fields at the end of the
> structure to avoid binary compatibility problems as much as possible,
> but I must admit it seems better for the code itself to put them
> after -l/-f. Note sure what to do here. - I have a mixed feeling
> about the fact that the size of the ls and fs arrays is not known in
> the CloogOption structure, this gives me the impression that it is
> not self-contained, but it's much probably not a problem (if it
> becomes a problem we may introduce, e.g., a "final" flag as the last
> element of each array).
>
> Thanks for this useful option.
>
> Cedric
>
> On Thu, May 31, 2012 at 2:29 PM, Uday K Bondhugula
> <uday...@gmail.com <mailto:uday...@gmail.com>> wrote:
>
>
> I've added this functionality. Patch is attached and pasted below as
> well.
>
> Thanks, Uday
>

> ------------------------------__------------------------------__---------
>
>
From 0d8928337d81cdfeac82984716c70a__5b3e946cda Mon Sep 17 00:00:00

> 2001 From: Uday Bondhugula <uday...@gmail.com

> <mailto:uday...@gmail.com>> Date: Thu, 31 May 2012 17:38:53 +0530

> Subject: [PATCH 3/3] statement-wise -f/-l options for loop
> separation
>
> option->f/l (-f -l command-line args) provided first and last levels
> to optimize control overhead by separating / splitting loops at a
> global level. This patch allow -f/-l options to be set on a stmt-wise
> basis. options->fs, options->ls arrays are provided - they should be
> allocated and de-allocated by user (with 'number of statement'
> integer elements). For any given loop, the first and last depths of
> statements under it are looked at to determine if the loop should be
> separated (max across all fs' and ls' is taken). A user has to set fs
> meaningfully, i.e., for eg., if two statements i & j have a fused
> loop and fs[i], fs[j] specify separation for that level for stmt i
> but not for stmt j, the input is ambiguous and we will in this case
> not separate (since a max is taken). options->fs/ls override f/l; if
> fs/ls are not set or are set inconsistently (max across ls[i] < max
> across fs[i]), f/l take over.
>
> fs/ls can only be set via the library interface for now.
>
> Signed-off-by: Uday Bondhugula <uday...@gmail.com

> <mailto:uday...@gmail.com>> --- include/cloog/options.h | 3 ++
> source/loop.c | 68
> ++++++++++++++++++++++++++++++__+++++++++++++--- source/options.c

> | 2 + 3 files changed, 68 insertions(+), 5 deletions(-)
>
> diff --git a/include/cloog/options.h b/include/cloog/options.h index
> 2233579..e4f26d2 100644 --- a/include/cloog/options.h +++
> b/include/cloog/options.h @@ -62,6 +62,9 @@ struct cloogoptions /*
> OPTIONS FOR LOOP GENERATION */ int l ; /* Last level to
> optimize. */ int f ; /* First level to optimize. */ + +
> int *ls; /* Last level to optimize (statement-wise). */ +
> int *fs; /* First level to optimize (statement-wise). */ int
> stop ; /* Level to stop code generation. */ int strides ;
> /* 1 if user wants to handle non-unit strides (then loop * increment
> can be something else than one), 0 otherwise. diff --git
> a/source/loop.c b/source/loop.c index d93d8a7..e028809 100644 ---
> a/source/loop.c +++ b/source/loop.c @@ -1800,6 +1800,46 @@ CloogLoop
> *cloog_loop_recurse(CloogLoop *loop, return res; }
>
> + +/* Get the max across all 'first' depths for statements in this +
> * stmt list, and the max across all 'last' depths */ +void

> cloog_statement_get_fl(__CloogStatement *s, int *f, int *l, +

> CloogOptions *options) +{ + if (s == NULL) return; + + int fs,
> ls; + + if (options->fs != NULL && options->ls != NULL) { +
> fs = options->fs[s->number-1]; + ls =
> options->ls[s->number-1]; + *f = (fs > *f)? fs: *f; +
> *l = (ls > *l)? ls: *l; + }else{ + *f = -1; + *l =

> -1; + } + + cloog_statement_get_fl(s->__next, f, l, options);

> +} + +/* Get the max across all 'first' depths for statements under +
> * this loop, and the max across all 'last' depths */ +void
> cloog_loop_get_fl(CloogLoop *loop, int *f, int *l, +
> CloogOptions *options) +{ + if (loop == NULL) return; + +
> CloogBlock *block = loop->block; + + if (block != NULL &&
> block->statement != NULL) { +

> cloog_statement_get_fl(block->__statement, f, l, options); + } + +

> cloog_loop_get_fl(loop->inner, f, l, options); +
> cloog_loop_get_fl(loop->next, f, l, options); +} + /** *
> cloog_loop_generate_general function: * Adaptation from LoopGen 0.4
> by F. Quillere. This function implements the @@ -1822,6 +1862,10 @@
> CloogLoop *cloog_loop_recurse(CloogLoop *loop, * - November 15th
> 2005: (debug) the result of the cloog_loop_generate call may *
> be a list of polyhedra (especially if stop option is *
> used): cloog_loop_add_list instead of cloog_loop_add. + * - May 31,
> 2012: statement-wise first and last depth for loop separation + *
> if options->fs and option->ls arrays are set, it will override what
> has + * been supplied via "-f/-l" + * */ CloogLoop

> *cloog_loop_generate_general(__CloogLoop *loop, int level, int

> scalar, int *scaldims, int nb_scattdims, @@ -1831,13 +1875,27 @@

> CloogLoop *cloog_loop_generate_general(__CloogLoop *loop, int

> separate = 0; int constant = 0;
>
> + int first = -1; + int last = -1; + + now = NULL; + + /*
> Get the -f and -l for each statement */ + cloog_loop_get_fl(loop,
> &first, &last, options); + + /* If stmt-wise options are not set
> or set inconsistently, use -f/-l ones globally */ + if (first <= 0
> || last < first) { + first = options->f; + last =
> options->l; + }
>
> + /* 3. Separate all projections into disjoint polyhedra. */ if
> (level > 0 && cloog_loop_is_constant(loop, level)) { res =
> cloog_loop_constant(loop, level); constant = 1; - } else if
> ((options->f > level+scalar) || (options->f < 0)) + }else if
> ((first > level+scalar) || (first < 0)) {
>
> res = cloog_loop_merge(loop, level, options); - else { + }else{
>
> res = cloog_loop_separate(loop); separate = 1; } @@ -1853,7 +1911,7

> @@ CloogLoop *cloog_loop_generate_general(__CloogLoop *loop, /* 4.

> Recurse for each loop with the current domain as context. */ temp =
> res ; res = NULL ; - if (!level || (level+scalar < options->l) ||
> (options->l < 0)) + if (!level || (level+scalar < last) || (last <
> 0)) res = cloog_loop_recurse(temp, level, scalar, scaldims,
> nb_scattdims, constant, options); else @@ -1877,8 +1935,8 @@

> CloogLoop *cloog_loop_generate_general(__CloogLoop *loop, * for an

> idea. */ if (options->backtrack && level && - ((level+scalar <
> options->l) || (options->l < 0)) && - ((options->f <=
> level+scalar) && !(options->f < 0))) + ((level+scalar <
> last) || (last < 0)) && + ((first <= level+scalar) &&

> !(first < 0))) res = cloog_loop_generate_backtrack(__res, level,

> options);
>
> /* Pray for my new paper to be accepted somewhere since the
> following stuff diff --git a/source/options.c b/source/options.c
> index ca7f2fa..c50e246 100644 --- a/source/options.c +++
> b/source/options.c @@ -316,6 +316,8 @@ CloogOptions

> *cloog_options_malloc(__CloogState *state) /* OPTIONS FOR LOOP

> GENERATION */ options->l = -1 ; /* Last level to optimize:
> infinity. */ options->f = 1 ; /* First level to optimize:
> the first. */ + options->ls = NULL ; /* Last level to
> optimize (stmt-wise, user-set) */ + options->fs = NULL ;
> /* First level to optimize (stmt-wise, user-set) */ options->stop
> = -1 ; /* Generate all the code. */ options->strides = 0 ; /*
> Generate a code with unit strides. */ options->sh = 0; /*
> Compute actual convex hull. */ -- 1.7.4.4
>
>
>
>
>
>
> On 03/27/2012 02:15 PM, C�dric Bastoul wrote:
>
> Hi Uday, you are quite right, in fact this is in an old version of
> my TODO list. I should put it directly in CLooG's repository, see:

> https://groups.google.com/__group/cloog-development/__browse_thread/thread/__64822083b8b380fc/__d5ce099bd97aee4e?hl=en&lnk=__gst&q=todo+list#__d5ce099bd97aee4e
>
>
<https://groups.google.com/group/cloog-development/browse_thread/thread/64822083b8b380fc/d5ce099bd97aee4e?hl=en&lnk=gst&q=todo+list#d5ce099bd97aee4e>
>
> <https://groups.google.com/__group/cloog-development/__browse_thread/thread/__64822083b8b380fc/__d5ce099bd97aee4e?hl=en&lnk=__gst&q=todo+list#__d5ce099bd97aee4e

>
>
<https://groups.google.com/group/cloog-development/browse_thread/thread/64822083b8b380fc/d5ce099bd97aee4e?hl=en&lnk=gst&q=todo+list#d5ce099bd97aee4e>>
>
> Not only we should tune the -l/-f for each input domains, but we
> should also integrate an automatic way during code generation,
> depending on which level we are, how many statements are embedded in
> a given generated loop, a weight provided by the user, etc. I'll try
> to provide such a functionality like this before the summer, or
> before if you are highly motivated (help is welcome !) :-).
> Providing the input information will not be a problem, especially
> from OpenScop's input which is built to support extensions.
>
> Cedric
>
>
> On Wed, Mar 21, 2012 at 6:46 PM, Uday K Bondhugula
> <uday...@gmail.com <mailto:uday...@gmail.com>

> <mailto:uday...@gmail.com <mailto:uday...@gmail.com>>> wrote:
>
>
> The -f and -l options that specify the first and last loop depths to
> optimize control for (by separation) are global, as we know. I'm
> running into more and more cases where setting these options
> statement-wise improves performance of generated code significantly.
> Also, more the number of statements, more likely is the need of
> different settings for different statements for best performance.
>
> Is this feature on anyone's TODO list? How easy of difficult is it
> to implement? A few things.
>
> 1. There may not be a good way to provide this feature via the
> command-line interface. But if it can be added in the .cloog (the
> unused 0 0 0 at the end of stmt domain), one won't need a library
> interface as well.
>
> 2. A user may end up setting these options in a way that may not be
> meaningful. For eg., if two statements have fused loops, it doesn't
> make sense to ask for that loop depth to be optimized for one
> statement and not for the other. But cloog can freely assume to
> optimize or not optimize, and this shouldn't be a problem at all.
>
> Overall, it'll be great to have this feature.
>
> -Uday
>
> -- You got this message because you subscribed to the CLooG
> Development mailing list. To send messages to this list, use

> cloog-development@___googlegroups.com_
> <mailto:cloog-development@__googlegroups.com
> <mailto:cloog-de...@googlegroups.com>>_ To stop subscribing,
> send a mail to
> <mailto:cloog-development%__2Buns...@googlegroups.com
> <mailto:cloog-development%252Buns...@googlegroups.com>__>_cloog-development+__unsubscribe@_googlegroups.com_
>
>
>
> <mailto:cloog-development%__2Buns...@googlegroups.com
> <mailto:cloog-development%252Buns...@googlegroups.com>__>_

>
> For more options and to visit the group,

> <http://groups.google.fr/__group/cloog-development?hl=en
> <http://groups.google.fr/group/cloog-development?hl=en>>___http://groups.google.fr/__group/_cloog-development?hl=__en_
>
>
<http://groups.google.fr/group/_cloog-development?hl=en_>
>
>
> <http://groups.google.fr/__group/cloog-development?hl=en
> <http://groups.google.fr/group/cloog-development?hl=en>>____

>
>
> _ _ _ -- This message has been scanned for viruses and dangerous

> content by *MailScanner* <http://www.mailscanner.info/>__, and is

>
> believed to be clean. _
>
>
> -- You got this message because you subscribed to the CLooG
> Development mailing list. To send messages to this list, use

> cloog-development@__googlegroups.com
> <mailto:cloog-de...@googlegroups.com> To stop subscribing, send
> a mail to cloog-development+unsubscribe@__googlegroups.com
> <mailto:cloog-development%2Bunsu...@googlegroups.com> For more

> options and to visit the group,

> http://groups.google.fr/group/__cloog-development?hl=en
> <http://groups.google.fr/group/cloog-development?hl=en>

>
>
>
> -- This message has been scanned for viruses and dangerous content by
> *MailScanner* <http://www.mailscanner.info/>, and is believed to be
> clean.

--
This message has been scanned for viruses and

dangerous content by MailScanner, and is
believed to be clean.

[Cédric Bastoul]

On Fri, Jun 1, 2012 at 11:12 AM, Uday K Bondhugula <ud...@csa.iisc.ernet.in> wrote:

- I have a mixed feeling about the fact that the size of the ls and
fs arrays is not known in the CloogOption structure, this gives me
the impression that it is not self-contained, but it's much probably
not a problem (if it becomes a problem we may introduce, e.g., a
"final" flag as the last element of each array).

Yes, I was uncomfortable about this as well. Since we don't know the number of statements in CloogOptions, the best solution I could find was to allow the user to allocate and deallocate them. So, cloog_options_free will do nothing about fs/ls.

I think there is no problem for cloog_option_malloc and cloog_option_free. Whatever the size is, according to how CLooG "objects" work, cloog_option_malloc has to set the fs/ls pointers to NULL and free has to free them (free(ls); free(fs); will do it), so I prefer not to introduce an inconsistency here. I'm more concerned by cloog_option_print which cannot dump the content of the structure, but just mention the arrays are set. I see two solutions: we could #define a final marker to put at the last element of the array (#define CLOOG_FINAL -2 for instance), or set a ls_size and a lf_size fields in CloogOptions (verbose but pretty clean).

 

-Uday

<mailto:cloog-development@googlegroups.com>>_ To stop subscribing,
send a mail to

<mailto:cloog-development%__2Bunsu...@googlegroups.com
<mailto:cloog-development%252Bunsubscribe@googlegroups.com>__>_cloog-development+__unsubscribe@_googlegroups.com_



<mailto:cloog-development%__2Bunsu...@googlegroups.com

<mailto:cloog-development%252Bunsubscribe@googlegroups.com>__>_

For more options and to visit the group,

<http://groups.google.fr/__group/cloog-development?hl=en
<http://groups.google.fr/group/cloog-development?hl=en>>___http://groups.google.fr/__group/_cloog-development?hl=__en_

<http://groups.google.fr/group/_cloog-development?hl=en_>

<http://groups.google.fr/__group/cloog-development?hl=en
<http://groups.google.fr/group/cloog-development?hl=en>>____

_ _ _ -- This message has been scanned for viruses and dangerous

content by *MailScanner* <http://www.mailscanner.info/>__, and is

believed to be clean. _


-- You got this message because you subscribed to the CLooG
Development mailing list. To send messages to this list, use

cloog-development@__googlegroups.com

<mailto:cloog-development@googlegroups.com> To stop subscribing, send

a mail to cloog-development+unsubscribe@__googlegroups.com
<mailto:cloog-development%2Bunsu...@googlegroups.com> For more

options and to visit the group,

http://groups.google.fr/group/__cloog-development?hl=en
<http://groups.google.fr/group/cloog-development?hl=en>

-- This message has been scanned for viruses and dangerous content by
*MailScanner* <http://www.mailscanner.info/>, and is believed to be
clean.

--
This message has been scanned for viruses and

dangerous content by MailScanner, and is
believed to be clean.

--
You got this message because you subscribed to the CLooG Development mailing list.

To send messages to this list, use cloog-development@googlegroups.com
To stop subscribing, send a mail to cloog-development+unsubscribe@googlegroups.com
For more options and to visit the group, http://groups.google.fr/group/cloog-development?hl=en

[Cédric Bastoul]

Hi Uday,

I made some minor changes I was sure you would agree (remove whitespace errors, documentation about fs_ls_size and default values, default value for fs_ls_size in cloog_option_malloc) and pushed it. Thank you !

Ced.

On Sun, Jun 3, 2012 at 7:44 AM, Uday Reddy <uday...@gmail.com> wrote:

Updated patch attached.

-Uday

On Sun, Jun 3, 2012 at 10:48 AM, Uday Reddy <uday...@gmail.com> wrote:

On Fri, Jun 1, 2012 at 2:59 PM, Cédric Bastoul <cedric....@u-psud.fr> wrote:

On Fri, Jun 1, 2012 at 11:12 AM, Uday K Bondhugula <ud...@csa.iisc.ernet.in> wrote:

- I have a mixed feeling about the fact that the size of the ls and
fs arrays is not known in the CloogOption structure, this gives me
the impression that it is not self-contained, but it's much probably
not a problem (if it becomes a problem we may introduce, e.g., a
"final" flag as the last element of each array).

Yes, I was uncomfortable about this as well. Since we don't know the number of statements in CloogOptions, the best solution I could find was to allow the user to allocate and deallocate them. So, cloog_options_free will do nothing about fs/ls.

I think there is no problem for cloog_option_malloc and cloog_option_free. Whatever the size is, according to how CLooG "objects" work, cloog_option_malloc has to set the fs/ls pointers to NULL and free has to free them (free(ls); free(fs); will do it), so I prefer not to introduce an inconsistency here. I'm more concerned by cloog_option_print which cannot dump the content of the structure, but just mention the arrays are set. I see two solutions: we could #define a final marker to put at the last element of the array (#define CLOOG_FINAL -2 for instance), or set a ls_size and a lf_size fields in CloogOptions (verbose but pretty clean).

Having a size looks much better, but both have to be of the same size. How about fs_ls_size?

-Uday

 

To send messages to this list, use cloog-de...@googlegroups.com
To stop subscribing, send a mail to cloog-developm...@googlegroups.com