public inbox for gcc-cvs@sourceware.org help / color / mirror / Atom feed
From: Michael Meissner <meissner@gcc.gnu.org> To: gcc-cvs@gcc.gnu.org Subject: [gcc(refs/users/meissner/heads/work083)] Update ChangeLog.meissner. Date: Thu, 24 Mar 2022 19:45:26 +0000 (GMT) [thread overview] Message-ID: <20220324194526.94AE03858D3C@sourceware.org> (raw) https://gcc.gnu.org/g:e680afadd24f8cdde94a2c34166496eabc0b8db6 commit e680afadd24f8cdde94a2c34166496eabc0b8db6 Author: Michael Meissner <meissner@linux.ibm.com> Date: Thu Mar 24 15:45:07 2022 -0400 Update ChangeLog.meissner. 2022-03-24 Michael Meissner <meissner@linux.ibm.com> gcc/ * ChangeLog.meissner: Update. Diff: --- gcc/ChangeLog.meissner | 108 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 108 insertions(+) diff --git a/gcc/ChangeLog.meissner b/gcc/ChangeLog.meissner index e72802074b6..45880d06766 100644 --- a/gcc/ChangeLog.meissner +++ b/gcc/ChangeLog.meissner @@ -1,3 +1,111 @@ +==================== Work083, patch #4: + +Allow vsx_extract_<mode> to use Altivec registers + +In looking at PR target/99293, I noticed that the vsx_extract_<mode> +pattern for V2DImode and V2DFmode only allowed traditional floating point +registers, and it did not allow Altivec registers. The original code was +written a few years ago when we used the old register allocator, and +support for scalar floating point in Altivec registers was just being +added to GCC. + +2022-03-24 Michael Meissner <meissner@linux.ibm.com> + +gcc/ + PR target/99392 + * config/rs6000/rs6000.md (vsx_extract_<mode>): Allow destination + to be an Altivec register. + +==================== Work083, patch #1: + +Make vsx_extract_<mode> use correct insn attributes. + +In looking at PR target/99293, I noticed that the insn "type" attribute is +incorrect for the vsx_extract_<mode> insns. In particular: + + 1) Simple vector register move should be vecsimple (alternative 1); + 2) Xxpermdi should be vecperm (alternative 2); (and) + 3) Mfvsrld should be mfvsr (alternative 4). + +This patch fixes those attributes. + +2022-03-24 Michael Meissner <meissner@linux.ibm.com> + +gcc/ + PR target/99392 + * config/rs6000/rs6000.md (vsx_extract_<mode>): Use the correct + insn type for the alternatives. + +==================== Work083, patch #1: + +Make vsx_splat_<mode>_reg use correct insn attributes. + +In looking at PR target/99293, I noticed that the code in +vsx_splat_<mode>_reg used "vecmove" as the "type" insn attribute when the +"mtvsrdd" is generated. It should use "mfvsr". I also added a "p9v" isa +attribute for that alternative. + +2022-03-23 Michael Meissner <meissner@linux.ibm.com> + +gcc/ + PR target/99392 + * config/rs6000/rs6000.md (vsx_splat_<mode>_reg): Use the correct + insn type attribute. Add "p9v" isa attribute for generating the + mtvsrdd instruction. + +==================== Work083, patch #1: + +Optimize vec_splats of constant vec_extract for V2DI/V2DF. + +In PR target/99293, it was pointed out that doing: + + vector long long dest0, dest1, src; + /* ... */ + dest0 = vec_splats (vec_extract (src, 0)); + dest1 = vec_splats (vec_extract (src, 1)); + +would generate slower code. + +It generates the following code on power8: + + ;; vec_splats (vec_extract (src, 0)) + xxpermdi 0,34,34,3 + xxpermdi 34,0,0,0 + + ;; vec_splats (vec_extract (src, 1)) + xxlor 0,34,34 + xxpermdi 34,0,0,0 + +However on power9 and power10 it generates: + + ;; vec_splats (vec_extract (src, 0)) + mfvsld 3,34 + mtvsrdd 34,9,9 + + ;; vec_splats (vec_extract (src, 1)) + mfvsrd 9,34 + mtvsrdd 34,9,9 + +This is due to the power9 having the mfvsrld instruction which can extract +either 64-bit element into a GPR. + +However in this case, it is better to have a single combiner pattern that +can generate a single xxpermdi, instead of doing 2 insnsns (the extract +and then the concat). + +2022-03-24 Michael Meissner <meissner@linux.ibm.com> + +gcc/ + PR target/99392 + * config/rs6000/vsx.md (vsx_splat_const_extract_<mode>): New + combiner insn. + +gcc/testsuite: + PR target/99392 + * gcc.target/powerpc/pr99293.c: New test. + +==================== Baseline + 2022-03-24 Michael Meissner <meissner@linux.ibm.com> Clone branch
next reply other threads:[~2022-03-24 19:45 UTC|newest] Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-03-24 19:45 Michael Meissner [this message] 2022-03-24 21:37 Michael Meissner
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=20220324194526.94AE03858D3C@sourceware.org \ --to=meissner@gcc.gnu.org \ --cc=gcc-cvs@gcc.gnu.org \ /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: linkBe 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).