From patchwork Fri Nov 29 12:24:02 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Frederik Harwath X-Patchwork-Id: 1202470 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=209.132.180.131; helo=sourceware.org; envelope-from=gcc-patches-return-514847-incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="keYLrfaF"; dkim-atps=neutral Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 47PYbl1Xjcz9sPv for ; Fri, 29 Nov 2019 23:24:34 +1100 (AEDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:cc:subject:message-id:date:mime-version:content-type :content-transfer-encoding; q=dns; s=default; b=T21qjAqUI1upt4J1 iHerUJVEl+pOFr5WgOJLP2TsbzX+RY+ljDA8NVX6cOfwGBFKz617HnCBSbFKEamS duXWLEge4XbrYeZ6f7Rdq78a9DFGMFgywt9lnwsSka9kbGXH/PK5bcImaCabV7F6 NJ1BrDZIOrCwkYU2t4aRZkrbloY= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:cc:subject:message-id:date:mime-version:content-type :content-transfer-encoding; s=default; bh=Q3eN9H5cisrYPCTC4ULk5a tGPvk=; b=keYLrfaFnITomnJLG9qGSCLy2WXOlKyDLZLYgGHVZdQB4z6MxK1AOk WoQxR3N3IwPf9y55rijUZQk2eSbzxAhFIS/PKAeqsk5WHu6DA5T5czSJuZLnP38d DOo+VsPA6aJkjywVuOzznwFlCN5Lysjs9ClNKdSObm6lxrjtuxapc= Received: (qmail 121763 invoked by alias); 29 Nov 2019 12:24:27 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 121649 invoked by uid 89); 29 Nov 2019 12:24:18 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-19.7 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, SPF_PASS autolearn=ham version=3.3.1 spammy=lie X-HELO: esa3.mentor.iphmx.com Received: from esa3.mentor.iphmx.com (HELO esa3.mentor.iphmx.com) (68.232.137.180) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 29 Nov 2019 12:24:17 +0000 IronPort-SDR: mXlu6+Qas0gksa0Me2mWGYK80fu2S47GJbRZlcVyiwwg+ZSiGFxOrrLlwf4z29shXpiV/943Zt Sq4ljN3mj9zSeTNZ2xW1SuT1ImWxOm1VFknGHhnhkolhv7iaHcnzGDiQDTAF1s/IolBYLXs2f7 aHCq7mUTv4IRm1/dckoebYenr6TjO2k/aaLCW02aHeUve/4KVEqVXKODL8UwnABi7Ikrj6m/IN V99b7k3Pajo1kQ+ovL+/baqo/4azzcqUOLMquXeRidDgvuJmz1WSNuQx1hXVie2SbLsfmSSAw5 gL0= Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa3.mentor.iphmx.com with ESMTP; 29 Nov 2019 04:24:15 -0800 IronPort-SDR: qXnDYrpkXbaXqMOdGCM5PCff+ynco6KEOviV8XdQpg1H0SQvIvxQ58XOAqv5CGQ9b+pVSk9fzd MUETd/oRccbnz0GRSRCUA6UdG8Y7ZFExFxKIw8Kv3ZFBeYK+K4mfhgheMQvcO0vMQCzzyfYbEI Mf/Dmd/xSLy4zgia0hily0X/9i0+7zIjN47wQXH6ONjUwtW+y5TSkCTB+XuP5W4A3AcAlOtxPi Lq8JjrcG7bLUwpzt49CV/uuxdmLBVz8V+uIAeqNCWijtYjOVqquC/YnQRLGlO1rGamkV7tvoPt bPQ= From: "Harwath, Frederik" To: , Jakub Jelinek , CC: , Subject: [PATCH][amdgcn] Fix ICE in re-simplification of VEC_COND_EXPR X-Pep-Version: 2.0 Message-ID: <643ae1a0-ffa2-2004-d186-736c81c6a0d7@codesourcery.com> Date: Fri, 29 Nov 2019 13:24:02 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 X-IsSubscribed: yes Hi, currently, on trunk, the tests gcc.dg/vect/vect-cond-reduc-1.c and gcc.dg/pr68286.c fail when compiling for amdgcn-unknown-amdhsa. The reason seems to lie in the interaction of the changes that have been introduced by revision r276659 ("Allow COND_EXPR and VEC_COND_EXPR condtions to trap" by Ilya Leoshkevich) of trunk and the vectorized code that is generated for amdgcn. If the function maybe_resimplify_conditional_op from gimple-match-head.c gets called on a conditional operation without an "else" part, it makes the operation unconditional, but only if the operation cannot trap. To check this, it uses operation_could_trap_p. This ends up in a violated assertion in the latter function if maybe_resimplify_conditional_op is called on a COND_EXPR or VEC_COND_EXPR: /* This function cannot tell whether or not COND_EXPR and VEC_COND_EXPR could trap, because that depends on the respective condition op. */ gcc_assert (op != COND_EXPR && op != VEC_COND_EXPR); A related issue has been resolved by the patch that was committed as r276915 ("PR middle-end/92063" by Jakub Jelinek). In our case, the error is triggered by the simplification rule at line 3450 of gcc/match.pd: /* A + (B vcmp C ? 1 : 0) -> A - (B vcmp C ? -1 : 0), since vector comparisons return all -1 or all 0 results. */ /* ??? We could instead convert all instances of the vec_cond to negate, but that isn't necessarily a win on its own. */ (simplify (plus:c @3 (view_convert? (vec_cond:s @0 integer_each_onep@1 integer_zerop@2))) (if (VECTOR_TYPE_P (type) && known_eq (TYPE_VECTOR_SUBPARTS (type), TYPE_VECTOR_SUBPARTS (TREE_TYPE (@1))) && (TYPE_MODE (TREE_TYPE (type)) == TYPE_MODE (TREE_TYPE (TREE_TYPE (@1))))) (minus @3 (view_convert (vec_cond @0:0 (negate @1) @2))))) ) It seems that this rule is not invoked when compiling for x86_64 where the generated code for vect-cond-reduc-1.c does not contain anything that would match this rule. Could it be that there is no test covering this rule for commonly tested architectures? I have changed maybe_resimplify_conditional_op to check if a COND_EXPR or VEC_COND_EXPR could trap by checking whether the condition can trap using generic_expr_could_trap_p. Judging from the comment above the assertion and the code changes of r276659, it seems that this is both necessary and sufficient to verify if those expressions can trap. Does that sound reasonable and can the patch be included in trunk? The patch fixes the failing tests for me and does not cause any visible regressions in the results of "make check" which I have executed for targets amdgcn-unknown-amdhsa and x86_64-pc-linux-gnu. Best regards, Frederik 2019-11-28 Frederik Harwath gcc/ * gimple-match-head.c (maybe_resimplify_conditional_op): use generic_expr_could_trap_p to check if the condition of COND_EXPR or VEC_COND_EXPR can trap. --- gcc/gimple-match-head.c | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/gcc/gimple-match-head.c b/gcc/gimple-match-head.c index 2996bade301..4da6c4d7458 100644 --- a/gcc/gimple-match-head.c +++ b/gcc/gimple-match-head.c @@ -144,9 +144,17 @@ maybe_resimplify_conditional_op (gimple_seq *seq, gimple_match_op *res_op, /* Likewise if the operation would not trap. */ bool honor_trapv = (INTEGRAL_TYPE_P (res_op->type) && TYPE_OVERFLOW_TRAPS (res_op->type)); - if (!operation_could_trap_p ((tree_code) res_op->code, - FLOAT_TYPE_P (res_op->type), - honor_trapv, res_op->op_or_null (1))) + tree_code op_code = (tree_code) res_op->code; + /* COND_EXPR and VEC_COND_EXPR will trap if, and only if, the condition + traps and hence we have to check this. For all other operations, we + don't need to consider the operands. */ + bool op_could_trap = op_code == COND_EXPR || op_code == VEC_COND_EXPR ? + generic_expr_could_trap_p (res_op->ops[0]) : + operation_could_trap_p ((tree_code) res_op->code, + FLOAT_TYPE_P (res_op->type), + honor_trapv, res_op->op_or_null (1)); + + if (!op_could_trap) { res_op->cond.cond = NULL_TREE; return false;