https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91154
Richard Biener changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91154
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91154
--- Comment #37 from rguenther at suse dot de ---
On September 1, 2019 12:05:52 PM GMT+02:00, ubizjak at gmail dot com
wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91154
>
>--- Comment #36 from Uroš Bizjak ---
>(In reply to Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91154
--- Comment #36 from Uroš Bizjak ---
(In reply to Richard Biener from comment #30)
> Hmm, it regresses the gcc.target/i386/minmax-6.c though and thus cactusADM
> (IIRC).
I was looking a bit into minmax6.c failure. Apparently, despite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91154
--- Comment #35 from Rainer Orth ---
Between 20190819 (r274678) and 20190820 (r274749), a new failure was
introduced:
+FAIL: gcc.target/i386/minmax-6.c scan-assembler-not rsp
Seen on both i386-pc-solaris2.11 with -m64 and x86_64-pc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91154
Rainer Orth changed:
What|Removed |Added
CC||ro at gcc dot gnu.org
--- Comment #34
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91154
--- Comment #33 from Richard Biener ---
(In reply to Uroš Bizjak from comment #32)
> (In reply to H.J. Lu from comment #31)
>
> > > No, IMO IRA should be "fixed" to avoid stack temporary and (based on some
> > > cost metric) use direct move for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91154
--- Comment #32 from Uroš Bizjak ---
(In reply to H.J. Lu from comment #31)
> > No, IMO IRA should be "fixed" to avoid stack temporary and (based on some
> > cost metric) use direct move for paradoxical subregs.
>
> The problem is
>
> /*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91154
--- Comment #31 from H.J. Lu ---
(In reply to Uroš Bizjak from comment #28)
> (In reply to Richard Biener from comment #26)
> > This is the powers of simplify_subreg I guess. We're lucky it doesn't do
> > this to arbitrary arithmetic.
> >
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91154
--- Comment #30 from Richard Biener ---
(In reply to Richard Biener from comment #29)
> (In reply to Uroš Bizjak from comment #27)
> > (In reply to rguent...@suse.de from comment #25)
> > > and STV converting single-instruction 'chains':
> > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91154
--- Comment #29 from Richard Biener ---
(In reply to Uroš Bizjak from comment #27)
> (In reply to rguent...@suse.de from comment #25)
> > and STV converting single-instruction 'chains':
> >
> > Collected chain #40...
> > insns: 381
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91154
--- Comment #28 from Uroš Bizjak ---
(In reply to Richard Biener from comment #26)
> This is the powers of simplify_subreg I guess. We're lucky it doesn't do
> this to arbitrary arithmetic.
>
> So we need to really change all defs we introduce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91154
--- Comment #27 from Uroš Bizjak ---
(In reply to rguent...@suse.de from comment #25)
> On Sat, 17 Aug 2019, ubizjak at gmail dot com wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91154
> >
> > --- Comment #24 from Uroš Bizjak ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91154
--- Comment #26 from Richard Biener ---
This is the powers of simplify_subreg I guess. We're lucky it doesn't do
this to arbitrary arithmetic.
So we need to really change all defs we introduce to vector modes instead of
making our live easy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91154
--- Comment #25 from rguenther at suse dot de ---
On Sat, 17 Aug 2019, ubizjak at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91154
>
> --- Comment #24 from Uroš Bizjak ---
> It looks that the patch introduced a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91154
--- Comment #24 from Uroš Bizjak ---
It looks that the patch introduced a (small?) runtime regression of 5% in
SPEC2000 300.twolf on haswell [1]. Maybe worth looking at.
[1]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91154
--- Comment #22 from Richard Biener ---
Author: rguenth
Date: Wed Aug 14 12:04:05 2019
New Revision: 274481
URL: https://gcc.gnu.org/viewcvs?rev=274481=gcc=rev
Log:
2019-08-14 Richard Biener
Uroš Bizjak
PR target/91154
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91154
--- Comment #23 from Richard Biener ---
Fixed for {x86_64,i?86}-*-* (hopefully).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91154
--- Comment #21 from Richard Biener ---
Author: rguenth
Date: Wed Aug 14 08:31:54 2019
New Revision: 274422
URL: https://gcc.gnu.org/viewcvs?rev=274422=gcc=rev
Log:
2019-08-14 Richard Biener
PR target/91154
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91154
--- Comment #20 from rguenther at suse dot de ---
On Wed, 7 Aug 2019, segher at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91154
>
> Segher Boessenkool changed:
>
>What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91154
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91154
--- Comment #18 from Bill Schmidt ---
Richi corrected me -- this is not vectorization, but use of SSE on lane zero to
do scalar computation.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91154
Bill Schmidt changed:
What|Removed |Added
Target|x86_64-*-* |x86_64-*-* powerpc*-*-*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91154
--- Comment #16 from Richard Biener ---
Ah, because x86_64_general_operand allows memory but the v alternative not
and reloading that is appearantly more expensive than not doing that and
reloading the general reg later. Fun. Changing that to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91154
--- Comment #15 from Richard Biener ---
So another idea would be to provide [us]{min,max} patterns for integer modes
that split after reload into a compare or jumpy sequence if allocated
using GPR regs but also allow SSE reg alternatives which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91154
--- Comment #14 from Richard Biener ---
With
Index: gcc/config/i386/i386.md
===
--- gcc/config/i386/i386.md (revision 273567)
+++ gcc/config/i386/i386.md (working copy)
@@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91154
--- Comment #13 from Richard Biener ---
Testcase for the loop in question:
void foo (int *dc, int *mc, int *tpdd, int *tpmd, int M)
{
int sc;
int k;
for (k = 1; k <= M; k++)
{
dc[k] = dc[k-1] + tpdd[k-1];
if ((sc = mc[k-1]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91154
--- Comment #12 from Richard Biener ---
On Skylake (Coffeelake actually) with the same binary (built for Haswell), the
improvement is down to 5%.
On Haswell, when I just replace the second conditional move like
vmovd %ebx, %xmm12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91154
--- Comment #11 from Richard Biener ---
One could in some awkward way also rewrite the loop to use integer SSE (so
we have access to min/max), relying on zero-filling scalar moves into %xmm
and then using vector integer operations. Need to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91154
--- Comment #10 from Richard Biener ---
Note that on Haswell the conditional moves are two uops while on Broadwell and
up
they are only one uop (overall loop 16 uops vs. 18 uops). IACA doesn't show
any particular issue (the iterations shoud
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91154
Richard Biener changed:
What|Removed |Added
Blocks||85559
--- Comment #9 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91154
--- Comment #8 from Richard Biener ---
(In reply to Jakub Jelinek from comment #6)
> So pretty much undo all ifcvt into conditional moves (aka pretend the target
> doesn't have cmov) or something else?
> The problem is that cmov isn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91154
--- Comment #7 from Uroš Bizjak ---
This is PR 56309, again and again.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91154
--- Comment #6 from Jakub Jelinek ---
So pretty much undo all ifcvt into conditional moves (aka pretend the target
doesn't have cmov) or something else?
The problem is that cmov isn't unconditionally bad or unconditionally good and
moving in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91154
Richard Biener changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91154
Richard Biener changed:
What|Removed |Added
Keywords|needs-bisection |
Status|ASSIGNED
36 matches
Mail list logo
