On Thu, Jun 25, 2015 at 5:00 AM, Richard Biener
<richard.guent...@gmail.com> wrote:
> Yes, it looks good. What about COMPLEX_CST and VECTOR_CST and
> their types?
The question came around also when we were looking at these problems:
we really only care for integer_cst constants (I in ISL stands for integer ;-)
I think we can also discard those, though we do not have a test-case yet.
Probably we can write one from the real_cst test and add it with the patch.
Thanks for your review,
Sebastian
>
> Richard.
>
>> Sebastian
>>
>>>
>>> ---
>>> gcc/graphite-sese-to-poly.c | 8 ++++++++
>>> 1 file changed, 8 insertions(+)
>>>
>>> diff --git a/gcc/graphite-sese-to-poly.c b/gcc/graphite-sese-to-poly.c
>>> index 271c499..5b37796 100644
>>> --- a/gcc/graphite-sese-to-poly.c
>>> +++ b/gcc/graphite-sese-to-poly.c
>>> @@ -796,6 +796,9 @@ parameter_index_in_region (tree name, sese region)
>>>
>>> gcc_assert (SESE_ADD_PARAMS (region));
>>>
>>> + /* Cannot constrain on REAL_TYPE parameters. */
>>> + if (TREE_CODE (TREE_TYPE (name)) == REAL_TYPE)
>>> + return -1;
>>> i = SESE_PARAMS (region).length ();
>>> SESE_PARAMS (region).safe_push (name);
>>> return i;
>>> @@ -915,6 +918,7 @@ scan_tree_for_params (sese s, tree e)
>>>
>>> case INTEGER_CST:
>>> case ADDR_EXPR:
>>> + case REAL_CST:
>>> break;
>>>
>>> default:
>>> @@ -1194,6 +1198,10 @@ add_conditions_to_domain (poly_bb_p pbb)
>>> {
>>> case GIMPLE_COND:
>>> {
>>> + /* Don't constrain on REAL_TYPE. */
>>> + if (TREE_CODE (TREE_TYPE (gimple_cond_lhs (stmt))) == REAL_TYPE)
>>> + break;
>>> +
>>> gcond *cond_stmt = as_a <gcond *> (stmt);
>>> enum tree_code code = gimple_cond_code (cond_stmt);
>>>
>>> --
>>> 2.1.0.243.g30d45f7
>>>
