From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [IPv6:2a00:1450:4864:20::632]) by sourceware.org (Postfix) with ESMTPS id 4F0273858D33 for ; Wed, 9 Aug 2023 10:23:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4F0273858D33 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-ej1-x632.google.com with SMTP id a640c23a62f3a-99bf9252eddso981077766b.3 for ; Wed, 09 Aug 2023 03:23:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1691576629; x=1692181429; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:cc:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=FBtoHJaN8m5Uo1ZqDJF++QmQZ9qVEGUNX6lFBttzHvs=; b=dRCBsS4XHBEL/WPAzwfc5gbles7o9ZeXYEFchELiuv2iiiRVNdsoQDq4T69dGz/rBd WGX2w+wv9USH46XOb3lrl2AoVt+wl4665TnrC+vLoo11OHe3uSjxDskqUfjPltG7RHi5 4xqLpJOkLcT1+sjkGMFgxKZTwjtdQODuYjToDTGAic6ZKqpC3//8yYl5iyphEK7T4UOd eYOyym9EaIdbeE8PZXmQNhDPWuaDCN14x5BipgwnU8b8ezd9Kg3gHhIB97t6gac9XC+b 33AwzGpgVrz2VZO1YkR4x36jNfT9UYRRpfL4LXonA890VeMB+wnEPRCaUTOm7ILXGrii dlUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691576629; x=1692181429; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:cc:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=FBtoHJaN8m5Uo1ZqDJF++QmQZ9qVEGUNX6lFBttzHvs=; b=LJ0DFEZ0WvUXhVSzLC0WqxiCtOyAgfM0zs/5V9R0SZ/nu0oL06ZH97JLfAnYnZwI3I kp/LRUz6irjepPtvW6zBwMExLwcTBP4HwVfg8cVoA/Z3qMrl/DQ/oQ84WgugFMrxZ/+X 1XCFZMZq3yoJrsmckA5NchbadlgPv0L9KM9IuGi4vkMuGvokD4r7E50X5q4j4vxvogup Qy50tmaAofEmnQuUvqhlQYVeHgm3pEVoAQMQYJQQvxNOJNBL+vZ1wvzkpzCmhxzNnLNc wUs5lYnlfbHQUcerPr2TOxfqRC1fFBpbiKWHaJOGPxEeBj2y1znVM6yIL9bfI47euev5 3n0Q== X-Gm-Message-State: AOJu0YyauIq2qcb2hbjOs02a/OXAxjfK3cLeum6Mepj+ybYGwzAr9DbN YRp/I+cVG7X3TudF99tHi14= X-Google-Smtp-Source: AGHT+IEcZ2wWzSg5rWyk3/lFE5rz3lzelh8lACRDiMx9cnREQOx3vzmwaxu0onQSE8BEYvbdmc6O3A== X-Received: by 2002:a17:906:5307:b0:98d:f4a7:71cf with SMTP id h7-20020a170906530700b0098df4a771cfmr1474362ejo.62.1691576628773; Wed, 09 Aug 2023 03:23:48 -0700 (PDT) Received: from [192.168.1.23] (ip-046-005-130-086.um12.pools.vodafone-ip.de. [46.5.130.86]) by smtp.gmail.com with ESMTPSA id ot29-20020a170906ccdd00b00991d54db2acsm7773003ejb.44.2023.08.09.03.23.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 09 Aug 2023 03:23:48 -0700 (PDT) Message-ID: <8af42de5-c897-aecf-aad4-66f4a80d4551@gmail.com> Date: Wed, 9 Aug 2023 12:23:47 +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, gcc-patches Subject: Re: [PATCH] vect: Add a popcount fallback. To: Richard Biener References: <4d0d53a0-20d2-5b98-c4f9-67b624a27269@gmail.com> <86bb6ae6-1eb5-040a-19ef-bab1e1bc6f4e@gmail.com> <2a568bea-04db-ebd1-8b0d-f2f124f0b183@gmail.com> Content-Language: en-US From: Robin Dapp In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,NICE_REPLY_A,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: > We seem to be looking at promotions of the call argument, lhs_type > is the same as the type of the call LHS. But the comment mentions .POPCOUNT > and the following code also handles others, so maybe handling should be > moved. Also when we look to vectorize popcount (x) instead of popcount((T)x) > we can simply promote the result accordingly. IMHO lhs_type is the type of the conversion lhs_oprnd = gimple_assign_lhs (last_stmt); lhs_type = TREE_TYPE (lhs_oprnd); and rhs/unprom_diff has the type of the call's input argument rhs_oprnd = gimple_call_arg (call_stmt, 0); vect_look_through_possible_promotion (vinfo, rhs_oprnd, &unprom_diff); So we can potentially have T0 arg T1 in = (T1)arg T2 ret = __builtin_popcount (in) T3 lhs = (T3)ret and we're checking if precision (T0) == precision (T3). This will never be true for a proper __builtin_popcountll except if the return value is cast to uint64_t (which I just happened to do in my test...). Therefore it still doesn't really make sense to me. Interestingly though, it helps for an aarch64 __builtin_popcountll testcase where we abort here and then manage to vectorize via vectorizable_call. When we skip this check, recognition succeeds and replaces the call with the pattern. Then scalar costs are lower than in the vectorizable_call case because __builtin_popcountll is not STMT_VINFO_RELEVANT_P anymore (not live or so?). Then, vectorization costs are too high compared to the wrong scalar costs and we don't vectorize... Odd, might require fixing separately. We might need to calculate the scalar costs in advance? > It looks like vect_recog_popcount_clz_ctz_ffs_pattern is specifcally for > the conversions, so your fallback should possibly apply even when not > matching them. Mhm, yes it appears to only match when casting the return value to something else than an int. So we'd need a fallback in vectorizable_call? And it would potentially look a bit out of place there only handling popcount and not ctz, clz, ... Not sure if it is worth it then? Regards Robin