From patchwork Tue Apr 7 02:57:45 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: bule X-Patchwork-Id: 1267141 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org (client-ip=2620:52:3:1:0:246e:9693:128c; helo=sourceware.org; envelope-from=gcc-patches-bounces@gcc.gnu.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=huawei.com Received: from sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 48xBt71fQxz9sP7 for ; Tue, 7 Apr 2020 12:58:05 +1000 (AEST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 26023385DC08; Tue, 7 Apr 2020 02:58:01 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from huawei.com (szxga08-in.huawei.com [45.249.212.255]) by sourceware.org (Postfix) with ESMTPS id 18355385BF83 for ; Tue, 7 Apr 2020 02:57:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 18355385BF83 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=huawei.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=bule1@huawei.com Received: from DGGEML403-HUB.china.huawei.com (unknown [172.30.72.53]) by Forcepoint Email with ESMTP id 2271831594093810CB50 for ; Tue, 7 Apr 2020 10:57:54 +0800 (CST) Received: from DGGEML421-HUB.china.huawei.com (10.1.199.38) by DGGEML403-HUB.china.huawei.com (10.3.17.33) with Microsoft SMTP Server (TLS) id 14.3.487.0; Tue, 7 Apr 2020 10:57:52 +0800 Received: from DGGEML528-MBX.china.huawei.com ([169.254.7.180]) by dggeml421-hub.china.huawei.com ([10.1.199.38]) with mapi id 14.03.0487.000; Tue, 7 Apr 2020 10:57:44 +0800 From: bule To: Martin Jambor Subject: =?utf-8?b?562U5aSNOiBbQUFyY2g2NF1bU1ZFXVtJUEFdIElDRSBjYXVzZWQg?= =?utf-8?q?by_incompatibility_of_SRA_and_svst_builtin-function?= Thread-Topic: [AArch64][SVE][IPA] ICE caused by incompatibility of SRA and svst builtin-function Thread-Index: AdYInsvt/WRtS2T1SqmRvxQkKQUwgf//wiaAgAdOTYCAADx3gA== Date: Tue, 7 Apr 2020 02:57:45 +0000 Message-ID: <8FB10B4CA53A144E918874949D50CEB1022B336A@dggeml528-mbx.china.huawei.com> References: <8FB10B4CA53A144E918874949D50CEB1022B24E3@dggeml528-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.223.175] MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Spam-Status: No, score=-22.1 required=5.0 tests=BAYES_00, BODY_8BITS, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, KAM_DMARC_STATUS, SPF_HELO_PASS, 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: , Cc: "gcc-patches@gcc.gnu.org" Errors-To: gcc-patches-bounces@gcc.gnu.org Sender: "Gcc-patches" Hi, The patch is tested and works fine. It is more appropriate to handle the context by considering it as a section of assemble code. A minor question is that I think svst functions are for store operations. Why pass ISRA_CTX_LOAD to scan_expr_access rather than ISRA_CTX_STORE? Thanks, Bu Le -----邮件原件----- 发件人: Martin Jambor [mailto:mjambor@suse.cz] 发送时间: 2020年4月7日 7:21 收件人: bule 抄送: Richard Biener ; gcc-patches@gcc.gnu.org 主题: Re: [AArch64][SVE][IPA] ICE caused by incompatibility of SRA and svst builtin-function Hi, On Thu, Apr 02 2020, Richard Biener wrote: > On Thu, Apr 2, 2020 at 5:36 AM bule wrote: >> >> Hello, >> >> An Internal Compiler Error(ICE) is found in ipa-sra optimization pass when it handle the argument of internal call svst3 for SVE. >> >> The problem comes from gcc/testsuite/gcc.target/aarch64/sve/acle/asm/st2_bf16.c in the test suit, which can be reduced to flowing code: >> >> #include >> #include >> void st2_bf16_base (svbfloat16x3_t z1, svbool_t p0, bfloat16_t *x0, intptr_t x1) { >> svst3 (p0, x0, z1); >> } >> >> Compiled with -march=armv8.2-a+sve -msve-vector-bits=256 -O2, it will result in a segment fault in IPA-SRA: >> >> > [bule@localhost gcc10_fail]$ gcc st2_bf16.i -o st2_bf16.s -S >> > -march=armv8.2-a+sve -msve-vector-bits=256 -O2 during IPA pass: sra >> > st2_bf16.c: In function ‘st2_bf16_base’: >> > st2_bf16.c:10:1: internal compiler error: Segmentation fault >> > ...... /* omit some stack info here. */ ...... >> > 0xa34f68 call_summary::get_create(cgraph_edge*) >> > ../.././gcc/symbol-summary.h:642 >> > 0xa34f68 record_nonregister_call_use >> > ../.././gcc/ipa-sra.c:1613 >> > 0xa34f68 scan_expr_access >> > ../.././gcc/ipa-sra.c:1781 >> > ...... /* omit some stack info here. */ ...... >> > Please submit a full bug report, >> > with preprocessed source if appropriate. >> > Please include the complete backtrace with any bug report. >> >> Details can be found in PR 94398. >> Similar problem can be found in svst2、svst4 and other functions of this kind. >> >> This problem is cause by "record_nonregister_call_use" function trying to access the call graph edge of an internal call, .MASK_STORE_LANE, which is a NULL pointer. >> >> The reason of stepping into "record_nonregister_call_use" function is that the upper level function "scan_expr_access" considered the "svbfloat16x3_t z1" >> argument as a valid candidate for further optimization. >> >> A simple solution here is to disqualify the candidate at "scan_expr_access" level when the call graph edge is null, which indicates the call is either an internal call or a call with no references. For both case, the further optimization process should stop before it reference a NULL pointer. >> >> A proposed patch is attached. >> >> Any suggestions? > > I think internal calls should be handled like asms which means, lookig > at the source a bit, instead of ISRA_CTX_ARG pass ISRA_CTX_LOAD to > scan_expr_access. > indeed, in this situation it would be best if we simply treated such arguments as loads (from the aggregates). Would the following (only very mildly tested) patch work for you? Thanks, Martin diff --git a/gcc/ipa-sra.c b/gcc/ipa-sra.c index f0ebaec708d..b225af61427 100644 --- a/gcc/ipa-sra.c +++ b/gcc/ipa-sra.c @@ -1870,15 +1870,22 @@ scan_function (cgraph_node *node, struct function *fun) case GIMPLE_CALL: { unsigned argument_count = gimple_call_num_args (stmt); - scan_call_info call_info; + isra_scan_context ctx = ISRA_CTX_ARG; + scan_call_info call_info, *call_info_p = &call_info; call_info.cs = node->get_edge (stmt); - call_info.argument_count = argument_count; + if (!call_info.cs) + { + call_info_p = NULL; + ctx = ISRA_CTX_LOAD; + } + else + call_info.argument_count = argument_count; for (unsigned i = 0; i < argument_count; i++) { call_info.arg_idx = i; scan_expr_access (gimple_call_arg (stmt, i), stmt, - ISRA_CTX_ARG, bb, &call_info); + ctx, bb, call_info_p); } tree lhs = gimple_call_lhs (stmt);