public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "juergen.reuter at desy dot de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer
Date: Fri, 25 Aug 2023 21:17:37 +0000 [thread overview]
Message-ID: <bug-110311-4-9jgI3DJiYj@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-110311-4@http.gcc.gnu.org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #52 from Jürgen Reuter <juergen.reuter at desy dot de> ---
(In reply to Jakub Jelinek from comment #51)
> The easiest would be to bisect gcc in the suspected ranges, that way you'd
> know for sure which git commit introduced the problem and which
> fixed/"fixed" it.
> If it is about what the compiler emits, one doesn't have to build whole gcc
> from scratch each time, but can just --disable-bootstrap build it and during
> bisection
> whenever git is updated just ./config.status --recheck; ./config.status;
> make -jN in libcpp, libiberty and gcc subdirectories and use f951/gfortran
> binariers from that instead of the ones from the initial build to build your
> project.
This was the offending commit by Richard Sayle, on Saturday June 17:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=96c3539f2a38134cb76d8ab2e924e0dc70b2ccbd
=================================
i386: Two minor tweaks to ix86_expand_move.
This patch splits out two (independent) minor changes to i386-expand.cc's
ix86_expand_move from a larger patch, given that it's better to review
and commit these independent pieces separately from a more complex patch.
The first change is to test for CONST_WIDE_INT_P before calling
ix86_convert_const_wide_int_to_broadcast. Whilst stepping through
this function in gdb, I was surprised that the code was continually
jumping into this function with operands that obviously weren't
appropriate.
The second change is to generalize the optimization for efficiently
moving a TImode value to V1TImode (via V2DImode), to cover all 128-bit
vector modes.
Hence for the test case:
typedef unsigned long uv2di __attribute__ ((__vector_size__ (16)));
uv2di foo2(__int128 x) { return (uv2di)x; }
we'd previously move via memory with:
foo2: movq %rdi, -24(%rsp)
movq %rsi, -16(%rsp)
movdqa -24(%rsp), %xmm0
ret
with this patch we now generate with -O2 (the same as V1TImode):
foo2: movq %rdi, %xmm0
movq %rsi, %xmm1
punpcklqdq %xmm1, %xmm0
ret
and with -O2 -msse4 the even better:
foo2: movq %rdi, %xmm0
pinsrq $1, %rsi, %xmm0
ret
The new test case is unimaginatively called sse2-v1ti-mov-2.c given
the original test case just for V1TI mode was called sse2-v1ti-mov-1.c.
2023-06-17 Roger Sayle <roger@nextmovesoftware.com>
gcc/ChangeLog
* config/i386/i386-expand.cc (ix86_expand_move): Check that OP1 is
CONST_WIDE_INT_P before calling ix86_convert_wide_int_to_broadcast.
Generalize special case for converting TImode to V1TImode to handle
all 128-bit vector conversions.
gcc/testsuite/ChangeLog
* gcc.target/i386/sse2-v1ti-mov-2.c: New test case.
===========================================================
Now the question is, was this commit later reverted? Or changed in a different
manner
next prev parent reply other threads:[~2023-08-25 21:17 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-19 12:45 [Bug fortran/110311] New: [gfortran 14.0 regression] juergen.reuter at desy dot de
2023-06-20 6:29 ` [Bug fortran/110311] " juergen.reuter at desy dot de
2023-06-20 7:48 ` juergen.reuter at desy dot de
2023-06-20 8:08 ` [Bug fortran/110311] [14 Regression] gfortran 14.0 regression rguenth at gcc dot gnu.org
2023-06-20 10:13 ` juergen.reuter at desy dot de
2023-06-20 17:35 ` anlauf at gcc dot gnu.org
2023-06-20 17:38 ` juergen.reuter at desy dot de
2023-06-21 6:43 ` manolis.tsamis at vrull dot eu
2023-06-21 12:53 ` juergen.reuter at desy dot de
2023-06-21 23:37 ` pinskia at gcc dot gnu.org
2023-06-22 11:48 ` juergen.reuter at desy dot de
2023-06-22 11:54 ` [Bug fortran/110311] [14 Regression] regression in tree-optimizer juergen.reuter at desy dot de
2023-06-23 22:01 ` juergen.reuter at desy dot de
2023-06-23 23:23 ` juergen.reuter at desy dot de
2023-06-24 9:21 ` [Bug tree-optimization/110311] " juergen.reuter at desy dot de
2023-06-24 10:33 ` juergen.reuter at desy dot de
2023-06-24 11:47 ` anlauf at gcc dot gnu.org
2023-06-24 13:04 ` juergen.reuter at desy dot de
2023-06-24 13:09 ` juergen.reuter at desy dot de
2023-06-24 13:41 ` anlauf at gcc dot gnu.org
2023-06-24 13:43 ` juergen.reuter at desy dot de
2023-06-24 13:46 ` anlauf at gcc dot gnu.org
2023-06-24 18:21 ` anlauf at gcc dot gnu.org
2023-06-24 18:54 ` juergen.reuter at desy dot de
2023-06-24 19:16 ` anlauf at gcc dot gnu.org
2023-06-29 14:39 ` juergen.reuter at desy dot de
2023-06-29 17:29 ` anlauf at gcc dot gnu.org
2023-06-29 17:47 ` juergen.reuter at desy dot de
2023-06-29 18:59 ` anlauf at gcc dot gnu.org
2023-06-29 19:33 ` anlauf at gcc dot gnu.org
2023-06-29 19:35 ` juergen.reuter at desy dot de
2023-06-29 20:07 ` anlauf at gcc dot gnu.org
2023-06-30 17:45 ` anlauf at gcc dot gnu.org
2023-06-30 17:50 ` jakub at gcc dot gnu.org
2023-06-30 18:32 ` anlauf at gcc dot gnu.org
2023-06-30 18:57 ` anlauf at gcc dot gnu.org
2023-06-30 19:25 ` ubizjak at gmail dot com
2023-06-30 19:30 ` anlauf at gcc dot gnu.org
2023-06-30 19:32 ` anlauf at gcc dot gnu.org
2023-06-30 19:46 ` juergen.reuter at desy dot de
2023-06-30 19:47 ` ubizjak at gmail dot com
2023-06-30 20:19 ` anlauf at gcc dot gnu.org
2023-06-30 21:09 ` jakub at gcc dot gnu.org
2023-06-30 21:48 ` juergen.reuter at desy dot de
2023-07-01 7:55 ` anlauf at gcc dot gnu.org
2023-07-01 8:09 ` juergen.reuter at desy dot de
2023-07-06 19:40 ` juergen.reuter at desy dot de
2023-07-06 19:44 ` juergen.reuter at desy dot de
2023-07-06 21:18 ` anlauf at gcc dot gnu.org
2023-07-06 21:38 ` anlauf at gcc dot gnu.org
2023-07-07 12:44 ` juergen.reuter at desy dot de
2023-08-09 9:02 ` juergen.reuter at desy dot de
2023-08-09 9:24 ` jakub at gcc dot gnu.org
2023-08-25 21:17 ` juergen.reuter at desy dot de [this message]
2023-08-25 21:18 ` juergen.reuter at desy dot de
2023-08-25 21:23 ` juergen.reuter at desy dot de
2023-08-30 12:34 ` juergen.reuter at desy dot de
2023-09-22 14:56 ` juergen.reuter at desy dot de
2023-10-17 11:07 ` rguenth at gcc dot gnu.org
2024-03-27 13:41 ` rguenth at gcc dot gnu.org
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=bug-110311-4-9jgI3DJiYj@http.gcc.gnu.org/bugzilla/ \
--to=gcc-bugzilla@gcc.gnu.org \
--cc=gcc-bugs@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: 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).