On the x86_64, does one have to zero a vector register before filling it completely ?

[Toon Moene]

Toon Moene wrote:

> Tim Prince wrote:
> 
>  > If you want those, you must request them with -mtune=barcelona.
> 
> OK, so it is an alignment issue (with -mtune=barcelona):
> 
> .L6:
>         movups  0(%rbp,%rax), %xmm0
>         movups  (%rbx,%rax), %xmm1
>         incl    %ecx
>         addps   %xmm1, %xmm0
>         movaps  %xmm0, (%r8,%rax)
>         addq    $16, %rax
>         cmpl    %r10d, %ecx
>         jb      .L6

Once this problem is solved (well, determined how it could be solved), 
we go on to the next, the extraneous induction variable %ecx.

There are two ways to deal with it:

1. Eliminate it with respect to the other induction variable that
    counts in the same direction (upwards, with steps 16) and remember
    that induction variable's (%rax) limit.

or:

2. Count %ecx down from %r10d to zero (which eliminates %r10d as a loop
    carried register).

g77 avoided this by coding counted do loops with a separate loop counter 
counting down to zero - not so with gfortran (quoting):

/* Translate the simple DO construct.  This is where the loop variable
    has integer type and step +-1.  We can't use this in the general case
    because integer overflow and floating point errors could give
    incorrect results.
    We translate a do loop from:

    DO dovar = from, to, step
       body
    END DO

    to:

    [Evaluate loop bounds and step]
    dovar = from;
    if ((step > 0) ? (dovar <= to) : (dovar => to))
     {
       for (;;)
         {
           body;
    cycle_label:
           cond = (dovar == to);
           dovar += step;
           if (cond) goto end_label;
         }
       }
    end_label:

    This helps the optimizers by avoiding the extra induction variable
    used in the general case.  */

So either we teach the Fortran front end this trick, or we teach the 
loop optimization the trick of flipping the sense of a (n otherwise 
unused) induction variable ....

-- 
Toon Moene - e-mail: toon@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
At home: http://moene.org/~toon/
Progress of GNU Fortran: http://gcc.gnu.org/gcc-4.5/changes.html