[LLVMdev] i1 Values

[dag at cray.com]

<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.

                                -David