On Thu, Jun 30, 2011 at 09:46, Richard Guenther <rguent...@suse.de> wrote:
> On Thu, 30 Jun 2011, Sebastian Pop wrote:
>
>> On Thu, Jun 30, 2011 at 05:19, Richard Guenther <rguent...@suse.de> wrote:
>> > That looks odd. So you given -1U as input you sign-extend that to -1
>>
>> correct
>>
>> > and then set the mpz to -1ULLL.
>>
>> and then it sets the mpz to signed -1, given that I'm passing false to UNS:
>>
>> /* Sets RESULT to VAL, taken unsigned if UNS is true and as signed
>> otherwise. */
>>
>> void
>> mpz_set_double_int (mpz_t result, double_int val, bool uns)
>>
>> > In fact it looks like you either
>> > have non-canoncial INTEGER_CSTs from the start or the type of the
>> > integer constants is wrong.
>>
>> I don't know what a canonical INTEGER_CST is.
>
> Canonically extended according to TYPE_UNSIGNED I mean. So what you
> do is always create signed mpzs - that should simply work without
> doing anything to the double-int. Thus, why not do
>
> static inline void
> tree_int_to_gmp (tree t, mpz_t res)
> {
> double_int di = tree_to_double_int (t);
> mpz_set_double_int (res, di, false);
> }
>
> ? I don't see why you'd want to sign-extend unsigned values
> (for example an unsigned char 255 would get sign-extended to -1).
> As double_ints are always correctly extended according to the
> sign of the INTEGER_CST they come from (iff they are properly
> canonical) you can embed all INTEGER_CSTs with precision of max.
> HOST_BITS_PER_WISE_INT * 2 into a signed mpz with precision
> HOST_BITS_PER_WISE_INT * 2 + 1.
>
>> Here are the cases that can occur:
>> - translating to mpz a -1U as the upper bound of an unsigned type,
>> in which case I do not want it to be sign extended,
>> - translating to mpz a -1U constant in an unsigned expression "x + -1U"
>> in which I do want it to be sign extended.
>
> I don't think you want the 2nd.
Supposing that we have a loop iterating over unsigned char
for (unsigned char i = 100; i > 0; i--)
that would have a decrement "i = i + -1U", then the -1U would end up
translated as 255 in mpz, and that would be really interpreted as a stride
of 255 in the rest of graphite.
> I think you want to preserve the value.
Then we should also deal with the modulo arithmetic in graphite.
Sebastian
