On Tue, May 24, 2011 at 09:09, Alexey Kravets <kayr...@ispras.ru> wrote: > There are two places in graphite-opencl where we use strcmp technique. > The first one is the detection of privatizable variables > (opencl_private_var_name_p) and it can be eliminated by marking all zero > dimensional arrays as private (see patch below).
Thanks for this patch. I think that the patch is a good cleanup. I will commit it to the graphite branch after some testing. One change that I introduced sometime in February is that some reductions are not translated to a zero dim array to make the dependence test work on some of the interchange testcases. With this change, are we going to also create privatized copies for the reduction variables that are not translated into zero dim arrays? > The other occurrence of this technique is the detection of loop iterators in > CLAST data structures. In this case we assume that every loop iterator > called scat_<NUM> where NUM represents the depth of corresponding loop in > current loop nest. Is it possible to use it here, or we should use another > approach for detecting and comparing loop iterators for CLAST loops? I had a quick look at the code and I think that these uses are quite difficult to remove as they are dealing with the CLAST representation: static bool opencl_constant_expression_p (struct clast_expr *expr, const char *first_scat) static const char * opencl_get_scat_real_name (opencl_main code_gen, clast_name_p name) I guess that we still can use the strcmp technique in these cases. Sebastian
