From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-1.mimecast.com (us-smtp-1.mimecast.com [205.139.110.61]) by sourceware.org (Postfix) with ESMTP id 1E264386181A for ; Thu, 20 Aug 2020 20:05:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 1E264386181A Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-140-g1ntmrFGN1233YoKBWoGXA-1; Thu, 20 Aug 2020 16:05:02 -0400 X-MC-Unique: g1ntmrFGN1233YoKBWoGXA-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 8F0DD802B49; Thu, 20 Aug 2020 20:05:00 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-113-174.ams2.redhat.com [10.36.113.174]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 3C73B747B0; Thu, 20 Aug 2020 20:04:58 +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 07KK4uad015849; Thu, 20 Aug 2020 22:04:56 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id 07KK4r53015848; Thu, 20 Aug 2020 22:04:53 +0200 Date: Thu, 20 Aug 2020 22:04:53 +0200 From: Jakub Jelinek To: GT Cc: "gcc-patches@gcc.gnu.org" , "segher@kernel.crashing.org" , "dje.gcc@gmail.com" , "wschmidt@linux.ibm.com" , "tuliom@linux.ibm.com" Subject: Re: [RFC PATCH v1 1/1] PPC64: Implement POWER Architecture Vector Function ABI. Message-ID: <20200820200452.GI2363@tucnak> Reply-To: Jakub Jelinek References: <1596832552-111518-1-git-send-email-tnggil@protonmail.com> <20200807205905.GD2363@tucnak> <20200810180725.GA2363@tucnak> <20200813210059.GK2363@tucnak> MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.11.3 (2019-02-01) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Mimecast-Spam-Score: 0.001 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_SHORT, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2020 20:05:07 -0000 On Thu, Aug 20, 2020 at 07:31:50PM +0000, GT wrote: > I'm still trying to understand why we need attribute((target("vsx"))). > > https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#Common-Function-Attributes > > The documentation for target(string) states that the purpose is to allow a function to be > compiled with different target options than were specified on the command line. Why would we > want the vector version of say sinf to be compiled for a different target than the scalar sinf? The scalar sinf (well, better let's talk about some arbitrary user function, sinf or at least the vector versions thereof will be often implemented in assembly) can be compiled with whatever ISA options the user chooses. But, the SIMD ABI says that the 'b' char variants are VSX only, need to pass arguments in certain registers that might not be even available without that ISA, similarly for returns, and per the ABI the callers will ensure such functions are only used from code which assumes that ISA. Have a look at the x86_64 case, we have several different variants there, e.g. SSE2 that passes in registers that are only available in SSE1 and later, then AVX variants which use AVX registers, AVX2 variants which use the same registers but different in he way how integral vectors are passed, and finally AVX512F variants that use AVX512F registers. So, on the caller side among the other desirability checks (if the function is declare simd at all, what vectorization factor is available, whether it is inbranch or notinbranch or both, whether arguments are vectors or uniform or linear etc.), the compiler also checks the ISA. And in loops that aren't even SSE2 (-mno-sse, -msse1) just won't use any of the simd variants and will use always scalar version, in code that isn't -mavx or later will only use SSE2 (or scalar), in code that isn't -mavx2 will only use AVX or SSE2 or scalar, etc. Either one wouldn't be even able to pass the arguments or read the return values without those, or if it would, the ABI still says one can assume such ISA level. This is all implemented by: 1) having the target hook used during the vectorization decision (simd_clone_usable) decide based on the current ISA level 2) on the side of generation of the functions, it checks if the ISA is already available (e.g. from command line), if it is, nothing needs to be done, otherwise target attribute is added. Jakub