From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11862 invoked by alias); 3 May 2010 12:35:28 -0000 Received: (qmail 11651 invoked by alias); 3 May 2010 12:35:15 -0000 Date: Mon, 03 May 2010 12:35:00 -0000 Message-ID: <20100503123515.11650.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug middle-end/43901] [4.6 Regression] FAIL: gcc.c-torture/compile/pr42196-2.c In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "rguenther at suse dot de" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2010-05/txt/msg00190.txt.bz2 ------- Comment #13 from rguenther at suse dot de 2010-05-03 12:35 ------- Subject: Re: [4.6 Regression] FAIL: gcc.c-torture/compile/pr42196-2.c On Mon, 3 May 2010, irar at il dot ibm dot com wrote: > ------- Comment #12 from irar at il dot ibm dot com 2010-05-03 12:30 ------- > > > Well. For loops we'd have disqualified it as there is no vector > > type for the external def (well, the stmt inside the loop). > > I don't think that's true. With -fno-tree-pre we get the same ICE for loop > vectorization for: > > #define N 64 > > union U > { > __complex__ int ci; > __complex__ float cf; > }; > > union U u[N]; > > void foo (double f1, double f2) > { > int i; > > for (i=0; i { > __real__ u[i].cf = f1; > __imag__ u[i].cf = f2; > } > } > > > So we do not do this for SLP? In that case > > yes, if we can return false at this point then we should replace this > > (and similar) asserts with return false. Or we should fix > > the code that scans the BB initially and sets vector types properly? > > The loop scan that sets vector types, only checks lhs types (or the smallest > type in stmt) in order to decide on vectorization factor. There is a similar > scan for BBs in vect_analyze_stmt (only to set vector types for stmts) and it > also looks only at lhs. Ah, my followup AVX patches look at all operands. > The failure occurs in analysis, so it's ok to return false at this point. > But I don't understand why external def has to have the same size as the lhs? > (And it is, of course, possible that both types are vectorizable, but still the > rhs type is bigger than the lhs type). It tries to get a _vector_ type of the same size. In theory each vectorization method can choose whatever vector size suits them most (as for external defs they need to build up a vector of equivalent elements anyway). So with AVX we can do V4DF -> V4SF vectorization, if the double is an external def the vectorization method could choose to create a vector with double size. But the reasonable default for now is th force a same-sized vector type as that is what the vectorizer was tested for until now (well, until I get the followup patch cleaned up and posted again). So yes, if we can return false we should probably do so instead of asserting (maybe assert that if we are supposed to create vectorized stmts and thus cannot fail that we indeed have a vector type here). Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43901