January 16, 2012
On 16 January 2012 21:27, Michel Fortin <michel.fortin@michelf.com> wrote:

> In fact, the optimization I'd expect the compiler to do in this case is just wipe out all the code, as it does nothing other than putting a value in a local variable which is never reused later.
>

Yes, my first thought when I saw this test was "why is it generating any
code at all?".. But I tried to forget about that :)
I am curious though, what is causing that code (on both sides) to not be
eliminated? If I write that in C, I'm sure it would generate nothing. Is
this a language implementation bug somehow?


January 16, 2012
On 16 January 2012 19:25, Walter Bright <newshound2@digitalmars.com> wrote:
> On 1/16/2012 11:16 AM, Iain Buclaw wrote:
>>>
>>> But don't worry, I'm not planning on working on that at the moment :-)
>>
>> Leave that sort of optimisation for the backend to handle please. ;-)
>
>
> Of course.
>
> I suspect Intel's compiler does that one, does gcc?
>

There's auto-vectorisation for for(), foreach(), and foreach_reverse()
loops that I have written support for.  I am not aware of GCC
vectorising anything else.

example:

int a[256], b[256], c[256];
void foo () {
  for (int i=0; i<256; i++)
    a[i] = b[i] + c[i];
}

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
January 16, 2012
On 16/01/12 8:56 PM, Iain Buclaw wrote:
> On 16 January 2012 19:25, Walter Bright<newshound2@digitalmars.com>  wrote:
>> On 1/16/2012 11:16 AM, Iain Buclaw wrote:
>>>>
>>>> But don't worry, I'm not planning on working on that at the moment :-)
>>>
>>> Leave that sort of optimisation for the backend to handle please. ;-)
>>
>>
>> Of course.
>>
>> I suspect Intel's compiler does that one, does gcc?
>>
>
> There's auto-vectorisation for for(), foreach(), and foreach_reverse()
> loops that I have written support for.  I am not aware of GCC
> vectorising anything else.
>
> example:
>
> int a[256], b[256], c[256];
> void foo () {
>    for (int i=0; i<256; i++)
>      a[i] = b[i] + c[i];
> }
>

Unfortunately, if the function was this:

void foo(int[] a, int[] b, int[] c) {
  for (int i=0; i<256; i++)
    a[i] = b[i] + c[i];
}

Then it can't vectorize due to aliasing.
January 16, 2012
On 16 January 2012 23:57, Peter Alexander <peter.alexander.au@gmail.com>wrote:

> On 16/01/12 8:56 PM, Iain Buclaw wrote:
>
>> On 16 January 2012 19:25, Walter Bright<newshound2@digitalmars.**com<newshound2@digitalmars.com>>
>>  wrote:
>>
>>> On 1/16/2012 11:16 AM, Iain Buclaw wrote:
>>>
>>>
>>>>> But don't worry, I'm not planning on working on that at the moment :-)
>>>>>
>>>>
>>>> Leave that sort of optimisation for the backend to handle please. ;-)
>>>>
>>>
>>>
>>> Of course.
>>>
>>> I suspect Intel's compiler does that one, does gcc?
>>>
>>>
>> There's auto-vectorisation for for(), foreach(), and foreach_reverse()
>> loops that I have written support for.  I am not aware of GCC
>> vectorising anything else.
>>
>> example:
>>
>> int a[256], b[256], c[256];
>> void foo () {
>>   for (int i=0; i<256; i++)
>>     a[i] = b[i] + c[i];
>> }
>>
>>
> Unfortunately, if the function was this:
>
> void foo(int[] a, int[] b, int[] c) {
>
>  for (int i=0; i<256; i++)
>    a[i] = b[i] + c[i];
> }
>
> Then it can't vectorize due to aliasing.
>

This is why D needs a __restrict attribute! ;)


January 16, 2012
On 1/16/2012 12:22 PM, Manu wrote:
> Yes, my first thought when I saw this test was "why is it generating any code at
> all?".. But I tried to forget about that :)
> I am curious though, what is causing that code (on both sides) to not be
> eliminated? If I write that in C, I'm sure it would generate nothing. Is this a
> language implementation bug somehow?

Compile with inlining off, and the compiler 'forgets' what the called function does, so it must call it.
January 16, 2012
On 1/16/2012 1:54 PM, Manu wrote:
>     Unfortunately, if the function was this:
>
>     void foo(int[] a, int[] b, int[] c) {
>
>       for (int i=0; i<256; i++)
>         a[i] = b[i] + c[i];
>     }
>
>     Then it can't vectorize due to aliasing.
>
>
> This is why D needs a __restrict attribute! ;)

