SIMD benchmark

[Manu]

On 17 January 2012 03:56, Iain Buclaw <ibuclaw at ubuntu.com> wrote:

> On 16 January 2012 22:36, Iain Buclaw <ibuclaw at ubuntu.com> wrote:
> > On 16 January 2012 21:57, Peter Alexander <peter.alexander.au at gmail.com>
> wrote:
> >> On 16/01/12 8:56 PM, Iain Buclaw wrote:
> >>>
> >>> On 16 January 2012 19:25, Walter Bright<newshound2 at 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?)
>
> OK, have turned on strict aliasing by default for D2.  You should now
> be able to vectorise loops that use locals and parameters. :-)
>

What protects these ranges from being overlapping? What if they were
sourced from pointers?
Are just we to say in D that aliasing is not allowed, and 'you shouldn't do
it'? People almost never alias intentionally, it's usually the
most insidious of bugs. :/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120117/b5788591/attachment.html>