zero_alloca outputs invalid bitcode in some cases

[marijnh]

The following program results in an error like this when compiled:

alignment argument of memory intrinsics must be a constant int
  call void @llvm.memset.p0i8.i32(i8* %25, i8 0, i32 %92, i32 select (i1 icmp ult (i32 ptrtoint (i32* getelementptr ({ i1, i32 }* null, i64 0, i32 1) to i32), i32 1), i32 1, i32 ptrtoint (i32* getelementptr ({ i1, i32 }* null, i64 0, i32 1) to i32)), i1 false)

tag option<T> { some(T); none; }

fn foo<T>(x: &T) {
    let a = ~[some(x)];
    let _b <- a;
}

fn main() {
    foo(5);
}

The problem seems to be that LLVMIsConstant considers the select expression a constant, whereas the checker does not.

[marijnh]

(To reproduce this, you have to revert the patch linked above first. I think we should still find a real solution, though. Or is it safe to just always pass 0 as align, since the pointer is already aligned?)

[marijnh]

@nikomatsakis @brson You probably understand alignment subtleties better than I do. Could one of you look at the above patch and see if the upcall could sanely be replaced by some manual alignment-shuffling in trans::call_bzero?

[nikomatsakis]

@marijnh, is the issue you are trying to address in that patch that an alignment of 0 produces invalid code?

[marijnh]

No. The problem is that you get an LLVM error when you pass a non-compile-time-constant ValueRef to llvm.memset.p0i8.i32 as alignment arg. The old workaround just replaced the alignment with a C_i32(0), but that caused issue #1546 .

[marijnh]

@nikomatsakis In response to your remark on IRC, what happens when you simply pass 0 is a segfault with the program pasted in #1546 . My patch fixes that (possibly by accident).

[nikomatsakis]

I will try out #1546. I don't (yet) see why this should have caused that segfault.

[nikomatsakis]

let me step back a bit: the upcall zeroes out more than the LLVM primitive does, since you align the size. The LLVM primitive assumes the size has been appropriately aligned (as far as I know) and only uses the alignment to decode how many bytes of data it can copy at a time. So maybe the deeper problem here is that the size is being computed incorrectly, leading to #1546. (or maybe I'm just confused)