From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out2.suse.de (smtp-out2.suse.de [IPv6:2a07:de40:b251:101:10:150:64:2]) by sourceware.org (Postfix) with ESMTPS id B28553858CD1 for ; Wed, 20 Dec 2023 10:07:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B28553858CD1 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de ARC-Filter: OpenARC Filter v1.0.0 sourceware.org B28553858CD1 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a07:de40:b251:101:10:150:64:2 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1703066877; cv=none; b=nJOW4vx6jL3OcqndxPLj84yMVcxVdJcskRuaFXFDTenjvuHD4ptlgzGx15Q4RS2pxlrE/UouQd3ovm1UIhxI7onzYdF9aZez7nj2CVQIZyV+2Ox6IP0goNo3pj9qrqUxTLvvWp+ywgKDEdC6JOAmY7VzouGgAw2WRGIO7bW7kZU= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1703066877; c=relaxed/simple; bh=t5QI6i3DVts7fFA9/031fV0cf5OAPBKNuy3yBmaDmus=; h=DKIM-Signature:DKIM-Signature:DKIM-Signature:DKIM-Signature:Date: From:To:Subject:Message-ID:MIME-Version; b=GTs6FbRM2F2MxLC96RkzpfJpiUharli46e7R9M8N4g0iv2KDkqGCAPWmJgTwJ6SBmHiT2jvAwplM3uJQ4mgI64Dc40m6kOmGFP/pa8xGjU8zL5/lq52sJ3ye8DFG/uR+PkA433wbz2jyWveoUsGz/q7xTT29b9tOTocD3OklhAA= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from [10.168.4.150] (unknown [10.168.4.150]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 55DFF1F826; Wed, 20 Dec 2023 10:07:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1703066874; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=2mUQUvuet2wGuJiS6AInCGHFjzZMrlb4UUexsZUX+YA=; b=VyY0V7WHpLiraCsaWmiPfpFfXgS6cB2vU8BT7Bl9MewLfJiNTIqIuLQg/muhfuRvLQOqFj SmfeGd468swKLj+UsIZ85PGo1L5MFEeQcgkUP4xInGjlu2pn4v4sxhl+yV9gU5K2wJj2XI 1TUJUt8OfgtpupnnOx/n+xb/v80gklw= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1703066874; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=2mUQUvuet2wGuJiS6AInCGHFjzZMrlb4UUexsZUX+YA=; b=mD03rVawHN3LgFscTYlqtdaLyNxp+NBN43LeEXH4H6FdApuFCDqrz8ptKJ0rMvPJpk52bV onbj+FkE2mdP7jAw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1703066874; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=2mUQUvuet2wGuJiS6AInCGHFjzZMrlb4UUexsZUX+YA=; b=VyY0V7WHpLiraCsaWmiPfpFfXgS6cB2vU8BT7Bl9MewLfJiNTIqIuLQg/muhfuRvLQOqFj SmfeGd468swKLj+UsIZ85PGo1L5MFEeQcgkUP4xInGjlu2pn4v4sxhl+yV9gU5K2wJj2XI 1TUJUt8OfgtpupnnOx/n+xb/v80gklw= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1703066874; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=2mUQUvuet2wGuJiS6AInCGHFjzZMrlb4UUexsZUX+YA=; b=mD03rVawHN3LgFscTYlqtdaLyNxp+NBN43LeEXH4H6FdApuFCDqrz8ptKJ0rMvPJpk52bV onbj+FkE2mdP7jAw== Date: Wed, 20 Dec 2023 11:06:42 +0100 (CET) From: Richard Biener To: Richard Sandiford 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]. In-Reply-To: Message-ID: <4060o0r6-4s4p-rrqr-507q-5522q5r71r97@fhfr.qr> References: <097AABD6596FB0C3+2023121906491281154423@rivai.ai> <92p02r8p-46rq-s976-5r8p-s87q0q763465@fhfr.qr> <6FD0A43E2F3E9BD9+202312191735136921653@rivai.ai> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Level: Authentication-Results: smtp-out2.suse.de; none X-Spam-Level: X-Spam-Score: -2.80 X-Spamd-Result: default: False [-2.80 / 50.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_ENVRCPT(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519]; NEURAL_HAM_SHORT(-0.20)[-1.000]; RCPT_COUNT_SEVEN(0.00)[7]; DBL_BLOCKED_OPENRESOLVER(0.00)[suse.de:email,rivai.ai:email,arm.com:email]; FUZZY_BLOCKED(0.00)[rspamd.com]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_CC(0.00)[gmail.com,rivai.ai,gcc.gnu.org,intel.com]; BAYES_HAM(-3.00)[100.00%]; SUSPICIOUS_RECIPS(1.50)[] X-Spam-Status: No, score=-5.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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: On Wed, 20 Dec 2023, Richard Sandiford wrote: > 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. OK, I was thinking of only handling VECTOR_CST_NELTS_PER_PATTERN for example as additional (cheap) heuristic so we put VECTOR_CST_DUPLICATE_P second (this would cover the particular cases in this thread). > >> > > >> > 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. But doesn't this mean we can't rely on folding (match.pd) not seeing un-constant-folded operations and thus proper canonicalization? Which means we'd possibly have to alter _all_ (op X CST) cases to use :c? > Thanks, > Richard > -- Richard Biener SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)