[LLVMdev] i1 Values

[Nick Lewycky]

On 5 February 2015 at 13:04, <dag at cray.com> wrote:

> <dag at cray.com> writes:
>
> > I've been debugging some strange happenings over here and I put an
> > assert in APInt to catch what I think is the source of the problem:
> >
> >   int64_t getSExtValue() const {
> >     // An i1 -1 is unrepresentable.
> >     assert(BitWidth != 1 && "Signed i1 value is not representable!");
> >
> > To me an i1 -1 makes no sense whatsoever.  It is not representable in
> > twos-complement form.  It cannot be distinguished from unsigned i1 1.
> >
> > It turns out this assert triggers all over the place.  Before I dive
> > into this rat hole I'd like to confirm with others my sense that we
> > shouldn't be creating i1 -1 values.  Is there some legitimate reason to
> > do so?
>
> I should clarify this.  The problem isn't with i1 -1 per se, it's the
> fact that we need to also represent an unsigned i1 1 value.
>
> The problem appears to be that somewhere we request a sign-extended i1 1
> constant value when we really want the zero-extended i1 1 value.  That's
> probably actually the real error but I'm still wondering whether APInt
> should be used to represent both signed and unsigned i1 1.
>

This is in no way specific to i1's. Given an i8, you can have anything from
i8 -128 up to i8 255, inclusive. That's a larger range than 8 bits can
represent.

Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150205/1ee9bc1d/attachment.html>