That's why D has:

   a[] = b[] + c[];

because the language requires the arrays to be distinct.
January 16, 2012
On 17 January 2012 00:03, Walter Bright <newshound2@digitalmars.com> wrote:

> On 1/16/2012 1:54 PM, Manu wrote:
>
>>    Unfortunately, if the function was this:
>>
>>    void foo(int[] a, int[] b, int[] c) {
>>
>>      for (int i=0; i<256; i++)
>>        a[i] = b[i] + c[i];
>>    }
>>
>>    Then it can't vectorize due to aliasing.
>>
>>
>> This is why D needs a __restrict attribute! ;)
>>
>
> That's why D has:
>
>   a[] = b[] + c[];
>
> because the language requires the arrays to be distinct.
>

Surely it would be possible for them to be overlapping slices?


January 16, 2012
On Mon, 16 Jan 2012 23:06:12 +0100, Manu <turkeyman@gmail.com> wrote:

> On 17 January 2012 00:03, Walter Bright <newshound2@digitalmars.com> wrote:
>
>> On 1/16/2012 1:54 PM, Manu wrote:
>>
>>>    Unfortunately, if the function was this:
>>>
>>>    void foo(int[] a, int[] b, int[] c) {
>>>
>>>      for (int i=0; i<256; i++)
>>>        a[i] = b[i] + c[i];
>>>    }
>>>
>>>    Then it can't vectorize due to aliasing.
>>>
>>>
>>> This is why D needs a __restrict attribute! ;)
>>>
>>
>> That's why D has:
>>
>>   a[] = b[] + c[];
>>
>> because the language requires the arrays to be distinct.
>>
>
> Surely it would be possible for them to be overlapping slices?

If they are, that's your fault and your problem.

"The lvalue slice and any rvalue slices must not overlap."
January 16, 2012
On Mon, 16 Jan 2012 23:22:21 +0100, Simen Kjærås <simen.kjaras@gmail.com> wrote:

> On Mon, 16 Jan 2012 23:06:12 +0100, Manu <turkeyman@gmail.com> wrote:
>
>> On 17 January 2012 00:03, Walter Bright <newshound2@digitalmars.com> wrote:
>>
>>> On 1/16/2012 1:54 PM, Manu wrote:
>>>
>>>>    Unfortunately, if the function was this:
>>>>
>>>>    void foo(int[] a, int[] b, int[] c) {
>>>>
>>>>      for (int i=0; i<256; i++)
>>>>        a[i] = b[i] + c[i];
>>>>    }
>>>>
>>>>    Then it can't vectorize due to aliasing.
>>>>
>>>>
>>>> This is why D needs a __restrict attribute! ;)
>>>>
>>>
>>> That's why D has:
>>>
>>>   a[] = b[] + c[];
>>>
>>> because the language requires the arrays to be distinct.
>>>
>>
>> Surely it would be possible for them to be overlapping slices?
>
> If they are, that's your fault and your problem.
>
> "The lvalue slice and any rvalue slices must not overlap."

Sorry, forgot the link:

http://www.d-programming-language.org/arrays.html#array-operations
January 16, 2012
On 16 January 2012 21:57, Peter Alexander <peter.alexander.au@gmail.com> wrote:
> On 16/01/12 8:56 PM, Iain Buclaw wrote:
>>
>> On 16 January 2012 19:25, Walter Bright<newshound2@digitalmars.com>  wrote:
>>>
>>> On 1/16/2012 11:16 AM, Iain Buclaw wrote:
>>>
>>>>>
>>>>> But don't worry, I'm not planning on working on that at the moment :-)
>>>>
>>>>
>>>> Leave that sort of optimisation for the backend to handle please. ;-)
>>>
>>>
>>>
>>> Of course.
>>>
>>> I suspect Intel's compiler does that one, does gcc?
>>>
>>
>> There's auto-vectorisation for for(), foreach(), and foreach_reverse()
>> loops that I have written support for.  I am not aware of GCC
>> vectorising anything else.
>>
>> example:
>>
>> int a[256], b[256], c[256];
>> void foo () {
>>   for (int i=0; i<256; i++)
>>     a[i] = b[i] + c[i];
>> }
>>
>
> Unfortunately, if the function was this:
>
> void foo(int[] a, int[] b, int[] c) {
>
>  for (int i=0; i<256; i++)
>    a[i] = b[i] + c[i];
> }
>
> Then it can't vectorize due to aliasing.

Compile with -fstrict-aliasing then?

I could certainly play about with having this enabled by default, but I forsee there may be issues (maybe have it on for @safe code?)


Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';