llvm dev - Nov 2016 - array fill idioms

Back in the day, we called this a BLT (block transfer, pronouced 'blit')
for the PDP-10 instruction of that name.
You can do this by assigning the first value, then do an overlapping memcpy to
fill in the rest.
There's probably something clever you can do with vector instructions too,
in many cases.
--paulr

From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Ryan
Taylor via llvm-dev
Sent: Thursday, November 10, 2016 2:08 PM
To: Bagel; llvm-dev
Subject: Re: [llvm-dev] array fill idioms

Like a list initializer, but will do partials/slices?

Are you just looking to create an intrinsic that will generate a jump to a lib
routine?

On Thu, Nov 10, 2016 at 5:02 PM, Bagel via llvm-dev <llvm-dev at
lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:
Yes, I know this works peachy keen for char arrays.  I'm looking at (which
is
hard to express in C) something like

void foo () {
   int bar[20] = { 42, 42, ..., 42 };
}

I don't want to do a memcopy of the 20 element constant array, and memset
doesn't work here.  I want an intrinsic that copys the scalar int constant
42
to each element of the int array.

bagel


On 11/10/2016 03:30 PM, Mehdi Amini 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
> }
>
>
> —
> Mehdi
_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161110/ddb92984/attachment-0001.html>

> On Nov 10, 2016, at 5:15 PM, Robinson, Paul via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> Back in the day, we called this a BLT (block transfer, pronouced
'blit') for the PDP-10 instruction of that name.
On x86, there is REP MOVS.
> You can do this by assigning the first value, then do an overlapping memcpy
to fill in the rest.
This is undefined behavior, and really doesn’t work with most modern memcpy( )
implementations (the most common thing these days is to simply implement
memmove( ) semantics for memcpy, which will very much not do what you want).

– Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161110/88bc8765/attachment.html>

Right, not memcpy/memmove, sorry I should be more careful about that stuff.
REP MOVS looks like the right thing though.  Does LLVM know how to produce that?
Thanks,
--paulr

From: scanon at apple.com [mailto:scanon at apple.com]
Sent: Thursday, November 10, 2016 2:24 PM
To: Robinson, Paul
Cc: Ryan Taylor; Bagel; llvm-dev at lists.llvm.org
Subject: Re: [llvm-dev] array fill idioms

On Nov 10, 2016, at 5:15 PM, Robinson, Paul via llvm-dev <llvm-dev at
lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:

Back in the day, we called this a BLT (block transfer, pronouced 'blit')
for the PDP-10 instruction of that name.

On x86, there is REP MOVS.


You can do this by assigning the first value, then do an overlapping memcpy to
fill in the rest.

This is undefined behavior, and really doesn’t work with most modern memcpy( )
implementations (the most common thing these days is to simply implement
memmove( ) semantics for memcpy, which will very much not do what you want).

– Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161110/2658be74/attachment.html>