This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug tree-optimization/50789] Gather vectorization
- From: "irar at il dot ibm.com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Wed, 19 Oct 2011 08:47:03 +0000
- Subject: [Bug tree-optimization/50789] Gather vectorization
- Auto-submitted: auto-generated
- References: <bug-50789-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50789
--- Comment #2 from Ira Rosen <irar at il dot ibm.com> 2011-10-19 08:47:03 UTC ---
(In reply to comment #0)
> To vectorize the above I'm afraid we'd need to modify tree-data-ref.c as well
> as tree-vect-data-ref.c, because the memory accesses aren't affine and already
> dr_analyze_innermost gives up on those, doesn't fill in any of the DR_* stuff.
> Perhaps with some flag and when the base resp. offset has vdef in the same loop
> we could mark it somehow and at least fill in the other fields. It would
> probably make alias decisions (in tree-vect-data-ref.c?) harder. Any ideas?
We have something similar for SLP: if an access is not affine we just fill in
what we can. But I don't really understand what can be filled in for f3/f4.
I don't think any data dependence decision is possible for f3 and f4, since we
can't prove anything. But in all the examples there are no stores, and we don't
care about read-read.
In f1 and f2 we know the base so, assuming no overflow, we can handle stores to
a different array.
>
> What is additionally possible is to conditionalize loads, either affine or not.
Can't we treat it as an unconditional load for the dr analysis purposes?