From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 57196 invoked by alias); 4 Sep 2018 20:50:05 -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 57170 invoked by uid 89); 4 Sep 2018 20:50:04 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: NAM02-CY1-obe.outbound.protection.outlook.com Received: from mail-cys01nam02on0061.outbound.protection.outlook.com (HELO NAM02-CY1-obe.outbound.protection.outlook.com) (104.47.37.61) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 04 Sep 2018 20:50:02 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=CAVIUMNETWORKS.onmicrosoft.com; s=selector1-cavium-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JTqpqusl8B28nT4x9JtErg0TcS1jBz1lUZCklKPNWZA=; b=l74On5B8a7CJfBq+JGVrLzEHxwSfs9QYOn7V79MkVMOzfyacugfGjKa1qw3zxTwu5l39U1IZ6LanIe5B10vSxVhslSVu9vOAaUkEgaaPQeX93iVCEkNJmOhlGC8iYD5CFTStCUxtnpKJR+2kVSv26wbXEU8TG+LGTMtp4ZeFzEo= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Steve.Ellcey@cavium.com; Received: from sellcey-dt.caveonetworks.com (50.233.148.155) by BL0PR07MB5025.namprd07.prod.outlook.com (2603:10b6:208:49::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1101.17; Tue, 4 Sep 2018 20:49:56 +0000 Message-ID: <1536094188.7683.69.camel@cavium.com> Subject: Re: [Patch][Aarch64] Implement Aarch64 SIMD ABI and aarch64_vector_pcs attribute From: Steve Ellcey Reply-To: sellcey@cavium.com To: Wilco Dijkstra , Kyrill Tkachov , Segher Boessenkool Cc: gcc-patches , Richard Sandiford , Richard Earnshaw , James Greenhalgh , Marcus Shawcroft , nd Date: Tue, 04 Sep 2018 20:50:00 -0000 In-Reply-To: References: <1533075888.3879.14.camel@cavium.com> <5B61A40E.1040501@foss.arm.com> <1533593632.3879.90.camel@cavium.com> <20180807171509.GH31204@gate.crashing.org> <1534786623.20144.12.camel@cavium.com>,<5B8E6EA3.6020704@foss.arm.com> , Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Return-Path: sellcey@cavium.com Received-SPF: None (protection.outlook.com: cavium.com does not designate permitted sender hosts) X-SW-Source: 2018-09/txt/msg00220.txt.bz2 On Tue, 2018-09-04 at 17:20 +0000, Wilco Dijkstra wrote: > External Email > > Hi Steve, > > The latest version compiles the examples I used correctly, so it looks fine > from that perspective (but see comments below). However the key point of > the ABI is to enable better code generation when calling a vector function, > and that will likely require further changes that may conflict with this patch. > Do you have patches for that work outstanding? It seems best to do this in > one go. > > Also did you check there is no regression in code generation for non-vector > functions? Yes, I checked for regressions in non-vector functions.  They way this is written, there should be zero changes to any generated code that does not involve vector functions. I have some changes to improve code generation for SIMD functions but it is not ready to go yet.  The main change I made to improve code generation is to modify TARGET_HARD_REGNO_CALL_PART_CLOBBERED to accept an instruction pointer so we could check to see if the call being made is to a 'normal' function or a 'simd' function and return the correct value.  Unfortunately, there are many places where we don't have the call insn available and have to make the pessimistic guess. I also changed get_call_reg_set_usage so that it could return different default sets of what registers changed based on whether or not the function being called was normal or simd.  Again, there are some places where we have to make a pessimistic guess. > > > +/* Return 1 if the register is used by the epilogue.  We need to say the > +   return register is used, but only after epilogue generation is complete. > +   Note that in the case of sibcalls, the values "used by the epilogue" are > +   considered live at the start of the called function. > + > +   For SIMD functions we need to return 1 for FP registers that are saved and > +   restored by a function but not zero in call_used_regs.  If we do not do > +   this optimizations may remove the restore of the register.  */ > + > +int > +aarch64_epilogue_uses (int regno) > +{ > +  if (epilogue_completed && (regno) == LR_REGNUM) > +    return 1; > +  if (aarch64_simd_decl_p (cfun->decl) && FP_SIMD_SAVED_REGNUM_P > (regno)) > +    return 1; > +  return 0; > +} > > I'm not convinced this is a good idea. It suggests GCC doesn't have the correct set > of caller/callee-save registers for vector functions (I don't see a change to update > CALL_USED_REGISTERS or aarch64_hard_regno_call_part_clobbered), which could > lead to all kinds of interesting issues. The problem is that there is no single correct set of caller/callee- saved registers anymore.  There is one set for normal functions and a different set for simd functions.  GCC isn't set up to have two different caller/callee saved ABIs on one target, there is only one CALL_USED_REGISTERS macro used to set one call_used_regs array.  Should V16-V23 be set in CALL_USED_REGISTERS?  For 'normal' functions, yes.  For SIMD functions, no. > > +/* Return false for non-leaf SIMD functions in order to avoid > +   shrink-wrapping them.  Doing this will lose the necessary > +   save/restore of FP registers.  */ > + > +bool > +aarch64_use_simple_return_insn_p (void) > +{ > +  if (aarch64_simd_decl_p (cfun->decl) && !crtl->is_leaf) > +    return false; > + > +  return true; > +} > > Such as this... > > Wilco