[llvm-dev] array fill idioms

[Mehdi Amini via llvm-dev]

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
}


— 
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