[LLVMdev] i1 Values

[Nick Lewycky]

On 5 February 2015 at 12:48, <dag at cray.com> wrote:

> 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!");
>

Please don't do this. Asking for an i1 APInt to be sign-extended does not
mean that we have encountered a bug. How would you write a parser for the
constant expression "i32 sext(i1 true)"? It grabs the i1 and sign extends
it.


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

We don't create i1 -1 values, nor do we create i1 1 values. APInt is
neither signed nor unsigned, it is signless. The interpretation of the bits
(or in this case, the bit) is a matter for the caller to decide.

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