From: Richard Biener <rguenther@suse.de>
To: Richard Sandiford <richard.sandiford@arm.com>
Cc: Andrew Pinski <pinskia@gmail.com>,
"juzhe.zhong@rivai.ai" <juzhe.zhong@rivai.ai>,
Robin Dapp <rdapp.gcc@gmail.com>,
gcc-patches <gcc-patches@gcc.gnu.org>,
"pan2.li" <pan2.li@intel.com>,
Richard Biener <richard.guenther@gmail.com>
Subject: Re: [PATCH] fold-const: Handle AND, IOR, XOR with stepped vectors [PR112971].
Date: Wed, 20 Dec 2023 11:06:42 +0100 (CET) [thread overview]
Message-ID: <4060o0r6-4s4p-rrqr-507q-5522q5r71r97@fhfr.qr> (raw)
In-Reply-To: <mptcyv1md65.fsf@arm.com>
On Wed, 20 Dec 2023, Richard Sandiford wrote:
> Richard Biener <rguenther@suse.de> writes:
> > On Tue, 19 Dec 2023, Andrew Pinski wrote:
> >
> >> On Tue, Dec 19, 2023 at 2:40?AM Richard Sandiford
> >> <richard.sandiford@arm.com> wrote:
> >> >
> >> > Richard Biener <rguenther@suse.de> 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 <rguenther@suse.de>
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
next prev parent reply other threads:[~2023-12-20 10:07 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-18 19:50 Robin Dapp
2023-12-18 22:49 ` 钟居哲
2023-12-19 8:15 ` Richard Biener
2023-12-19 8:54 ` juzhe.zhong
2023-12-19 9:12 ` Richard Biener
2023-12-19 9:35 ` juzhe.zhong
2023-12-19 9:45 ` Jakub Jelinek
2023-12-19 9:49 ` juzhe.zhong
2023-12-19 9:55 ` Jakub Jelinek
2023-12-19 10:11 ` Richard Biener
2023-12-19 10:40 ` Richard Sandiford
2023-12-19 10:58 ` juzhe.zhong
2023-12-20 2:04 ` Andrew Pinski
2023-12-20 2:07 ` juzhe.zhong
2023-12-20 7:25 ` Richard Biener
2023-12-20 9:33 ` Richard Sandiford
2023-12-20 10:06 ` Richard Biener [this message]
2024-01-15 15:23 ` Robin Dapp
2024-01-16 7:17 ` Richard Biener
2024-01-24 11:29 ` Richard Sandiford
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4060o0r6-4s4p-rrqr-507q-5522q5r71r97@fhfr.qr \
--to=rguenther@suse.de \
--cc=gcc-patches@gcc.gnu.org \
--cc=juzhe.zhong@rivai.ai \
--cc=pan2.li@intel.com \
--cc=pinskia@gmail.com \
--cc=rdapp.gcc@gmail.com \
--cc=richard.guenther@gmail.com \
--cc=richard.sandiford@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).