T.init on arrays unrolls initialisation loop

[dansanduleac]

If we have code like:

alias ubyte[4096] buf;

buf initUsingValue() { buf x = 0; return x; }
buf initDefault() { return buf.init; } // can just as easily replace buf for typeof(return)

then in LLVM, initialisation using the value 0 uses straight @llvm.memset, and alternatively when using a value other than 0 it uses a loop called arrayinit.
However, the .init unrolls the loop into 4096 llvm stores.

Looking at the assembly generated by DMD 2.059 (64-bit) on OSX, it seems to do the same thing i.e. generate 4096 movb instructions, or 512 movq if -Optimized, but it seems to me that this behavior is inefficient and should be changed to use a memset with the element's init / loop.

[dnadlinger]

Yes, I noticed this as well. When building with optimizations enabled, LLVM recognizes the »loop« and replaces it with a zeroinitializer resp. efficient unrolled memset.

For codegen speed, it might still be beneficial to emit less IR instructions, though.

[dansanduleac]

The memset vs loop performance is probably comparable, but what about the array size x MOV instructions that get generated? Do you think we should submit a patch report upstream about this, since DMD has the same behavior?

[dnadlinger]

The codegen could (and should) definitely be improved, no question. Should not be too hard, although I'd regard it as a rather low-priority item compared to the other open bugs.

I can't judge the performance characteristics of what DMD currently emits without detailed benchmarking, but I suppose the size of the generated code alone is reason enough to report an upstream issue.

[redstar]

I looked into this. The loop unrolling is in method TypeSArray::defaultInitLiteral() in mtype.c. The IR is generated in method ArrayLiteralExp::toElem() in toir.cpp.
I already changed the IR generation to use a zeroinitializer and a memcpy, but I think this can still be improved.

[redstar]

Turned out to be a bit more demanding than expected.
If all literals are constant then a llvm::ConstantArray is created with the values. Depending on the type of the destination, this array is directly stored or assigned to a global variable and then copied to the destination.

This should work in other cases, too. It looks like that there is a similar issue in method DtoArrayInit() in file arrays.cpp.

[redstar]

As a side effect, this fixed the std.range failure on ubuntu-x86-64.