From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 87562 invoked by alias); 3 Jan 2019 17:32:52 -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 87530 invoked by uid 89); 3 Jan 2019 17:32:50 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.3.2 spammy=consecutive X-HELO: mail3-relais-sop.national.inria.fr Received: from mail3-relais-sop.national.inria.fr (HELO mail3-relais-sop.national.inria.fr) (192.134.164.104) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 03 Jan 2019 17:32:48 +0000 Received: from aaubervilliers-157-1-2-55.w83-200.abo.wanadoo.fr (HELO stedding) ([83.200.109.55]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Jan 2019 18:32:45 +0100 Date: Thu, 03 Jan 2019 17:32:00 -0000 From: Marc Glisse Reply-To: gcc-patches@gcc.gnu.org To: Jakub Jelinek cc: gcc-patches@gcc.gnu.org, Richard Biener , Richard Sandiford , Jason Merrill , "Joseph S. Myers" , Jan Hubicka Subject: Re: [PATCH] Add __builtin_convertvector support (PR c++/85052) In-Reply-To: <20190103110412.GO30353@tucnak> Message-ID: References: <20190103100640.GM30353@tucnak> <20190103110412.GO30353@tucnak> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-SW-Source: 2019-01/txt/msg00118.txt.bz2 On Thu, 3 Jan 2019, Jakub Jelinek wrote: > On Thu, Jan 03, 2019 at 11:48:12AM +0100, Marc Glisse wrote: >>> The following patch adds support for the __builtin_convertvector builtin. >>> C casts on generic vectors are just reinterpretation of the bits (i.e. a >>> VCE), this builtin allows to cast int/unsigned elements to float or vice >>> versa or promote/demote them. doc/ change is missing, will write it soon. >>> >>> The builtin appeared in I think clang 3.4 and is apparently in real-world >>> use as e.g. Honza reported. The first argument is an expression with vector >>> type, the second argument is a vector type (similarly e.g. to va_arg), to >>> which the first argument should be converted. Both vector types need to >>> have the same number of elements. >>> >>> I've implemented same element size (thus also whole vector size) conversions >>> efficiently - signed to unsigned and vice versa or same vector type just >>> using a VCE, for e.g. int <-> float or long long <-> double using >>> appropriate optab, possibly repeated multiple times for very large vectors. >> >> IIUC, you only lower __builtin_convertvector to VCE or FLOAT_EXPR or >> whatever in tree-vect-generic. That seems quite late. At least for the >> "easy" same-size case, I think we should do it early (gimplification?), > > No, it must not be done at gimplification time, think about OpenMP/OpenACC > offloading, the target before IPA optimizations might not be the target > after them, while they have to agree on ABI issues, the optabs definitely > can be and are different and these optabs originally added for the > vectorizer are something that doesn't have a fallback, whatever introduces > it into the IL is responsible for verification it is supported. Ah, I was missing this. And I don't see why we should keep it that way. As long as the vectorizer was the only producer, it made sense not to have a fallback, it was not needed. But now that we are talking of having the user produce it almost directly, it would make sense for it to behave like other vector operations (say PLUS_EXPR). > That said, not sure if e.g. using an opaque builtin for the conversion that > supportable_convert_operation sometimes uses is better over this ifn. > What exact optimization opportunities you are looking for if it is lowered > earlier? I have the VECTOR_CST folding in place... I don't know, any kind of optimization we currently do on scalars... For conversions between integers and floats, that seems to be very limited, maybe combine consecutive casts in rare cases. For sign changes, we have a number of transformations in match.pd that are fine with an intermediate cast that only changes the sign (I even introduced nop_convert to handle vectors at the same time). I guess we could handle this IFN as well. It is just that having 2 ways to express the same thing tends to cause code duplication. On the other hand, for narrowing/widening conversions, keeping it as one stmt with your ifn may be more convenient to optimize than a large mess of VEC_UNPACK_FLOAT_HI_EXPR and friends. Again I am thinking more of match.pd type of transformation, nothing that looks at the target. -- Marc Glisse