[llvm-dev] array fill idioms

[Mehdi Amini via llvm-dev]

> On Nov 10, 2016, at 1:30 PM, Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> Hi,
> 
> An alternative is to perform what is done for the equivalent C construct:
> 
> void foo() {
>  char bar[20] = “hello”;
> }
> 
> ->
> 
> @foo.bar = private unnamed_addr constant [20 x i8] c"hello\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00", align 16
> define void @foo() #0 {
>  %1 = alloca [20 x i8], align 16
>  %2 = bitcast [20 x i8]* %1 to i8*
>  call void @llvm.memcpy.p0i8.p0i8.i64(i8* %2, i8* getelementptr inbounds ([20 x i8], [20 x i8]* @foo.bar, i32 0, i32 0), i64 20, i32 16, i1 false)
>  ret void
> }
> 
> 

Obviously that isn’t great for patterns, and LLVM can recognize pattern that can fit memset_pattern on targets that supports it, which looks like closer to what you’d like I think.

— 
Mehdi



> 
> 
> 
>> On Nov 10, 2016, at 1:25 PM, Bagel via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>> 
>> I am asking for some collective wisdom/guidance.
>> 
>> What sort of IR construct should one use to implement filling each
>> element in an array (or vector) with the same value?  In C++, this
>> might arise in "std:fill" or "std:fill_n", when the element values in the
>> vector are identical.
>> In the D language, one can fill an array or a slice of an array
>> by an assignment, e.g.
>> "A[2..10] = 42;"
>> 
>> 1. What I would prefer is an explicit intrinsic, call it "llvm.fill.*" that
>>  would work similar to the "llvm.memset.*" intrinsic.  The memset intrinsic
>>  only works with byte arrays, but provides wonderful optimizations in the
>>  various code generators.  Hopefully, these similar optimizations would be
>>  implemented for "llvm.fill.*".
>> 
>> 2. Given that I probably won't get my wish, I note that some front-ends use
>>  vector assignment:
>>  store <8 x i16> <i16 42, i16 42, i16 42, i16 42, i16 42, i16 42, i16 42, i16
>> 42>, <8 x i16>* %14, align 2
>>  Does this work well for architectures without SIMD?
>>  What chunk size should be used for the vector, and is that architecture
>>  dependent?
>> 
>> 3. If vectors are not used, but rather an explicit loop of stores,
>>  element-by-element, will this be recognized as an idiom for
>>  architecture-dependent optimizations?
>> 
>> Thanks in advance.
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev