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

[Duncan Sands]

Hi Matt,

On 07/09/11 01:37, Matt Pharr 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:

some new infrastructure, activated using the -promote-elements llc flag, is
supposed to take care of this.  Unfortunately it crashes on your testcase :(
Otherwise, as Eli mentioned, codegen simply doesn't support these types.  I
had thought that all problems would result in an assertion firing but it seems
not...

Ciao, Duncan.

> 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.)
>
> Thanks,
> -matt
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev