From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 82264 invoked by alias); 3 Jan 2019 11:04:22 -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 82254 invoked by uid 89); 3 Jan 2019 11:04:22 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS autolearn=no version=3.3.2 spammy=somewhere X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 03 Jan 2019 11:04:21 +0000 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 706BC5D605; Thu, 3 Jan 2019 11:04:19 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-116-18.ams2.redhat.com [10.36.116.18]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E4DC25C223; Thu, 3 Jan 2019 11:04:18 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id x03B4F51021781; Thu, 3 Jan 2019 12:04:15 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id x03B4CiT021780; Thu, 3 Jan 2019 12:04:12 +0100 Date: Thu, 03 Jan 2019 11:04:00 -0000 From: Jakub Jelinek To: gcc-patches@gcc.gnu.org Cc: Richard Biener , Richard Sandiford , Jason Merrill , "Joseph S. Myers" , Jan Hubicka Subject: Re: [PATCH] Add __builtin_convertvector support (PR c++/85052) Message-ID: <20190103110412.GO30353@tucnak> Reply-To: Jakub Jelinek References: <20190103100640.GM30353@tucnak> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-IsSubscribed: yes X-SW-Source: 2019-01/txt/msg00092.txt.bz2 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. It could be done in some post-IPA pass, perhaps by just calling from somewhere else the tree-vect-generic.c function added in the patch, maybe with a special argument that would do it only for the single op cases and not for the others. 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... > before we start optimizing, without checking if it is supported by the > target (generic lowering can fix that up later). Of course that can be > changed later, getting the basic functionality comes first. Jakub