Vector ops optimization

[Temtaime]

First:

auto foo(ref float[4] a, float c) {
  typeof(a) b;
  b[] = a[] * c;
  return b;
}

Creates a call to _arraySliceExpMulSliceAssign_f function, but it think it needs to be inlined and turned in only one mulps.

Second:

auto foo(ref float[4] a, float c) {
  typeof(a) b;
  foreach(i, ref v; b) v = a[i] * c;
  return b;
}

OK, this code creates only one mulps.

We can increase size of a and it will be OK: http://goo.gl/jzjRH9
But for example if we make count of elements in a >= 32 (http://goo.gl/q1uKEZ), then ldc generates unnecessary initializations with nan. Is it llvm problem or ldc? Can we tell llvm that initialization is unnecessary ?

[redstar]

At first example: this is a missed optimization opportunity. I try to solve this.

At second example: what about adding = void;:

auto foo(ref float[4] a, float c) {
  typeof(a) b = void;
  foreach(i, ref v; b) v = a[i] * c;
  return b;
}

The NaNs are generated by ldc because of the language specification: http://dlang.org/declaration.html#VoidInitializer

[Temtaime]

HI Kai !
Yes i know that it's because of language specification but all the elements are overwritten, so there no chance that compiler can optimize it by himself ?

[redstar]

@Temtaime Could you check PR #939? This should fix the first example with -O2 or higher.

[Temtaime]

http://goo.gl/QdFsZP
Yes, now all is OK. Thanks you, Kai !

[Temtaime]

@redstar
I discovered another strange thing.
Compare http://goo.gl/8jb9h2 with link in my previous post.
After ret there are some strange artefacts. Is it normal ?

[redstar]

I think this is a bug in the tool.
The code is the function _arraySliceExpMulSliceAssign_f which is also emitted. The label above the code is missing.

[dnadlinger]

Closing, as the problem seems to be fixed and the linked site with the code examples seems to be offline. Please feel free to re-open if the problem still persists.

[Temtaime]

All is OK, thanks.
I'll bring up the site soon btw.