Re: [RFC] Matrix Flattening optimization

[Ayal Zaks <ZAKS at il dot ibm dot com>]

"Richard Guenther" <richard.guenther@gmail.com> wrote on 03/03/2006
13:10:14:

> On 3/2/06, Ayal Zaks <ZAKS@il.ibm.com> wrote:
> > > How does this deal with the case where
> > > 1) dim2 is a random odd number like 139
> > > 2) malloc on the host returns vector-aligned allocations
> > > 3) you're planning on doing vector operations on a[i] for at least
the
> > first
> > > part of a[i].
> > >
> > > If you do this type of malloc combining, a'[i * dim2 + 0] may no
longer
> > be
> > > aligned on a 16-byte boundary or whatever, so your later vectorized
code
> > would
> > > no longer be operating on aligned data, and may crash. If a user is
using
> > the
> > > auto-vectorizer, it's possible gcc could regroup the operation to
perform
> >
> > > well, but that wouldn't work well with hand-written vector code.
> >
> > Good point. We certainly don't want to obstruct vectorization ..
> >
> > Note that
> > Razya>The analysis part is implemented in
analyze_matrix_allocation_site()
> > Razya>and analyze_matrix_accesses().
> > The latter traverses all accesses, so it could detect such hand-written
> > vector code and either disable the optimization for this matrix or pad
its
> > rows to properly align them. Padding for alignment might actually be
worth
> > while irrespective of hand/auto vectorization.
>
> Even padding to either power-of-two row size (for cheap multiplication)
or
> cache-line aligned row-size if cheap enough may be worth in general.
Though
> I wonder if you currenlty deal with not compile-time constant row sizes?

sure; this is the case in art and equake that Razya reported. When row
sizes are compile-time constants, C lets you define/allocate a
multidimensional matrix whose multi-subscripted accesses are flat by
definition (no need for this or any optimization). Padding might help such
constant-sized cases as well.

Ayal.

>
> (and no, it won't help tramp3d ;))
> Richard.