From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) by sourceware.org (Postfix) with ESMTPS id 498683858439 for ; Wed, 20 Dec 2023 07:27:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 498683858439 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 498683858439 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=195.135.223.130 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1703057229; cv=none; b=tF5VEkxa4mMt00j5OlIOlKy5f3R5DLvLEPJUZd3wNiwtdUzbv2DsxlFAPwv8V1E0w0qzNryvBvcgM7OCQjfEATMuO2vu7BmlUehmoEo2TFqCVi/hr0GQAkyQnbNAfbjtj8NVlarXcwehig3et4bXFd22b3A5fsD4MRfh/N0n5wo= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1703057229; c=relaxed/simple; bh=ajcHIHIcyF7hkeCtYNJ/9/zrCSwgZDID4zHGRf2htlE=; h=DKIM-Signature:DKIM-Signature:DKIM-Signature:DKIM-Signature:Date: From:To:Subject:Message-ID:MIME-Version; b=svTpXDeAjDz0D1a0gzV+ifU3uDABY/+ZHX7Gxtamy8tlDO/u7Nk6WTpgYDGyxguNYfKi4bTty/k4tWM7XiUhMaKfpW5njy69+x2qQ7mEserZ+ErAXzZ14KcOvTbRNZp3TbAMQkLjI4gET2lyDRw4XJ32uOg8AVJyizYJOvlyMRc= 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-out1.suse.de (Postfix) with ESMTPS id DD68E21EE2; Wed, 20 Dec 2023 07:27:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1703057226; 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=qlS7MGxMATrud4JeP5DKz6W8AfPaLwJZL3SX7ZjZyGY=; b=nsdWzFhrNBX4MxHnvkVIXw7xT7JnDpN6tdTHIlNAQjZ4pCY8GY1kA6feQR7F94oJcQcqQY 6BUsNBEnSAlgW9gmTrw+M2y1jpbzdNZZVap7fBptKF3Hh5CcuaXE7nx08zDvlfeuBxmpnm 5u78A9WmIGpu+ogFOxqrs+S20q97eak= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1703057226; 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=qlS7MGxMATrud4JeP5DKz6W8AfPaLwJZL3SX7ZjZyGY=; b=nai8EoSl7drZKLvrU4VnBr/ODfgVOU0kSLVtvvwOks5LqDUQPKZJB82awlVToDvWgh4waR sAdm4eeuP8gIltBA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1703057225; 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=qlS7MGxMATrud4JeP5DKz6W8AfPaLwJZL3SX7ZjZyGY=; b=sqPzucke/X0pUw5z7eWsWfnGxNpgE5doh/EamInWnevMfmOVj8IXjjq9pXmbR0exwx7i7m brFQtyGmbSUINvldENF1+5W3Yd5/bFfKuzwswzaCy3qs1WIQKYEKgDyUTXAbDblKrISv/R Em4sbOwUXFBkDlpKqRYz2IiFP7Mz6uE= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1703057225; 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=qlS7MGxMATrud4JeP5DKz6W8AfPaLwJZL3SX7ZjZyGY=; b=FOsEc4m4H+kwNQ/MoeeqABaik8ezfSuWgtGRpUM2+aaQ1rb0LlqXdq4z6fJYW39b2s5Hx9 xmgwJSN8vPFJ18Ag== Date: Wed, 20 Dec 2023 08:25:54 +0100 (CET) From: Richard Biener To: Andrew Pinski cc: "juzhe.zhong@rivai.ai" , Robin Dapp , gcc-patches , "pan2.li" , Richard Biener , richard.sandiford@arm.com Subject: Re: [PATCH] fold-const: Handle AND, IOR, XOR with stepped vectors [PR112971]. In-Reply-To: Message-ID: 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-out1.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)[]; BAYES_HAM(-3.00)[100.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)[0.0.0.2:email,rivai.ai:email,gcc.target:url,suse.de:email,0.0.0.1:email]; FREEMAIL_TO(0.00)[gmail.com]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_CC(0.00)[rivai.ai,gmail.com,gcc.gnu.org,intel.com,arm.com]; FUZZY_BLOCKED(0.00)[rspamd.com]; SUSPICIOUS_RECIPS(1.50)[] X-Spam-Status: No, score=-11.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,KAM_SHORT,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 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. > > > > 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 Richard. > Now for commutative expressions, we only need to check the first > operand for zero/all_ones and try again swapping the operands. This > will most likely solve the problem of writing so much code. > We could even use lambdas to simplify things too. > > Thanks, > Andrew Pinski > > > > > /* OP is the INDEXth operand to CODE (counting from zero) and OTHER_OP > > is the other operand. Try to use the value of OP to simplify the > > operation in one step, without having to process individual elements. */ > > tree > > simplify_const_binop (tree_code code, rtx op, rtx other_op, int index) > > { > > ... > > } > > > > Thanks, > > Richard > > > > > > > > Richard. > > > > > >> > > >> > > >> > > >> juzhe.zhong@rivai.ai > > >> > > >> From: Richard Biener > > >> Date: 2023-12-19 17:12 > > >> To: juzhe.zhong@rivai.ai > > >> CC: Robin Dapp; gcc-patches; pan2.li; richard.sandiford; Richard Biener; pinskia > > >> Subject: Re: Re: [PATCH] fold-const: Handle AND, IOR, XOR with stepped vectors [PR112971]. > > >> On Tue, 19 Dec 2023, juzhe.zhong@rivai.ai wrote: > > >> > > >> > Hi?Richard. Do you mean add the check as follows ? > > >> > > > >> > if (VECTOR_CST_NELTS_PER_PATTERN (arg1) == 1 > > >> > && VECTOR_CST_NELTS_PER_PATTERN (arg2) == 3 > > >> > > >> Or <= 3 which would allow combining. As said, not sure what > > >> == 2 would be and whether that would work. > > >> > > >> Btw, integer_allonesp should also allow to be optimized for > > >> and/ior at least. Possibly IOR/AND with the sign bit for > > >> signed elements as well. > > >> > > >> I wonder if there's a programmatic way to identify OK cases > > >> rather than enumerating them. > > >> > > >> > && integer_zerop (VECTOR_CST_ELT (arg1, 0))) > > >> > step_ok_p = (code == BIT_AND_EXPR || code == BIT_IOR_EXPR > > >> > || code == BIT_XOR_EXPR); > > >> > else if (VECTOR_CST_NELTS_PER_PATTERN (arg2) == 1 > > >> > && VECTOR_CST_NELTS_PER_PATTERN (arg1) == 3 > > >> > && integer_zerop (VECTOR_CST_ELT (arg2, 0))) > > >> > step_ok_p = (code == BIT_AND_EXPR || code == BIT_IOR_EXPR > > >> > || code == BIT_XOR_EXPR); > > >> > > > >> > > > >> > > > >> > juzhe.zhong@rivai.ai > > >> > > > >> > From: Richard Biener > > >> > Date: 2023-12-19 16:15 > > >> > To: ??? > > >> > CC: rdapp.gcc; gcc-patches; pan2.li; richard.sandiford; richard.guenther; Andrew Pinski > > >> > Subject: Re: [PATCH] fold-const: Handle AND, IOR, XOR with stepped vectors [PR112971]. > > >> > On Tue, 19 Dec 2023, ??? wrote: > > >> > > > >> > > Thanks Robin send initial patch to fix this ICE bug. > > >> > > > > >> > > CC to Richard S, Richard B, and Andrew. > > >> > > > >> > Just one comment, it seems that VECTOR_CST_STEPPED_P should > > >> > implicitly include VECTOR_CST_DUPLICATE_P since it would be > > >> > a step of zero (but as implemented it doesn't catch this). > > >> > Looking at the implementation it's odd that we can handle > > >> > VECTOR_CST_NELTS_PER_PATTERN == 1 (duplicate) and > > >> > == 3 (stepped) but not == 2 (not sure what that would be). > > >> > > > >> > Maybe the tests can be re-formulated in terms of > > >> > VECTOR_CST_NELTS_PER_PATTERN? > > >> > > > >> > Richard. > > >> > > > >> > > Thanks. > > >> > > > > >> > > > > >> > > > > >> > > juzhe.zhong@rivai.ai > > >> > > > > >> > > From: Robin Dapp > > >> > > Date: 2023-12-19 03:50 > > >> > > To: gcc-patches > > >> > > CC: rdapp.gcc; Li, Pan2; juzhe.zhong@rivai.ai > > >> > > Subject: [PATCH] fold-const: Handle AND, IOR, XOR with stepped vectors [PR112971]. > > >> > > Hi, > > >> > > > > >> > > found in PR112971, this patch adds folding support for bitwise operations > > >> > > of const duplicate zero vectors and stepped vectors. > > >> > > On riscv we have the situation that a folding would perpetually continue > > >> > > without simplifying because e.g. {0, 0, 0, ...} & {7, 6, 5, ...} would > > >> > > not fold to {0, 0, 0, ...}. > > >> > > > > >> > > Bootstrapped and regtested on x86 and aarch64, regtested on riscv. > > >> > > > > >> > > I won't be available to respond quickly until next year. Pan or Juzhe, > > >> > > as discussed, feel free to continue with possible revisions. > > >> > > > > >> > > Regards > > >> > > Robin > > >> > > > > >> > > > > >> > > gcc/ChangeLog: > > >> > > > > >> > > PR middle-end/112971 > > >> > > > > >> > > * fold-const.cc (const_binop): Handle > > >> > > zerop@1 AND/IOR/XOR VECT_CST_STEPPED_P@2 > > >> > > > > >> > > gcc/testsuite/ChangeLog: > > >> > > > > >> > > * gcc.target/riscv/rvv/autovec/pr112971.c: New test. > > >> > > --- > > >> > > gcc/fold-const.cc | 14 +++++++++++++- > > >> > > .../gcc.target/riscv/rvv/autovec/pr112971.c | 18 ++++++++++++++++++ > > >> > > 2 files changed, 31 insertions(+), 1 deletion(-) > > >> > > create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/autovec/pr112971.c > > >> > > > > >> > > diff --git a/gcc/fold-const.cc b/gcc/fold-const.cc > > >> > > index f5d68ac323a..43ed097bf5c 100644 > > >> > > --- a/gcc/fold-const.cc > > >> > > +++ b/gcc/fold-const.cc > > >> > > @@ -1653,8 +1653,20 @@ const_binop (enum tree_code code, tree arg1, tree arg2) > > >> > > { > > >> > > tree type = TREE_TYPE (arg1); > > >> > > bool step_ok_p; > > >> > > + > > >> > > + /* AND, IOR as well as XOR with a zerop can be handled directly. */ > > >> > > if (VECTOR_CST_STEPPED_P (arg1) > > >> > > - && VECTOR_CST_STEPPED_P (arg2)) > > >> > > + && VECTOR_CST_DUPLICATE_P (arg2) > > >> > > + && integer_zerop (VECTOR_CST_ELT (arg2, 0))) > > >> > > + step_ok_p = code == BIT_AND_EXPR || code == BIT_IOR_EXPR > > >> > > + || code == BIT_XOR_EXPR; > > >> > > + else if (VECTOR_CST_STEPPED_P (arg2) > > >> > > + && VECTOR_CST_DUPLICATE_P (arg1) > > >> > > + && integer_zerop (VECTOR_CST_ELT (arg1, 0))) > > >> > > + step_ok_p = code == BIT_AND_EXPR || code == BIT_IOR_EXPR > > >> > > + || code == BIT_XOR_EXPR; > > >> > > + else if (VECTOR_CST_STEPPED_P (arg1) > > >> > > + && VECTOR_CST_STEPPED_P (arg2)) > > >> > > /* We can operate directly on the encoding if: > > >> > > a3 - a2 == a2 - a1 && b3 - b2 == b2 - b1 > > >> > > diff --git a/gcc/testsuite/gcc.target/riscv/rvv/autovec/pr112971.c b/gcc/testsuite/gcc.target/riscv/rvv/autovec/pr112971.c > > >> > > new file mode 100644 > > >> > > index 00000000000..816ebd3c493 > > >> > > --- /dev/null > > >> > > +++ b/gcc/testsuite/gcc.target/riscv/rvv/autovec/pr112971.c > > >> > > @@ -0,0 +1,18 @@ > > >> > > +/* { dg-do compile } */ > > >> > > +/* { dg-options "-march=rv64gcv_zvl256b -mabi=lp64d -O3 -fno-vect-cost-model" } */ > > >> > > + > > >> > > +int a; > > >> > > +short b[9]; > > >> > > +char c, d; > > >> > > +void e() { > > >> > > + d = 0; > > >> > > + for (;; d++) { > > >> > > + if (b[d]) > > >> > > + break; > > >> > > + a = 8; > > >> > > + for (; a >= 0; a--) { > > >> > > + char *f = &c; > > >> > > + *f &= d == (a & d); > > >> > > + } > > >> > > + } > > >> > > +} > > >> > > > > >> > > > >> > > > >> > > >> > -- Richard Biener SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)