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

  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).