[LLVMdev] i1 Values

[dag at cray.com]

Nick Lewycky <nlewycky at google.com> writes:

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

I simply put the assert there to track down a bug, I wasn't proposing to
commit it.  :)

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

Yes, I clarified this in my follow-up.  Somewhere a caller is treating
it as the wrong thing.  It's deep in codegen somewhere so it is
difficult to root out.  :(

I agree that APInt is fine.  Thanks for your helpful note!

                           -David