From patchwork Fri Sep 8 17:54:35 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Robin Dapp X-Patchwork-Id: 75556 Return-Path: X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 080773858C60 for ; Fri, 8 Sep 2023 17:55:09 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 080773858C60 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1694195709; bh=oAPP23jJWkwnsJjW24tl46hF7DkYRqlkq0KOX+VQksY=; h=Date:To:Subject:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:From; b=E4APRCWhzkJxe0UQmdCavmjSMrZyL45I7jpmBrRXnekvJo5ZaF/fRKHsAK+ZBtBCv 1DlznONJdlgm9OzajIMr57VCmEQKtQV7AghZFitvRlTI4WlkoUP2I3egYEsH+/22Em Av8taNcWGHZoqN23jaZNW3G9uYHCZdCs+75Q4Ht4= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) by sourceware.org (Postfix) with ESMTPS id 529C33858D1E for ; Fri, 8 Sep 2023 17:54:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 529C33858D1E Received: by mail-lf1-x134.google.com with SMTP id 2adb3069b0e04-502a4f33440so681113e87.1 for ; Fri, 08 Sep 2023 10:54:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694195677; x=1694800477; h=content-transfer-encoding:subject:from:to:content-language:cc :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=oAPP23jJWkwnsJjW24tl46hF7DkYRqlkq0KOX+VQksY=; b=GtPovnaEwKZQjOvTZKk2VG42WhoVzpj7n0OEQ5K2Eh9pJxYGzR47qNCdHgxRKHuQFJ b/9nXofwNC1PZFCVtOAEnc5qNgHlvgsF80ajJCAeIxDpZL2YXLmSPGm8LuCcP0Ci4LW8 asqsPxMn38B8gmUegXCy4r6GmSLwqbtuJG1Gg1K2R6GE8qNmott87JXywQ8WzefScw/U 0bC06CTOx9xAHigBmkpuw0g7/aZ/69enMTTnPObbiRQdTh0MmvzcwHWI5iwqgdn27qqN 9Evt79yIlyXqYEW6roiyph6Kit3mM1HmjvbJBXjjHxCLRQGZWu9+wTtYxvh91Tbz1eQC xq/Q== X-Gm-Message-State: AOJu0YxicPw+jtWfWMVqSd4UoVISiwGsMPd9bc7qA5ESnVFNGynd2lDf 6uWFE2U5Z0tTSxqNS8Z0bS0sBBA/lsHeGQ== X-Google-Smtp-Source: AGHT+IG/4YCZMoPVsp5oJ/xKF0CT6BWmM9JHRVVVhau0062+5BSfKHQXDSbkZaPR3bnn2ViGLwnPxA== X-Received: by 2002:a05:6512:10cc:b0:500:a396:b2e4 with SMTP id k12-20020a05651210cc00b00500a396b2e4mr2734304lfg.58.1694195677059; Fri, 08 Sep 2023 10:54:37 -0700 (PDT) Received: from [192.168.1.24] (ip-046-005-130-086.um12.pools.vodafone-ip.de. [46.5.130.86]) by smtp.gmail.com with ESMTPSA id s6-20020aa7c546000000b00521953ce6e0sm1286723edr.93.2023.09.08.10.54.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 08 Sep 2023 10:54:36 -0700 (PDT) Message-ID: <368038d2-e7a3-522d-18d1-6b04fa182896@gmail.com> Date: Fri, 8 Sep 2023 19:54:35 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Content-Language: en-US To: gcc-patches Subject: [PATCH] match: Don't sink comparisons into vec_cond operands. X-Spam-Status: No, score=-9.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Patchwork-Original-From: Robin Dapp via Gcc-patches From: Robin Dapp Reply-To: Robin Dapp Errors-To: gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org Sender: "Gcc-patches" Hi, on riscv gcc.dg/pr70252.c ICEs at gimple-isel.cc:283. This is because we created the gimple statement mask__7.36_170 = VEC_COND_EXPR ; during vrp2. What happens is that, starting with maskdest = (vec_cond mask1 1 0) >= (vec_cond mask2 1 0) we fold to maskdest = mask1 >= (vec_cond (mask2 1 0)) and then sink the "mask1 >=" into the vec_cond so we end up with maskdest = vec_cond (mask2 ? mask1 : 0), i.e. a vec_cond with a mask "data mode". In gimple-isel, when the target does not provide a vcond_mask implementation for that (which none does) we fail the assertion that the mask mode be MODE_VECTOR_INT. To prevent this, this patch restricts the match.pd sinking pattern to non-mask types. I was also thinking about restricting the type of the operands, wondering if that would be less intrusive. Bootstrapped and regression-tested on x86 and aarch64. Regards Robin gcc/ChangeLog: PR target/111337 * match.pd: Do not sink comparisons into vec_conds when the type is a vector mask. --- gcc/match.pd | 24 +++++++++++++++++++++++- 1 file changed, 23 insertions(+), 1 deletion(-) diff --git a/gcc/match.pd b/gcc/match.pd index 8c24dae71cd..db3e698f471 100644 --- a/gcc/match.pd +++ b/gcc/match.pd @@ -4856,7 +4856,7 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT) (vec_cond @0 (view_convert! @1) (view_convert! @2)))) /* Sink binary operation to branches, but only if we can fold it. */ -(for op (tcc_comparison plus minus mult bit_and bit_ior bit_xor +(for op (plus minus mult bit_and bit_ior bit_xor lshift rshift rdiv trunc_div ceil_div floor_div round_div trunc_mod ceil_mod floor_mod round_mod min max) /* (c ? a : b) op (c ? d : e) --> c ? (a op d) : (b op e) */ @@ -4872,6 +4872,28 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT) (op @3 (vec_cond:s @0 @1 @2)) (vec_cond @0 (op! @3 @1) (op! @3 @2)))) +/* Comparison sinks might be folded into vector masks which could + end up as "data" operand of a vec_cond + e.g. (vec_cond @0 (mask1) (...)). + gimple-isel does not handle such cases if the target does not provide + a vcond_mask. Therefore, restrict the operands to non-mask classes. */ +(for op (tcc_comparison) +/* (c ? a : b) op (c ? d : e) --> c ? (a op d) : (b op e) */ + (simplify + (op (vec_cond:s @0 @1 @2) (vec_cond:s @0 @3 @4)) + (if (GET_MODE_CLASS (TYPE_MODE (type)) != MODE_VECTOR_BOOL) + (vec_cond @0 (op! @1 @3) (op! @2 @4)))) + +/* (c ? a : b) op d --> c ? (a op d) : (b op d) */ + (simplify + (op (vec_cond:s @0 @1 @2) @3) + (if (GET_MODE_CLASS (TYPE_MODE (type)) != MODE_VECTOR_BOOL) + (vec_cond @0 (op! @1 @3) (op! @2 @3)))) + (simplify + (op @3 (vec_cond:s @0 @1 @2)) + (if (GET_MODE_CLASS (TYPE_MODE (type)) != MODE_VECTOR_BOOL) + (vec_cond @0 (op! @3 @1) (op! @3 @2))))) + #if GIMPLE (match (nop_atomic_bit_test_and_p @0 @1 @4) (bit_and (convert?@4 (ATOMIC_FETCH_OR_XOR_N @2 INTEGER_CST@0 @3))