From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx07-00178001.pphosted.com (mx07-00178001.pphosted.com [185.132.182.106]) by sourceware.org (Postfix) with ESMTPS id BE06F3858C60 for ; Thu, 21 Oct 2021 06:10:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org BE06F3858C60 Received: from pps.filterd (m0046668.ppops.net [127.0.0.1]) by mx07-00178001.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 19L3c9IV007701 for ; Thu, 21 Oct 2021 08:10:26 +0200 Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by mx07-00178001.pphosted.com with ESMTP id 3btywk8y8b-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 21 Oct 2021 08:10:26 +0200 Received: from euls16034.sgp.st.com (euls16034.sgp.st.com [10.75.44.20]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 374B6100034 for ; Thu, 21 Oct 2021 08:10:26 +0200 (CEST) Received: from Webmail-eu.st.com (sfhdag2node2.st.com [10.75.127.5]) by euls16034.sgp.st.com (STMicroelectronics) with ESMTP id 2E89A20FA3D for ; Thu, 21 Oct 2021 08:10:26 +0200 (CEST) Received: from [10.211.1.43] (10.75.127.47) by SFHDAG2NODE2.st.com (10.75.127.5) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Thu, 21 Oct 2021 08:10:25 +0200 Message-ID: <45e3dc11-c387-43df-d469-42ac33086c89@foss.st.com> Date: Thu, 21 Oct 2021 08:10:24 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.1.2 Subject: Re: [Patch][GCC][middle-end] - Lower store and load neon builtins to gimple Content-Language: en-US To: References: <03af9742-ab9e-4885-2782-fb42f61d69ab@arm.com> <4po81q35-5n6r-nq21-337n-5rr0rs3r92s6@fhfr.qr> From: Christophe LYON In-Reply-To: <4po81q35-5n6r-nq21-337n-5rr0rs3r92s6@fhfr.qr> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.75.127.47] X-ClientProxiedBy: SFHDAG2NODE2.st.com (10.75.127.5) To SFHDAG2NODE2.st.com (10.75.127.5) X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.182.1,Aquarius:18.0.790,Hydra:6.0.425,FMLib:17.0.607.475 definitions=2021-10-21_01,2021-10-20_02,2020-04-07_01 X-Spam-Status: No, score=-4.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, KAM_SHORT, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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, 21 Oct 2021 06:10:29 -0000 On 20/10/2021 12:16, Richard Biener via Gcc-patches wrote: > On Wed, 20 Oct 2021, Andre Vieira (lists) wrote: > >> On 27/09/2021 12:54, Richard Biener via Gcc-patches wrote: >>> On Mon, 27 Sep 2021, Jirui Wu wrote: >>> >>>> Hi all, >>>> >>>> I now use the type based on the specification of the intrinsic >>>> instead of type based on formal argument. >>>> >>>> I use signed Int vector types because the outputs of the neon builtins >>>> that I am lowering is always signed. In addition, fcode and stmt >>>> does not have information on whether the result is signed. >>>> >>>> Because I am replacing the stmt with new_stmt, >>>> a VIEW_CONVERT_EXPR cast is already in the code if needed. >>>> As a result, the result assembly code is correct. >>>> >>>> Bootstrapped Regtested on aarch64-none-linux-gnu and no issues. >>>> >>>> Ok for master? If OK can it be committed for me, I have no commit rights. >>> + tree temp_lhs = gimple_call_lhs (stmt); >>> + aarch64_simd_type_info simd_type >>> + = aarch64_simd_types[mem_type]; >>> + tree elt_ptr_type = build_pointer_type (simd_type.eltype); >>> + tree zero = build_zero_cst (elt_ptr_type); >>> + gimple_seq stmts = NULL; >>> + tree base = gimple_convert (&stmts, elt_ptr_type, >>> + args[0]); >>> + new_stmt = gimple_build_assign (temp_lhs, >>> + fold_build2 (MEM_REF, >>> + TREE_TYPE (temp_lhs), >>> + base, >>> + zero)); >>> >>> this now uses the alignment info as on the LHS of the call by using >>> TREE_TYPE (temp_lhs) as type of the MEM_REF. So for example >>> >>> typedef int foo __attribute__((vector_size(N),aligned(256))); >>> >>> foo tem = ld1 (ptr); >>> >>> will now access *ptr as if it were aligned to 256 bytes. But I'm sure >>> the ld1 intrinsic documents the required alignment (either it's the >>> natural alignment of the vector type loaded or element alignment?). >>> >>> For element alignment you'd do sth like >>> >>> tree access_type = build_aligned_type (vector_type, TYPE_ALIGN >>> (TREE_TYPE (vector_type))); >>> >>> for example. >>> >>> Richard. >> Hi, >> >> I'm taking over this patch from Jirui. >> >> I've decided to use the vector type stored in aarch64_simd_type_info, since >> that should always have the correct alignment. >> >> To be fair though, I do wonder whether this is actually needed as is right >> now, since the way we cast the inputs and outputs of these __builtins in >> arm_neon.h prevents these issues I think, but it is more future proof. Also >> you could argue people could use the __builtins directly, though I'd think >> that would be at their own risk. >> >> Is this OK? > Yes, this variant looks OK. Hi Andre, These new tests fail on aarch64_be: gcc.target/aarch64/fmla_intrinsic_1.c scan-assembler-times fmadd\\td[0-9]+, d[0-9]+, d[0-9]+, d[0-9]+ 2 gcc.target/aarch64/fmla_intrinsic_1.c scan-assembler-times fmla\\tv[0-9]+.2d, v[0-9]+.2d, v[0-9]+.d\\[[0-9]+\\] 2 gcc.target/aarch64/fmls_intrinsic_1.c scan-assembler-times fmls\\tv[0-9]+.2d, v[0-9]+.2d, v[0-9]+.d\\[[0-9]+\\] 2 gcc.target/aarch64/fmls_intrinsic_1.c scan-assembler-times fmsub\\td[0-9]+, d[0-9]+, d[0-9]+, d[0-9]+ 2 gcc.target/aarch64/fmul_intrinsic_1.c scan-assembler-times fmul\\td[0-9]+, d[0-9]+, d[0-9]+ 2 gcc.target/aarch64/fmul_intrinsic_1.c scan-assembler-times fmul\\tv[0-9]+.2d, v[0-9]+.2d, v[0-9]+.d\\[[0-9]+\\] 2 I've also noticed that: FAIL: gcc.target/aarch64/vect-vca.c execution test on aarch64 with -mabi=ilp32 Christophe > >> Kind regards, >> Andre >>