[LLVMdev] Unexpected behavior reading/writing <8 x i1> vector to memory

[Eli Friedman]

On Tue, Sep 6, 2011 at 4:37 PM, Matt Pharr <matt.pharr at gmail.com> wrote:
> I'm seeing some behavior that surprised me in writing an <8 x i1> vector to memory and reading it back.  (Specifically, the surprise is that I didn't get the original value back!).  This happens both with TOT and 2.9.  This program illustrates the issue:
>
> define i32 @foo() {
>  %c = alloca <8 x i1>
>  store <8 x i1> <i1 true, i1 false, i1 false, i1 false, i1 false, i1 false, i1 false, i1 false>,  <8 x i1>* %c
>  %val = load <8 x i1>* %c
>  %vali8 = bitcast <8 x i1> %val to i8
>  %vali32 = zext i8 %vali8 to i32
>  ret i32 %vali32
> }
>
> If I run this through opt -mem2reg before compiling with llc, then I basically get:
>
> _foo:
>        movl    $1, %eax
>        ret
>
> which looks good to me (and is the result I expect).
>
> If I just run it through llc without mem2reg,I get this suspicious output, which returns zero.
>
> _foo:
>        movb    $1, -8(%rsp)
>        movb    $0, -8(%rsp)
>        movzbl  -8(%rsp), %eax
>        ret
>
> Is this a bug?  I double checked the LLVM assembly reference manual and didn't see anything about writing vectors of i1 to memory as being undefined.
>
> (I recognize that I probably don't want to be doing this in general and wouldn't expect it to necessarily be super efficient.  But this was unusual enough that it seemed worth checking about.)

There are longstanding issues with CodeGen (espcially loads/stores) of
i1 vectors.  One of which is that we never actually decided what the
memory representation should be...

-Eli