From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 35797 invoked by alias); 30 Oct 2019 15:58:10 -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 35788 invoked by uid 89); 30 Oct 2019 15:58:09 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-4.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=H*f:sk:H3qtSdd, H*i:CAFiYyc2NfgM7, H*i:sk:H3qtSdd, treats 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, 30 Oct 2019 15:58:08 +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 A3AD54F5; Wed, 30 Oct 2019 08:58:06 -0700 (PDT) Received: from localhost (e121540-lin.manchester.arm.com [10.32.98.126]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 2BE833F6C4; Wed, 30 Oct 2019 08:58:06 -0700 (PDT) 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, 30 Oct 2019 16:33:00 -0000 In-Reply-To: (Richard Biener's message of "Wed, 30 Oct 2019 15:37:50 +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-10/txt/msg02157.txt.bz2 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. This patch just treats the mode as an alternative way of specifying the vector size. 11/n then tries to use related_vector_mode to choose the vector mode for each element type instead. But 11/n only uses related_vector_mode if vec_info::vector_mode is a vector mode. If it's an integer mode (as for -mno-sse), or if related_vector_mode fails to find a vector mode, then we still fall back to mode_for_vector and so pick an integer mode in the same cases as before. Thanks, Richard