🚀 go-pugleaf

In article <45o2n2$o48@gabi.gabi-soft.fr>, kanze@gabi-soft.fr (J. Kanze) writes:
> enseeg14@grenet.fr wrote:
> 
> |> > for (i = 0 ; i < n ; i++) {
> |> >    for (j = 0 ; j < n ; j++) {
> |> >       a[i][j] = b[i][j] * c[i] ;
> |> >    }
> |> > }
> 
> |> > do j = 1,m
> |> >   do i = 1, n
> |> >     a (i,j) = b(i,j) * c(i)
> |> >   enddo
> |> > enddo 
> 
> Const won't help, and the problem isn't typing, but potential aliasing.
> Fortran basically says that the results are undefined if aliasing is
> present, C/C++ doesn't.

A minor point: Fortran doesn't say the results are *always* undefined if
aliasing is present.  The only thing that Fortran says that C/C++ do not is
that, if a, b, and c are all arguments to the function or subroutine, the
results are undefined if they refer to the same object.

You could easily write a Fortran program containing the above code fragment
wherein the compiler would not be allowed to vectorize the loop because of
aliasing.  That's one reason why vectorizing Fortran compilers are not
cheap. :-)

I'll also note that, despite the fact that the Fortran standard says the
results are undefined if two arguments overlap, there is a ton of extant
code that breaks that rule.  For that reason, some commercial Fortran
compilers have some way of telling the compiler to avoid any optimization
based on that rule.

> If the compiler can determine that no aliasing is present, they can
> optimize.  Typically, this would require intermodule flow analysis,
> something that is not frequently done in either C/C++ or Fortran
> (although I've heard rumors of a C++ compiler which does it).

Well, if a, b, and c were all local arrays, a C/C++ compiler could easily
determine that no aliasing is present.  However, typically they are
arguments to a function/subroutine.

|> The Fortran compiler can easy unroll the loop and take advantage of scalar
|> caches, and easily use vectorial registers, whereas the C compiler
|> can't even move the evaluation of c[i] out of the inner loop because
|> &c[i] could be == to &a[x][y] ............ That's the problem with
|> weak typin... I'm wondering if any of the "const" tweak would change
|> anything...

A C/C++ compiler could still unroll the loop, which would at least reduce
the loop overhead.  However, reordering operations would be verboten unless
the compiler could prove no aliasing.

> There is a proposed extention to C which would do it, a sort of son of
> noalias.  I don't know any of the details, but I'm sure that a question
> in comp.std.c would reach people who did, or who could point you in the
> right direction.

I continue to think such extensions are a bad idea.  They basically force
the compiler to trust the programmer, and historically that is not a
reliable thing to do.  The original programmer may have been careful to
avoid aliasing, but what about the 50 other programmers who came later and
made modifications to the program?  Worse still, you may have a bug lurking
there for decades until you happen to compile with a compiler that takes
advantage of the noalias declaration *and* does it in such a way that the
illegal aliasing changes the behavior of the program.  Such bugs are
extremely difficult to track down.

For example, suppose that in the above matrix multiplication, a[i][j] is
the same as b[i][j+2].  This violates the programmer's assertion that a and
b are not aliased, but you won't be able to tell it unless the compiler
generates code that fetches two elements of b ahead of an assignment to an
element of a.  One fetch ahead would be okay.

IMHO, the best answer is improved interprocedural analysis by compilers,
because that is the safest and also the most optimal -- it detects aliasing
when it is present, and detects lack of aliasing when it is absent (even if
the programmer didn't know whether aliasing was present or not).

-- 
Bill Leonard
Harris Computer Systems Corporation
2101 W. Cypress Creek Road
Fort Lauderdale, FL  33309
Bill.Leonard@mail.hcsc.com

These opinions and statements are my own and do not necessarily reflect the
opinions or positions of Harris Computer Systems Corporation.

------------------------------------------------------------------------------
I feel like I've been sent for and couldn't go, and weren't needed after I
got there.
------------------------------------------------------------------------------

[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]