From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 111154 invoked by alias); 13 Nov 2019 16:15:47 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 111102 invoked by uid 89); 13 Nov 2019 16:15:43 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-4.7 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=picks X-HELO: foss.arm.com Received: from foss.arm.com (HELO foss.arm.com) (217.140.110.172) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 13 Nov 2019 16:15:40 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id D2A8E30E; Wed, 13 Nov 2019 08:15:38 -0800 (PST) Received: from localhost (e121540-lin.manchester.arm.com [10.32.98.126]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 5D60B3F534; Wed, 13 Nov 2019 08:15:38 -0800 (PST) From: Richard Sandiford To: Richard Biener Mail-Followup-To: Richard Biener ,GCC Patches , richard.sandiford@arm.com Cc: GCC Patches Subject: Re: [8/n] Replace autovectorize_vector_sizes with autovectorize_vector_modes References: Date: Wed, 13 Nov 2019 16:16:00 -0000 In-Reply-To: (Richard Biener's message of "Wed, 13 Nov 2019 15:29:51 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2019-11/txt/msg01067.txt.bz2 Richard Biener writes: > On Tue, Nov 12, 2019 at 6:54 PM Richard Sandiford > wrote: >> >> Richard Biener writes: >> > On Wed, Oct 30, 2019 at 4:58 PM Richard Sandiford >> > wrote: >> >> >> >> Richard Biener writes: >> >> > On Fri, Oct 25, 2019 at 2:37 PM Richard Sandiford >> >> > wrote: >> >> >> >> >> >> This is another patch in the series to remove the assumption that >> >> >> all modes involved in vectorisation have to be the same size. >> >> >> Rather than have the target provide a list of vector sizes, >> >> >> it makes the target provide a list of vector "approaches", >> >> >> with each approach represented by a mode. >> >> >> >> >> >> A later patch will pass this mode to targetm.vectorize.related_mode >> >> >> to get the vector mode for a given element mode. Until then, the modes >> >> >> simply act as an alternative way of specifying the vector size. >> >> > >> >> > Is there a restriction to use integer vector modes for the hook >> >> > or would FP vector modes be OK as well? >> >> >> >> Conceptually, each mode returned by the hook represents a set of vector >> >> modes, with the set containing one member for each supported element >> >> type. The idea is to represent the set using the member with the >> >> smallest element type, preferring integer modes over floating-point >> >> modes in the event of a tie. So using a floating-point mode as the >> >> representative mode is fine if floating-point elements are the smallest >> >> (or only) supported element type. >> >> >> >> > Note that your x86 change likely disables word_mode vectorization with >> >> > -mno-sse? >> >> >> >> No, that still works, because... >> >> >> >> > That is, how do we represent GPR vectorization "size" here? >> >> > The preferred SIMD mode hook may return an integer mode, >> >> > are non-vector modes OK for autovectorize_vector_modes? >> >> >> >> ...at least with all current targets, preferred_simd_mode is only >> >> an integer mode if the target has no "real" vectorisation support >> >> for that element type. There's no need to handle that case in >> >> autovectorize_vector_sizes/modes, and e.g. the x86 hook does nothing >> >> when SSE is disabled. >> >> >> >> So while preferred_simd_mode can continue to return integer modes, >> >> autovectorize_vector_modes always returns vector modes. >> > >> > Hmm, I see. IIRC I was playing with a patch for x86 that >> > enabled word-mode vectorization (64bits) for SSE before (I see >> > we don't do that at the moment). The MMX-with-SSE has made >> > that somewhat moot but with iterating over modes we could >> > even make MMX-with-SSE (MMX modes) and word-mode vectors >> > coexist by allowing the hook to return V4SI, V2SI, DImode? >> > Because MMX-with-SSE might be more costly than word-mode >> > but can of course handle more cases. >> > >> > So you say the above isn't supported and cannot be made supported? >> >> It isn't supported as things stand. It shouldn't be hard to make >> it work, but I'm not sure what the best semantics would be. >> >> AIUI, before the series, returning word_mode from preferred_simd_mode >> just means that vectors should have the same size as word_mode. If the >> target defines V2SI, we'll use that as the raw type mode for SI vectors, >> regardless of whether V2SI is enabled. If the mode *is* enabled, >> the TYPE_MODE will also be V2SI and so returning word_mode from >> preferred_simd_mode is equivalent to returning V2SImode. If the mode >> isn't enabled, the TYPE_MODE will be word_mode if that's suitable and >> BLKmode otherwise. >> >> The situation's similar for SF; if the target defines and supports V2SF, >> returning word_mode would be equivalent to returning V2SFmode. >> >> But it sounds like returning word_mode for the new hook would behave >> differently, in that we'd force the raw type mode to be DImode even >> if V2SImode is defined and supported. > > Yes. > >> So what should happen for float >> types? Should we reject those, or behave as above and apply the usual >> mode_for_vector treatment for a word_mode-sized vector? > > I wasn't aware we're doing this mode_for_vector dance, certainly we > didn't that before? We do that without the series too, just a bit more indirectly. get_vectype_for_scalar_type_and_size has: /* If no size was supplied use the mode the target prefers. Otherwise lookup a vector mode of the specified size. */ if (known_eq (size, 0U)) simd_mode = targetm.vectorize.preferred_simd_mode (inner_mode); else if (!multiple_p (size, nbytes, &nunits) || !mode_for_vector (inner_mode, nunits).exists (&simd_mode)) return NULL_TREE; /* NOTE: nunits == 1 is allowed to support single element vector types. */ if (!multiple_p (GET_MODE_SIZE (simd_mode), nbytes, &nunits)) return NULL_TREE; vectype = build_vector_type (scalar_type, nunits); So all we use the simd_mode for is to get a size. Then that size determines the nunits, and build_vector_type picks whichever mode works best for that nunits and element type. That mode might not have anything to do with simd_mode, except for having the same size. So although the new mode_for_vector calls make that explicit, it was the behaviour before the series too. > I expected targets would return vector modes that > are enabled only. What's the reason to not do that? I think all current targets do only return supported modes or word_mode from preferred_simd_mode. But returning word_mode isn't for example an effective way of preventing V2SI being used, since if V2SI is enabled for 64-bit targets, word_mode would actually choose V2SI rather than DI. >> If code contains a mixture of HImode and SImode elements, should >> we use DImode for both of them, or SImode for HImode elements? >> Should the modes be passed to the target's related_vector_mode >> hook in the same way as for vectors, or handled before then? > > I'd say SImode and HImode are naturally "related" "vector" modes > for word_mode - so word_mode ideally is just a placeholder for > "try to vectorize w/o actual SIMD instructions" which we can do > for a small set of operations. > >> I could implement one of these. I'm just not sure it'd turn out >> to be the right one, once someone actually tries to use it. :-) > > Heh. I was merely trying to make sure we're not designing us > into a corner where we can't mix the word_mode vectorization > facility with the SIMD one (because on GIMPLE it's still all > vectors, only vector lowering exposes the ints IIRC). > >> FWIW, another way of doing the same thing would be to define >> emulated vector modes, e.g. EMUL_V2SI, giving them a lower >> priority than the real V2SI. This is already possible with >> VECTOR_MODES_WITH_PREFIX. Because these emulated modes would >> be permanently unsupported, the associated TYPE_MODE would always >> be the equivalent integer mode (if appropriate). So we could force >> integer modes that way too. This has the advantage that we never lose >> sight of what the element type is, and so can choose between pairing >> EMUL_V2SI and EMUL_V4HI vs. pairing EMUL_V2SI and EMUL_V2HI, >> just like we can for "real" vector modes. >> >> Of course that's "a bit" of a hack. But then so IMO is using integer >> modes for this kind of choice. :-) >> >> Another option I'd considered was having the hook return a list of >> abstract identifiers that are only meaningful to the target, either >> with accompanying information like the maximum size and maximum nunits, >> or with a separate hook to provide that information. Or we could even >> return a list of virtual objects. But that seemed like an abstraction >> too far when in practice a vector mode should be descriptive enough. > > Anyway, I think we have testsuite coverage for word_mode vectorization > and IIRC i?86 enables that when there's no SSE support via > the preferred_simd_mode hook which you do not change (and at the moment > that doesn't have to be in the list of sizes we should iterate over). Yeah. > When I understand you correctly what is not yet supported with your patch > is adding word_mode (or other integer modes) to autovectorize_vector_modes > but behavior could be emulated via non-enabled vector modes that get > mapped to integer modes. Right. And we could support word_mode with its current meaning from autovectorize_vector_modes too if that turns out to be the best way of handling it. Thanks, Richard