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 095873857BAE for ; Wed, 20 Dec 2023 09:33:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 095873857BAE 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 095873857BAE 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=1703064790; cv=none; b=skQ2BymYsC0YZw3Kj4s0Ey+a7mwecqMOPCE/2E+r7ohsXhKYi88NZTgBXHD6PceBfFKXRNEl6lbl88ia9kMwayG4Dj99OjuCgwZsO2IGwnQkm9v5PAjhCFPvClpMstFghztdZU7Cc5hKPle2OEFRxb4O1Wtav+baFGpO5JvYhfs= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1703064790; c=relaxed/simple; bh=zY4qIDcI/F6fxjtmMrF5cYyGikGY/9OwtU9Z+0jg01I=; h=From:To:Subject:Date:Message-ID:MIME-Version; b=CtQdsckFj1mCjNL/HkS6egT3g1UJC5x+eHVSGxWdUU//awwaw96dFPKq/e3hQvrcJ15BeQ6ZTt22mVRk3mXno4bMNpbK+WBVwYQg9iy4PG+e1FjfbqEA/pLPI2C6YweLSkdhaxDzLPH9kihdt78S2JjI0LMUIEoYVGN7nY11q+A= 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 57BC71FB; Wed, 20 Dec 2023 01:33:53 -0800 (PST) Received: from localhost (e121540-lin.manchester.arm.com [10.32.110.72]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 947393F64C; Wed, 20 Dec 2023 01:33:07 -0800 (PST) From: Richard Sandiford To: Richard Biener Mail-Followup-To: Richard Biener ,Andrew Pinski , "juzhe.zhong\@rivai.ai" , Robin Dapp , gcc-patches , "pan2.li" , Richard Biener , richard.sandiford@arm.com Cc: Andrew Pinski , "juzhe.zhong\@rivai.ai" , Robin Dapp , gcc-patches , "pan2.li" , Richard Biener Subject: Re: [PATCH] fold-const: Handle AND, IOR, XOR with stepped vectors [PR112971]. References: <097AABD6596FB0C3+2023121906491281154423@rivai.ai> <92p02r8p-46rq-s976-5r8p-s87q0q763465@fhfr.qr> <6FD0A43E2F3E9BD9+202312191735136921653@rivai.ai> Date: Wed, 20 Dec 2023 09:33:06 +0000 In-Reply-To: (Richard Biener's message of "Wed, 20 Dec 2023 08:25:54 +0100 (CET)") 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=-15.6 required=5.0 tests=BAYES_00,KAM_DMARC_NONE,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE 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: Richard Biener writes: > On Tue, 19 Dec 2023, Andrew Pinski wrote: > >> On Tue, Dec 19, 2023 at 2:40?AM Richard Sandiford >> wrote: >> > >> > Richard Biener writes: >> > > On Tue, 19 Dec 2023, juzhe.zhong@rivai.ai wrote: >> > > >> > >> Hi, Richard. >> > >> >> > >> After investigating the codes: >> > >> /* Return true if EXPR is the integer constant zero or a complex constant >> > >> of zero, or a location wrapper for such a constant. */ >> > >> >> > >> bool >> > >> integer_zerop (const_tree expr) >> > >> { >> > >> STRIP_ANY_LOCATION_WRAPPER (expr); >> > >> >> > >> switch (TREE_CODE (expr)) >> > >> { >> > >> case INTEGER_CST: >> > >> return wi::to_wide (expr) == 0; >> > >> case COMPLEX_CST: >> > >> return (integer_zerop (TREE_REALPART (expr)) >> > >> && integer_zerop (TREE_IMAGPART (expr))); >> > >> case VECTOR_CST: >> > >> return (VECTOR_CST_NPATTERNS (expr) == 1 >> > >> && VECTOR_CST_DUPLICATE_P (expr) >> > >> && integer_zerop (VECTOR_CST_ENCODED_ELT (expr, 0))); >> > >> default: >> > >> return false; >> > >> } >> > >> } >> > >> >> > >> I wonder whether we can simplify the codes as follows :? >> > >> if (integer_zerop (arg1) || integer_zerop (arg2)) >> > >> step_ok_p = (code == BIT_AND_EXPR || code == BIT_IOR_EXPR >> > >> || code == BIT_XOR_EXPR); >> > > >> > > Possibly. I'll let Richard S. comment on the whole structure. >> > >> > The current code is handling cases that require elementwise arithmetic. >> > ISTM that what we're really doing here is identifying cases where >> > whole-vector arithmetic is possible instead. I think that should be >> > a separate pre-step, rather than integrated into the current code. >> > >> > Largely this would consist of writing out match.pd-style folds in >> > C++ code, so Andrew's fix in comment 7 seems neater to me. >> >> I didn't like the change to match.pd (even with a comment on why) >> because it violates the whole idea behind canonicalization of >> constants being 2nd operand of commutative and comparison expressions. >> Maybe there are only a few limited match/simplify patterns which need >> to add the :c for constants not being the 2nd operand but there needs >> to be a comment on why :c is needed for this. > > Agreed. Note that in theory we of course could define extra > canonicalization rules for CST op CST in tree_swap_operands_p, > there are some cases those surivive, mostly around FP and > dynamic rounding state. I'd rather go that route if we decide > that match.pd should catch this. I don't think that'll help in all cases though. E.g. consider an unfoldable: (or 1 CST) where CST is "complicated". We'd probably canonicalise that to: (or CST 1) And that's good if we have: (or (or CST 1) 2) since it could be folded to: (or CST 3) But there are other constants CST2 for which (or CST CST2) is foldable and (op 1 CST2) isn't. So: (or (or 1 CST) CST2) would sometimes be foldable in cases where: (or (or CST 1) CST2) isn't. >> > >> > But if this must happen in const_binop instead, then we could have >> > a function like: >> >> The reasoning of why it should be in const_binop rather than in match >> is because both operands are constants. > > +1 I can see that argument for the traditional case where all constants can be folded at compile time. But that isn't the case for VLA constants. (op CST1 CST2) is sometimes not knowable at compile time. And I think match.pd should apply to those cases just as much as to (op VAR CST). VLA vector "constants" are really in intermediate category between variable and constant. The approach that the patch takes is to add a "rule of thumb" that applies to all (op X CST), regardless of whether X is constant. It doesn't work by doing constant arithmetic per se. If we add those rules of thumb here, I think it'll keep growing and growing. Thanks, Richard