From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-lf1-x134.google.com with SMTP id 2adb3069b0e04-502a4f33440so681113e87.1 for ; Fri, 08 Sep 2023 10:54:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1694195677; x=1694800477; darn=gcc.gnu.org; h=content-transfer-encoding:subject:from:to:content-language:cc :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=oAPP23jJWkwnsJjW24tl46hF7DkYRqlkq0KOX+VQksY=; b=I64flXeyJDKgD+eFIlqPGrKa/xmNc+V/M3Reu8umnqSSHNswn4TiRXLtH4dg5q4p6Q rWYfehCrEAI4X0JDYzgSN9BCSGJsKbtQG8iZH5LpEFU58vWdH+EUpssTIfQE5WE69pOm s+EjqIsZsk8g9aogpqKxsptJOGPPuTioNFI0JFoMA/WR3q5pF0jrIDjb0gfVTg1ax6Ls fjRwg7oV9vzq0+qttTGetO6Fw8AV/nMqZVQp8SbgMmlp/JRqjJb78SNgeL8KbI84mzCT 3A+8t407Gp7AYz/PeinQr+jjhQQsizhTifpvsPbi4d7Idc9WRFLO10bK8XlQvmTGW+0r cBdg== 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 Cc: rdapp.gcc@gmail.com Content-Language: en-US To: gcc-patches From: Robin Dapp Subject: [PATCH] match: Don't sink comparisons into vec_cond operands. Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 List-Id: 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)) -- 2.41.0