From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id BF8DC3858C35 for ; Tue, 17 Oct 2023 16:05:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org BF8DC3858C35 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=arm.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org BF8DC3858C35 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=217.140.110.172 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1697558717; cv=none; b=HoOMex0kiWOTRo7re6q0BX12slpJ7fjDugjLihOe/fN4qOEiXkAw5G6CO37uSrqaCbbUwiNmMqVedu2n3Hk5MfdLWO0rXaNNf8lHZCSqi1EO5T889bhiK9U+d6BhrMDniLxO/xZMUGIWJKmhYeUfCNi2uQrBiGis435ClR31lY0= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1697558717; c=relaxed/simple; bh=Td6c2kcq8NY2gW40kD2e+batyvwAmQvaXtegJFclEzU=; h=From:To:Subject:Date:Message-ID:MIME-Version; b=qEYl6hLanFgB1eb7U0BiOtfb5JaQCv/aOo6RZa8uExfShSq9GGcqQ6x8h/2eiZLoqDWO2mHvELD0qND7gddKcniS0fDYe/iWaSav6KGlUIZBqbRiDPkzPi5YahD4m3gIJTvxdeJKSxb1sTS/Wz6NYZ7zGN7D1MDPXEupUNP64oI= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id E32C12F4; Tue, 17 Oct 2023 09:05:55 -0700 (PDT) Received: from localhost (unknown [10.32.110.65]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id B15A03F762; Tue, 17 Oct 2023 09:05:14 -0700 (PDT) From: Richard Sandiford To: Robin Dapp Mail-Followup-To: Robin Dapp ,Richard Biener , Robin Dapp via Gcc-patches , richard.sandiford@arm.com Cc: Richard Biener , Robin Dapp via Gcc-patches Subject: Re: [PATCH] gimple-match: Do not try UNCOND optimization with COND_LEN. References: <4b77e155-0936-67d6-ab2d-ae7ef49bfde0@gmail.com> <4afb967d-96ea-7e74-1a35-c86aa5a5ffa6@gmail.com> <38b16b69-1b82-420c-839b-d82278515f10@gmail.com> <03a8c49e-af19-4b38-966b-e9ddae4863f5@gmail.com> <6b71858f-51d1-4e23-879c-d3cb19778ed9@gmail.com> Date: Tue, 17 Oct 2023 17:05:13 +0100 In-Reply-To: <6b71858f-51d1-4e23-879c-d3cb19778ed9@gmail.com> (Robin Dapp's message of "Tue, 17 Oct 2023 17:42:11 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-18.1 required=5.0 tests=BAYES_00,KAM_DMARC_NONE,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Robin Dapp writes: > Thank you for the explanation. > > So, assuming I added an IFN_VCOND_MASK and IFN_VCOND_MASK_LEN along > with the respective helper and expand functions, what would be the > way forward? IMO it'd be worth starting with the _LEN form only. > Generate an IFN_VCOND_MASK(_LEN) here instead of a VEC_COND_EXPR? > How would I make sure all of match.pd's vec_cond optimizations > applied to it as well? I think the most important ones are: /* Simplify: a = a1 op a2 r = c ? a : b; to: r = c ? a1 op a2 : b; if the target can do it in one go. This makes the operation conditional on c, so could drop potentially-trapping arithmetic, but that's a valid simplification if the result of the operation isn't needed. Avoid speculatively generating a stand-alone vector comparison on targets that might not support them. Any target implementing conditional internal functions must support the same comparisons inside and outside a VEC_COND_EXPR. */ It would be nice if there was some match.pd syntax that automatically extended these rules to IFN_VCOND_MASK_LEN, but I don't know how easy that would be, due to the extra two parameters. Perhaps that itself could be done in gimple-match-exports.cc, in a similar way to the current conditional stuff. That is: - for IFN_VCOND_MASK_LEN, try folding as a VEC_COND_EXPR and then "adding the length back" - for IFN_COND_LEN_FOO, try folding as an IFN_COND_FOO and then "add the length back" Not sure how important the second one is. Thanks, Richard > Right now AFAIK IFN_VCOND_MASK only gets created in isel and > everything is just a VEC_COND before. But that does not provide > length masking so is not the way to go? > > Thanks. > > Regards > Robin