This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] Matrix Flattening optimization
- From: Ayal Zaks <ZAKS at il dot ibm dot com>
- To: Shantonu Sen <ssen at opendarwin dot org>
- Cc: Razya Ladelsky <RAZYA at il dot ibm dot com>, gcc-patches at gcc dot gnu dot org, Daniel Berlin <dberlin at dberlin dot org>, jh at suse dot cz
- Date: Fri, 3 Mar 2006 00:42:46 +0200
- Subject: Re: [RFC] Matrix Flattening optimization
> 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.
Ayal.