[GSoC] generation of GCC expression trees from isl ast expressions

[Tobias Grosser]

On 25/06/2014 16:25, Roman Gareev wrote:
> Hi Tobias,
>
> I haven't found out how to use unit tests in gcc. I've asked community
> about this. Maybe it is better to postpone testing using DejaGnu tests
> until generation of loops with empty bodies is finished, because we
> have to traverse isl ast to transform expressions anyway. What do you
> think about this?

Are you saying we should better not do unit testing at the moment? (This 
is perfectly fine with me, I am just verifying what you said)

If we don't have a convenient way to do unit-testing, we need to do 
testing for larger programs (at least empty loop bodies). This is what 
we did previously and even though not ideal should work as well.

> I've written the following functions to compare the semantics of the
> GCC and isl expressions: isl_ast_bin_expression_comp_test and
> graphite_bin_expression_comp_test. graphite_bin_expression_comp_test
> compares the result of evaluation of binary tree expression of the
> given type with the given assumed result.
> isl_ast_bin_expression_comp_test the result of evaluation of binary
> isl_ast_expression with the given assumed result. They are called
> after “if (dump_file && (dump_flags & TDF_DETAILS))» and can be
> eliminated in the future.

I did not fully understand them. Are you comparing the resulting GIMPLE 
trees or are you statically evaluating the isl and gimple trees to check
if the computed value is the same?

I was hoping we could compare the actual trees, as this would allow us 
to not just test certain special cases.

Anyway, it seems that get's more involved than I expected (you do very 
good research, but I don't want to wast too much of your time on that). 
I suppose just starting with actual test cases should work as well (or 
even better).

 > However, it seems that it is impossible to
> verify all types of isl_ast_expression, because only add, sub, mul,
> div, and, or can be generated. If I am not mistaken, there is a
> possibility of generation of any isl_ast_expression using
> isl_ast_epxr_alloc_binary, but it is missing in isl_ast.h. Could you
> please advise me what can be done in this situation?

Yes, it seems this functionality is not exposed. We could ask for it to
be exposed if we would need to, but that may be too much hassle/overhead.

> I've rewritten the generation of isl_ast_expr_int, but after
> successful building of gcc the following error arises:
>
> /home/roman/compiled/build/graphite8/libexec/gcc/x86_64-unknown-linux-gnu/4.10.0/cc1plus:
> symbol lookup error:
> /home/roman/compiled/build/graphite8/libexec/gcc/x86_64-unknown-linux-gnu/4.10.0/cc1plus:
> undefined symbol: isl_val_from_gmp
>
> Do you know anything about this mistake? Should I use something
> undocumented in isl manual, but important for Graphite like
> +#if defined(__cplusplus)
> +extern "C" {
> +#endif
> +#include <isl/val_gmp.h>
> +#if defined(__cplusplus)
> +}
> +#endif
>
> I have to write the code above to use isl_val_get_num_gmp from isl/val_gmp.h.

That seems to be a bug in the isl header file. The 'fix' seems fine, but 
I would verify that nested extern "C" statements don't cause issues, in 
case isl fixes this in a later version.

Tobias