From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 64422 invoked by alias); 16 Feb 2020 20:10:24 -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 64413 invoked by uid 89); 16 Feb 2020 20:10:23 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00,BODY_8BITS,FREEMAIL_FROM,GARBLED_BODY,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.3.1 spammy=powerpc-linux, crucial, sais, 39pm X-HELO: mail-40132.protonmail.ch Received: from mail-40132.protonmail.ch (HELO mail-40132.protonmail.ch) (185.70.40.132) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 16 Feb 2020 20:10:21 +0000 Date: Sun, 16 Feb 2020 20:10:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1581883818; bh=xgA4kjpoEFTAOYxyJ26MFnGFwR+FwrDWhxnWOTHTKYA=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=RR1aiaG/GUuVOSLqFLxsonUysVDaP5tsiMZjahMIdVJ+Ph8mMIrRZgXbosTzFVjj/ EzO3bYrxv87gDP8z7XeVt8AHXztWH0/YBnNK8Y0nNeLMhZivVXMNjzCGk0d2Ve6MQb zsYN8a1c04EnRY90ZHWPxuH9TK2f9rQHv4rplesE= To: Jakub Jelinek From: GT Cc: "gcc-patches@gcc.gnu.org" , Segher Boessenkool , Bill Schmidt , Tulio Magno Quites Machado Filho Reply-To: GT Subject: Re: [RFC PATCH v0] PPC64: Implement POWER Architecure Vector Function ABI. Message-ID: In-Reply-To: <20200214220906.GT17695@tucnak> References: <20200214203856.GS17695@tucnak> <20200214220906.GT17695@tucnak> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2020-02/txt/msg00923.txt.bz2 =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me= ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 On Friday, February 14, 2020 5:09 PM, Jakub Jelinek jakub@redhat.com wrote: > On Fri, Feb 14, 2020 at 10:02:39PM +0000, GT wrote: > > > > > Function rs6000_simd_clone_adjust, even though it's body is empty, > > > > cannot simply be removed. I tried it. It resulted in ICE. In my > > > > view, leaving it empty is preferable to modifying other files > > > > unrelated to rs6000.c in order to avoid having a function whose > > > > body is empty. > > > > > > So shouldn't the callback set target attribute (on definitions) to "v= sx"? > > > > I did consider doing something similar to aarch64_simd_clone_adjust. Bu= t the reason > > Aarch64 has a new attribute aarch64_vector_pcs is that they implemented= a modified > > function calling sequence for vector functions. PPC64 vector functions = use the existing > > function calling sequence spelled out in the 64-bit ELFv2 ABI. So with = no new attribute > > here, the function body ends up empty. > > Have I missed something crucial? > > I haven't seen anything in the patch that would only enable it for ELFv2, > The idea is that the vector functionality defined in the ABI is guaranteed = only on systems that implement the ELFv2 ABI. It's possible that the functionali= ty also works on ELFv1 Big-Endian PPC64. I'll check if that's the case. If so, then= the ABI will need modification. > and while powerpc64le-linux probably assumes TARGET_VSX unconditionally > (haven't verified), powerpc64-linux or powerpc-linux certainly doesn't. > The last function in the patch, rs6000_simd_clone_usable, returns a value t= hat will disable use of vector variants if TARGET_VSX is undefined. > And it is just fine to have the ABI for those pass/return vectors in VSX > registers too, after all, it won't be used if the vectorized caller isn't > TARGET_VSX, Don't quite understand the comment here. Are you stating the possibility of a system that has VSX hardware but does not define macro TARGET_VSX? > the definitions of the declare simd functions could be compiled > with different ISA options. Do you mean the 'b' vs 'c' in the ABI's vector function name mangling? > And, if the ABI sais that the 'b' stuff assumes > certain ISA extensions, if the declare simd function definition is compil= ed > with e.g. -mno-vsx -mno-altivec, it would either not be able to get the > arguments/return values at all, or wouldn't benefit from the ISA guarante= es > the ABI gives to it. > Not sure if you expect a response here. > BTW, in the ABI document there isn't just 'b', but also 'c' ABI, it is > unclear if one needs to always emit both (e.g. like on x86 we emit 'b', '= c', > 'd' and 'e') and then let the vectorized callers choose based on what ISA > options it is compiled with. > The reason 'c' was added to the ABI is this mailing list discussion: https://sourceware.org/ml/libc-alpha/2019-11/msg00765.html As long as 'b' specifies that the VSX functionality is that specified in IS= A v2.07, I suggest that we delete the reference to 'c' in the ABI. Bill, Tulio? Bert.