[Bug rtl-optimization/55278] New: Botan performance regressions apparently due to LRA

[Bug rtl-optimization/55278] New: Botan performance regressions apparently due to LRA

[hubicka at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55278

             Bug #: 55278
           Summary: Botan performance regressions apparently due to LRA
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: rtl-optimization
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: hubicka@gcc.gnu.org


Botan regressed significantly around October 23-25 when LRA was merged as can
be seen http://gcc.opensuse.org/c++bench/botan/botan-summary.txt-1-0.html
Those are all quite straighforward internal loops so it may be easy enough to
analyze what is going wrong.

[Bug rtl-optimization/55278] [4.8 Regression] Botan performance regressions apparently due to LRA

[steven at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55278

Steven Bosscher <steven at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ra
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-03-23
            Summary|Botan performance           |[4.8 Regression] Botan
                   |regressions apparently due  |performance regressions
                   |to LRA                      |apparently due to LRA
     Ever Confirmed|0                           |1

--- Comment #1 from Steven Bosscher <steven at gcc dot gnu.org> 2013-03-23 19:38:00 UTC ---
Confirmed for RC5(12) and KASUMI.

Note, LLVM also beats GCC badly for a few of the botan benchmarks, see
http://www.phoronix.com/scan.php?page=article&item=llvm_32_egging&num=2

[Bug rtl-optimization/55278] [4.8/4.9 Regression] Botan performance regressions apparently due to LRA

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55278

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |missed-optimization
           Priority|P3                          |P2
   Target Milestone|---                         |4.8.1

[Bug rtl-optimization/55278] [4.8/4.9 Regression] Botan performance regressions apparently due to LRA

[hubicka at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55278

--- Comment #2 from Jan Hubicka <hubicka at gcc dot gnu.org> 2013-03-25 11:03:36 UTC ---
Yep, Botan tends to be very random, see our benchmarks.  I looked into some of
the loops and they are very tight written in a bit particular way, so a lot of
performance changes are really by a chance.

Some better analysis would be desirable however.

[Bug rtl-optimization/55278] [4.8/4.9 Regression] Botan performance regressions apparently due to LRA

[mpolacek at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55278

--- Comment #5 from Marek Polacek <mpolacek at gcc dot gnu.org> 2013-05-07 22:31:37 UTC ---
Created attachment 30049
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30049
kasumi_clang.s

Clang assembly

[Bug rtl-optimization/55278] [4.8/4.9 Regression] Botan performance regressions apparently due to LRA

[mpolacek at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55278

--- Comment #4 from Marek Polacek <mpolacek at gcc dot gnu.org> 2013-05-07 22:31:05 UTC ---
Created attachment 30048
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30048
kasumi_gcc.s

Adding GCC assembly

[Bug rtl-optimization/55278] [4.8/4.9 Regression] Botan performance regressions apparently due to LRA

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55278

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-05-07 22:34:15 UTC ---
To:
unsigned char KASUMI_SBOX_S7[128];
unsigned short KASUMI_SBOX_S9[512];

static inline unsigned short
rotate_left (unsigned short input, unsigned long rot)
{
  return ((input << rot) | (input >> (8 * sizeof (unsigned short) - rot)));
}

static inline unsigned short
reverse_bytes (unsigned short val)
{
  return rotate_left (val, 8);
}

static inline unsigned short
load_be (const unsigned char in[], unsigned long off)
{
  return reverse_bytes (*((const unsigned short *)in + off));
}

static inline void
store_be (unsigned short in, unsigned char out[2])
{
  *(unsigned short *)out = reverse_bytes (in);
}

static inline void
store_be4 (unsigned char out[], unsigned short x0, unsigned short x1,
      unsigned short x2, unsigned short x3)
{
  store_be (x0, out + (0 * sizeof (unsigned short)));
  store_be (x1, out + (1 * sizeof (unsigned short)));
  store_be (x2, out + (2 * sizeof (unsigned short)));
  store_be (x3, out + (3 * sizeof (unsigned short)));
}

unsigned short
FI (unsigned short I, unsigned short K)
{
  unsigned short D9 = (I >> 7);
  unsigned char D7 = (I & 0x7F);
  D9 = KASUMI_SBOX_S9[D9] ^ D7;
  D7 = KASUMI_SBOX_S7[D7] ^ (D9 & 0x7F);

  D7 ^= (K >> 9);
  D9 = KASUMI_SBOX_S9[D9 ^ (K & 0x1FF)] ^ D7;
  D7 = KASUMI_SBOX_S7[D7] ^ (D9 & 0x7F);
  return (D7 << 9) | D9;
}

__attribute__((noinline, noclone))
void
encrypt_n (unsigned short **EK, const unsigned char in[], unsigned char out[],
       unsigned long blocks)
{
  unsigned long i, j;
  for (i = 0; i != blocks; ++i)
    {
      unsigned short B0 = load_be (in, 0);
      unsigned short B1 = load_be (in, 1);
      unsigned short B2 = load_be (in, 2);
      unsigned short B3 = load_be (in, 3);
      for (j = 0; j != 8; j += 2)
    {
      const unsigned short *K = &(*EK)[8 * j];
      unsigned short R = B1 ^ (rotate_left (B0, 1) & K[0]);
      unsigned short L = B0 ^ (rotate_left (R, 1) | K[1]);
      L = FI (L ^ K[2], K[3]) ^ R;
      R = FI (R ^ K[4], K[5]) ^ L;
      L = FI (L ^ K[6], K[7]) ^ R;
      R = B2 ^= R;
      L = B3 ^= L;
      R = FI (R ^ K[10], K[11]) ^ L;
      L = FI (L ^ K[12], K[13]) ^ R;
      R = FI (R ^ K[14], K[15]) ^ L;
      R ^= (rotate_left (L, 1) & K[8]);
      L ^= (rotate_left (R, 1) | K[9]);
      B0 ^= L;
      B1 ^= R;
    }
      store_be4 (out, B0, B1, B2, B3);
      in += 8;
      out += 8;
    }
}

unsigned char in[4096], out[4096];

int
main ()
{
  unsigned short EKb[64], *EK = EKb;
  __builtin_memset (EKb, 0, sizeof EKb);
  asm volatile ("" : : : "memory");
  int i;
  for (i = 0; i < 100000; i++)
    encrypt_n (&EK, in, out, 4096 / 8);
  return 0;
}

actually (note different code in store_be and load_be).  I'm surprised that
the 16-bit rotations aren't detected/folded into rotations (or rotate_left
(u16, 8) into a bswap16).

[Bug rtl-optimization/55278] [4.8/4.9 Regression] Botan performance regressions apparently due to LRA

[glisse at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55278

--- Comment #7 from Marc Glisse <glisse at gcc dot gnu.org> 2013-05-07 22:48:40 UTC ---
(In reply to comment #6)
> I'm surprised that
> the 16-bit rotations aren't detected/folded into rotations (or rotate_left
> (u16, 8) into a bswap16).

See also PR 45216 for rotate, where the initial report is about rotate16, and
the last comment is about a C++ regression likely related to the sizeof changes
(it is folded too late for fold_binary of | to see the constant).

[Bug rtl-optimization/55278] [4.8/4.9 Regression] Botan performance regressions apparently due to LRA

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55278

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-05-08 06:58:37 UTC ---
unsigned int
f1 (unsigned int x, unsigned int y)
{
  return (x << y) | (x >> (32 - y));
}

unsigned int
f2 (unsigned int x, unsigned long y)
{
  return (x << y) | (x >> (32 - y));
}

unsigned int
f3 (unsigned int x)
{
  return (x << 1) | (x >> (32 - 1));
}

unsigned int
f4 (unsigned int x)
{
  return (x << (32 - 1)) | (x >> 1);
}

unsigned short int
f5 (unsigned short int x, unsigned int y)
{
  return (x << y) | (x >> (16 - y));
}

unsigned short int
f6 (unsigned short int x, unsigned long y)
{
  return (x << y) | (x >> (16 - y));
}

unsigned char
f7 (unsigned char x, unsigned int y)
{
  return (x << y) | (x >> (8 - y));
}

unsigned char
f8 (unsigned char x, unsigned long y)
{
  return (x << y) | (x >> (8 - y));
}

unsigned int
f9 (unsigned int x, unsigned int y)
{
  return (x << y) | (x >> (sizeof (unsigned int) - y));
}

unsigned int
f10 (unsigned int x, unsigned long y)
{
  return (x << y) | (x >> (sizeof (unsigned int) - y));
}

unsigned int
f11 (unsigned int x)
{
  return (x << 1) | (x >> (sizeof (unsigned int) - 1));
}

unsigned int
f12 (unsigned int x)
{
  return (x << (sizeof (unsigned int) - 1)) | (x >> 1);
}

unsigned short int
f13 (unsigned short int x, unsigned int y)
{
  return (x << y) | (x >> (sizeof (unsigned short) - y));
}

unsigned short int
f14 (unsigned short int x, unsigned long y)
{
  return (x << y) | (x >> (sizeof (unsigned short) - y));
}

unsigned char
f15 (unsigned char x, unsigned int y)
{
  return (x << y) | (x >> (sizeof (unsigned char) - y));
}

unsigned char
f16 (unsigned char x, unsigned long y)
{
  return (x << y) | (x >> (sizeof (unsigned char) - y));
}

shows lots of various issues with rotates:
1) if the shift count isn't int expression, we don't detect that (there is
extra
   cast that bit_rotate: doesn't handle) - example f2
2) for f3 we emit rorl $31, %eax while we should special case it and emit
   roll %eax instead (shorter insn; backend issue)
3) the casts added for promoted types aren't handled - example f5
   - I guess even that is fine to handle, because say for y 17, while << 17
   is defined behavior, >> (16 - 17) or >> (16U - 17) should be undefined
   behavior and thus really y should be [1, 15].
4) the deferred SIZEOF_EXPR folding in C++ plays a role here
5) as mentioned in another PR, these rotate idioms assume non-zero rotation
   count, for 0 they have undefined behavior, so we should recognize also
   another form

So, IMHO bit_rotate: should be extended to handle these (except that it can't
do anything about SIZEOF_EXPR, being a FE tree (unless we add some langhook for
it
or handle it again in C++ lang folder), and perhaps some later pass (bswap pass
or gimple-fold?) should be taught to recognize it too.  And the vectorizer
pattern detection needs to be taught to undo that if there is no vector
rotation optab.

[Bug rtl-optimization/55278] [4.8/4.9 Regression] Botan performance regressions apparently due to LRA

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55278

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I've attached two rotate patches to PR57157.  They seem to improve
#c6 runtime slightly (from:
real 0m6.303s
user 0m6.293s
sys  0m0.000s
to:
real 0m5.920s
user 0m5.913s
sys  0m0.000s
) but guess there are other issues to look at (perhaps RA can be one thing,
what else?).

[Bug rtl-optimization/55278] [4.8/4.9 Regression] Botan performance regressions apparently due to LRA

[vmakarov at redhat dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55278

--- Comment #11 from Vladimir Makarov <vmakarov at redhat dot com> ---
I don't see a code degradation because of LRA.  Here what I got using gcc4.8
branch compiler with options -O3  -finline-functions  -D_REENTRANT
-Wno-long-long -W -Wall -fPIC -fvisibility=hidden on Xeon X5660 and i7-2600
(sandy bridge):

64-bit:

real=16.78 user=16.57 system=0.00
real=16.39 user=16.20 system=0.00
real=16.81 user=16.57 system=0.00
real=16.35 user=16.20 system=0.00
real=16.82 user=16.56 system=0.00
real=16.40 user=16.20 system=0.00

real=7.37 user=7.34 system=0.00
real=7.05 user=7.02 system=0.00
real=7.34 user=7.31 system=0.00
real=7.05 user=7.02 system=0.00
real=7.37 user=7.31 system=0.00
real=7.05 user=7.02 system=0.00


32-bit:

real=15.46 user=15.22 system=0.00 share=98%%
real=14.53 user=14.21 system=0.00 share=97%%
real=15.77 user=15.41 system=0.00 share=97%%
real=14.49 user=14.23 system=0.00 share=98%%
real=15.57 user=15.22 system=0.00 share=97%%
real=14.51 user=14.23 system=0.00 share=98%%

real=10.17 user=10.13 system=0.00
real=7.76 user=7.73 system=0.00
real=10.17 user=10.13 system=0.00
real=7.76 user=7.73 system=0.00
real=10.17 user=10.13 system=0.00
real=7.76 user=7.73 system=0.00

The first run is for gcc-4.8 with reload the second run with LRA. It is
repeated 3 times. LRA generates a better code for this test on both CPU in 32
and 64-bit mode.

Although LLVM new reg allocator might generate better code than LRA or reload
or may be there is another reason for this.  To be honest I don't know.

I looked at http://gcc.opensuse.org/c++bench/botan/botan-summary.txt-1-0.html
and I see that KASUMI was improved about October.  I worked on botan after LRA
merge and as I remember some benchmarked became worse, some were improved but
in overall (run time for all algorithms) was about the same.

I don't have 3.3 LLVM but I using 3.2 I am getting on i7-2600
7.378s(64-bit) and 7.234s (32-bit) using the option above vs 7.02s and 7.73s
for gcc4.8 (LRA).  So I can not confirm the big difference on KASUMI reported
on http://www.phoronix.com/scan.php?page=article&item=llvm_32_egging&num=2.

It seems to me phoronix is very LLVM biased and that is not good for its
credibility.

[Bug rtl-optimization/55278] [4.8/4.9 Regression] Botan performance regressions, other compilers generate better code than gcc

[ubizjak at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55278

--- Comment #14 from Uros Bizjak <ubizjak at gmail dot com> ---
(In reply to Jakub Jelinek from comment #12)

> (force gcc to avoid xorw memory, %hireg and instead use movzwl memory,
> %sireg; ... xorl %sireg, %sireg2) and p2 was something similar for *xorqi_1.
> 
> Looking at icc generated assembly, it is interesting to see that the only
> HImode instructions it ever uses are rolw and movw stores, for everything
> else it uses
> movzwl loads and SImode arithmetics (well, I guess shift right
> shrw/sarw/rorw can't be avoided either).  Similarly, icc on the testcase
> doesn't emit any QImode instructions at all, while gcc emits tons of them
> and llvm something in between.
> 
> So perhaps this bug is not about LRA, but about instruction selection, and
> when not optimizing for size at least on some CPUs we should consider using
> SImode arithmetics instead of QImode/HImode much more aggressively than we
> do now.
> Not sure if it is better done by (Kai's?) type optimization pass, which
> shortly before expansion using target hints would just try to get rid of as
> many QImode and especially HImode operations as possible, guess we can often
> keep complete garbage in the upper bits, or if it is better done at the *.md
> level.

Please note that it is possible to tune usage of HImode and QImode arithmetics
with X86_TUNE_QIMODE_MATH and X86_TUNE_HIMODE_MATH. Also,
X86_TUNE_PROMOTE_QI_REGS, X86_TUNE_PROMOTE_QI_REGS and eventually
X86_TUNE_PARTIAL_REG_STALL can be used to fine-tune usage of partial registers.

[Bug rtl-optimization/55278] [4.8/4.9 Regression] Botan performance regressions, other compilers generate better code than gcc

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55278

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.8.1                       |4.8.2

--- Comment #15 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 4.8.1 has been released.

[Bug rtl-optimization/55278] [4.8/4.9 Regression] Botan performance regressions, other compilers generate better code than gcc

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55278

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.8.2                       |4.8.3

--- Comment #16 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 4.8.2 has been released.

[Bug rtl-optimization/55278] [4.8/4.9/4.10 Regression] Botan performance regressions, other compilers generate better code than gcc

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55278

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.8.3                       |4.8.4

--- Comment #17 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 4.8.3 is being released, adjusting target milestone.

[Bug rtl-optimization/55278] [4.8/4.9/5 Regression] Botan performance regressions, other compilers generate better code than gcc

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55278

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.8.4                       |4.8.5

--- Comment #18 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 4.8.4 has been released.

[Bug rtl-optimization/55278] [4.8/4.9/5/6 Regression] Botan performance regressions, other compilers generate better code than gcc

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55278

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.8.5                       |4.9.3

--- Comment #19 from Richard Biener <rguenth at gcc dot gnu.org> ---
The gcc-4_8-branch is being closed, re-targeting regressions to 4.9.3.

[Bug rtl-optimization/55278] [4.9/5/6 Regression] Botan performance regressions, other compilers generate better code than gcc

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55278

--- Comment #20 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 4.9.3 has been released.

[Bug rtl-optimization/55278] [4.9/5/6 Regression] Botan performance regressions, other compilers generate better code than gcc

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55278

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.9.3                       |4.9.4

[Bug rtl-optimization/55278] [9/10/11/12 Regression] Botan performance regressions, other compilers generate better code than gcc

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55278

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|8.5                         |9.4

--- Comment #26 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 8 branch is being closed.

[Bug rtl-optimization/55278] [9/10/11/12 Regression] Botan performance regressions, other compilers generate better code than gcc

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55278

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|9.4                         |9.5

--- Comment #27 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 9.4 is being released, retargeting bugs to GCC 9.5.

[Bug rtl-optimization/55278] [9/10/11/12 Regression] Botan performance regressions, other compilers generate better code than gcc

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55278

--- Comment #28 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Jakub Jelinek from comment #12)
> (force gcc to avoid xorw memory, %hireg and instead use movzwl memory,
> %sireg; ... xorl %sireg, %sireg2) and p2 was something similar for *xorqi_1.
> 
> Looking at icc generated assembly, it is interesting to see that the only
> HImode instructions it ever uses are rolw and movw stores, for everything
> else it uses
> movzwl loads and SImode arithmetics (well, I guess shift right
> shrw/sarw/rorw can't be avoided either).  Similarly, icc on the testcase
> doesn't emit any QImode instructions at all, while gcc emits tons of them
> and llvm something in between.

-mtune-ctrl=^himode_math,^qimode_math

will eliminate all HImode and QImode arithmetics.

[Bug rtl-optimization/55278] [10/11/12/13 Regression] Botan performance regressions, other compilers generate better code than gcc

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55278

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|9.5                         |10.4

--- Comment #29 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 9 branch is being closed

[Bug rtl-optimization/55278] [10/11/12/13 Regression] Botan performance regressions, other compilers generate better code than gcc

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55278

--- Comment #30 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Roger Sayle <sayle@gcc.gnu.org>:

https://gcc.gnu.org/g:acb1e6f43dc2bbedd1248ea61c7ab537a11fe59b

commit r13-1100-gacb1e6f43dc2bbedd1248ea61c7ab537a11fe59b
Author: Roger Sayle <roger@nextmovesoftware.com>
Date:   Wed Jun 15 09:31:13 2022 +0200

    Fold truncations of left shifts in match.pd

    Whilst investigating PR 55278, I noticed that the tree-ssa optimizers
    aren't eliminating the promotions of shifts to "int" as inserted by the
    c-family front-ends, instead leaving this simplification to be left to
    the RTL optimizers.  This patch allows match.pd to do this itself earlier,
    narrowing (T)(X << C) to (T)X << C when the constant C is known to be
    valid for the (narrower) type T.

    Hence for this simple test case:
    short foo(short x) { return x << 5; }

    the .optimized dump currently looks like:

    short int foo (short int x)
    {
      int _1;
      int _2;
      short int _4;

      <bb 2> [local count: 1073741824]:
      _1 = (int) x_3(D);
      _2 = _1 << 5;
      _4 = (short int) _2;
      return _4;
    }

    but with this patch, now becomes:

    short int foo (short int x)
    {
      short int _2;

      <bb 2> [local count: 1073741824]:
      _2 = x_1(D) << 5;
      return _2;
    }

    This is always reasonable as RTL expansion knows how to use
    widening optabs if it makes sense at the RTL level to perform
    this shift in a wider mode.

    Of course, there's often a catch.  The above simplification not only
    reduces the number of statements in gimple, but also allows further
    optimizations, for example including the perception of rotate idioms
    and bswap16.  Alas, optimizing things earlier than anticipated
    requires several testsuite changes [though all these tests have
    been confirmed to generate identical assembly code on x86_64].
    The only significant change is that the vectorization pass wouldn't
    previously lower rotations of signed integer types.  Hence this
    patch includes a refinement to tree-vect-patterns to allow signed
    types, by using the equivalent unsigned shifts.

    2022-06-15  Roger Sayle  <roger@nextmovesoftware.com>
                Richard Biener  <rguenther@suse.de>

    gcc/ChangeLog
            * match.pd (convert (lshift @1 INTEGER_CST@2)): Narrow integer
            left shifts by a constant when the result is truncated, and the
            shift constant is well-defined.
            * tree-vect-patterns.cc (vect_recog_rotate_pattern): Add
            support for rotations of signed integer types, by lowering
            using unsigned vector shifts.

    gcc/testsuite/ChangeLog
            * gcc.dg/fold-convlshift-4.c: New test case.
            * gcc.dg/optimize-bswaphi-1.c: Update found bswap count.
            * gcc.dg/tree-ssa/pr61839_3.c: Shift is now optimized before VRP.
            * gcc.dg/vect/vect-over-widen-1-big-array.c: Remove obsolete tests.
            * gcc.dg/vect/vect-over-widen-1.c: Likewise.
            * gcc.dg/vect/vect-over-widen-3-big-array.c: Likewise.
            * gcc.dg/vect/vect-over-widen-3.c: Likewise.
            * gcc.dg/vect/vect-over-widen-4-big-array.c: Likewise.
            * gcc.dg/vect/vect-over-widen-4.c: Likewise.

[Bug rtl-optimization/55278] [10/11/12/13 Regression] Botan performance regressions, other compilers generate better code than gcc

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55278

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|10.4                        |10.5

--- Comment #31 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 10.4 is being released, retargeting bugs to GCC 10.5.

[Bug rtl-optimization/55278] [10/11/12/13 Regression] Botan performance regressions, other compilers generate better code than gcc

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55278

--- Comment #32 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Does anyone understand the state of this bug report? Is the performance back up
in recent releases?

[Bug rtl-optimization/55278] [11/12/13/14 Regression] Botan performance regressions, other compilers generate better code than gcc

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55278

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|10.5                        |11.5

--- Comment #33 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 10 branch is being closed.