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

[Samuel Crow]

Hi folks,

In this case, am I wrong in assuming that for the target that Matt is using the representation is an unpacked byte for each boolean value?  If so, it might be handy to have a notation for a packed vector of bits as well.  On some architectures, packing flags in a bitset not only saves memory but even has special opcodes for dealing with them.

Just a thought,

--Sam

>________________________________
>From: Eli Friedman <eli.friedman at gmail.com>
>To: Matt Pharr <matt.pharr at gmail.com>
>Cc: llvmdev at cs.uiuc.edu
>Sent: Tuesday, September 6, 2011 6:44 PM
>Subject: Re: [LLVMdev] Unexpected behavior reading/writing <8 x i1> vector to memory
>
>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
>
>_______________________________________________
>LLVM Developers mailing list
>LLVMdev at cs.uiuc.edu        http://llvm.cs.uiuc.edu
>http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
>