From patchwork Wed May 5 13:50:31 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Tobias Burnus X-Patchwork-Id: 1474330 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=) 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 4FZyln29CMz9sCD for ; Wed, 5 May 2021 23:50:44 +1000 (AEST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 50FE8385742B; Wed, 5 May 2021 13:50:41 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from esa1.mentor.iphmx.com (esa1.mentor.iphmx.com [68.232.129.153]) by sourceware.org (Postfix) with ESMTPS id 7BB2F3857414 for ; Wed, 5 May 2021 13:50:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 7BB2F3857414 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=Tobias_Burnus@mentor.com IronPort-SDR: Kxs2GIns+x9JkM1ncazyOSQM//mPa13bdbM7jjc0xiIsUTjyStaxy9A6uKJEVFcGjrb/b1KbwE qICR/GCxg00eltrDxdtllOYokN9XXb/SIuKF8BGK2eDtySL/U+Fst5Nyi1jWixFmlbAR2BhTcQ W3ONpIXeXfHWH8iP8493+AStR2weceYr+ggDyfIhaknKuIRTE2f7N0gSDXfprvvPmsV9fy2CZK xpwxcZ390iv7Iv8MuWpGoyZFnJsMdB8Pmf3VL7qLrWbHGki7gJGvkWMZKhTyYjna2PjFSpgLa3 3/Q= X-IronPort-AV: E=Sophos;i="5.82,275,1613462400"; d="diff'?scan'208";a="63254103" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa1.mentor.iphmx.com with ESMTP; 05 May 2021 05:50:36 -0800 IronPort-SDR: +X7aq8rgwjAQr/ddnMVGuDi4ULOafLSV7KUQZ+AjcarvDwHgM3wHLdIXffValim1r3+/0DzuU5 Vc0pNjne1A4vj9veRWDkcoc3pHBtA87QaxuYBhZKIXH51tLq2/sSLq/GgHy8bHGcN/4CvrSHXm oLFLHU7kIpmKikQU4KPcc0hvrWpZE/Ly4r113aIVy88cra0ktSf5Ob8E17ksoc6iWx3L8agj1E cB38JB2Nt2pJX/B8VYjmKDnkJVErAUpRYBZcOsvkUKf1uYDO7XZuFlmLDdoHN0Ngpgq/HVOYGw Vks= To: Eric Botcazou , gcc-patches , Andrew Stubbs , Jakub Jelinek From: Tobias Burnus Subject: [Patch?][RFC][RTL] clobber handling & buildin expansion - missing insn_invalid_p call [PR100418] Message-ID: <968cb4a4-ff85-ebaa-6cd2-98ebe9851f6c@codesourcery.com> Date: Wed, 5 May 2021 15:50:31 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 Content-Language: en-US X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: SVR-IES-MBX-07.mgc.mentorg.com (139.181.222.7) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-Spam-Status: No, score=-11.9 required=5.0 tests=BAYES_00, GIT_PATCH_0, HEADER_FROM_DIFFERENT_DOMAINS, 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: , Errors-To: gcc-patches-bounces@gcc.gnu.org Sender: "Gcc-patches" Hi Eric, hi all, currently, gcn (amdgcn-amdhsa) bootstrapping fails as Alexandre's patch to __builtin_memset (applied yesterday) now does more expansions. The problem is [→ PR100418] (set(reg:DI)(plus:DI(reg:DI)(const_int))) [= "adddi3"] This fails with gcn as gcn has two clobbers for "adddi3" - and when expand_insn is called, INSN_CODE == -1 via: icode = recog_memoized (insn); alias INSN_CODE (insn) = recog (PATTERN (insn), insn, 0); As the "int *pnum_clobber" argument is NULL (well, '0'), the clobbers are not available - which causes the pattern fail. I think that's a general issue with the RTX code generated by builtins.c – except that most targets either do not have clobbers for the used operators — or the code is by chance fixed: For instance, I see that several "if" blocks being processed in recog.c's insn_invalid_p via 'cleanup_cfg (CLEANUP_NO_INSN_DEL)'; the innermost parts of the call chain are: apply_change_group → verify_changes → insn_invalid_p * * * The attached patch seems to solve the GCN issue. Does it look OK? Or does the insn_invalid_p call come too late? If so, any suggestion where it would fit best? Tobias, who is more a FE and early-ME person. ----------------- Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Frank Thürauf extract_insn: Call insn_invalid_p is insn cannot be found. gcc/ChangeLog: * recog.c (extract_insn): Call insn_invalid_p if recog_memoized did not find the insn. diff --git a/gcc/recog.c b/gcc/recog.c index eb617f11163..4ddc5d185af 100644 --- a/gcc/recog.c +++ b/gcc/recog.c @@ -2766,6 +2766,8 @@ extract_insn (rtx_insn *insn) and get the constraints. */ icode = recog_memoized (insn); + if (icode < 0 && !insn_invalid_p (insn, false)) + icode = INSN_CODE (insn); if (icode < 0) fatal_insn_not_found (insn);