On Thu, 30 Jun 2011, Sebastian Pop wrote:
> 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.
But what do you do for
for (unsigned char i = 128; i < 255; ++i)
? You change 128 to -128 which is wrong. So yes, you also have to
deal with modulo arithmetic in graphite.
Richard.
