https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
Jakub Jelinek changed:
What|Removed |Added
Priority|P1 |P2
--- Comment #55 from Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #54 from Wilco ---
(In reply to Jeffrey A. Law from comment #53)
> Realistically the register allocation issues are not going to get addressed
> this cycle nor are improvements to the overall handling of RMW insns in
> combine. So
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #53 from Jeffrey A. Law ---
Realistically the register allocation issues are not going to get addressed
this cycle nor are improvements to the overall handling of RMW insns in
combine. So we're going to be stuck with bandaids.
I've
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #52 from Wilco ---
(In reply to Jeffrey A. Law from comment #49)
> I think the insv_1 (and it's closely related insv_2) regressions can be
> fixed by a single ior/and pattern in the backend or by hacking up combine a
> bit. I'm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #51 from Steve Ellcey ---
Author: sje
Date: Thu Apr 11 18:03:49 2019
New Revision: 270289
URL: https://gcc.gnu.org/viewcvs?rev=270289=gcc=rev
Log:
2018-04-11 Steve Ellcey
PR rtl-optimization/87763
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #50 from Steve Ellcey ---
Author: sje
Date: Thu Apr 11 18:02:41 2019
New Revision: 270288
URL: https://gcc.gnu.org/viewcvs?rev=270288=gcc=rev
Log:
2018-04-11 Steve Ellcey
PR rtl-optimization/87763
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #49 from Jeffrey A. Law ---
I think the insv_1 (and it's closely related insv_2) regressions can be fixed
by a single ior/and pattern in the backend or by hacking up combine a bit. I'm
still playing with the latter, but may have to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #48 from Steve Ellcey ---
(In reply to Richard Biener from comment #47)
> What's the state of regressions left? Can we xfail the rest and defer the
> bug?
I submitted a patch to fix gcc.target/aarch64/lsl_asr_sbfiz.c
That email is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #47 from Richard Biener ---
What's the state of regressions left? Can we xfail the rest and defer the bug?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #46 from Steve Ellcey ---
Author: sje
Date: Wed Apr 10 20:29:57 2019
New Revision: 270267
URL: https://gcc.gnu.org/viewcvs?rev=270267=gcc=rev
Log:
2018-04-10 Steve Ellcey
PR rtl-optimization/87763
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #45 from Steve Ellcey ---
Author: sje
Date: Wed Apr 10 20:28:19 2019
New Revision: 270266
URL: https://gcc.gnu.org/viewcvs?rev=270266=gcc=rev
Log:
2018-04-10 Steve Ellcey
PR rtl-optimization/87763
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #44 from Segher Boessenkool ---
(In reply to Jeffrey A. Law from comment #43)
> The problem with your suggestions Segher is that we'd have to do them for
> every target which defines insns with a zero_extract destination and that's
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #43 from Jeffrey A. Law ---
The problem with your suggestions Segher is that we'd have to do them for every
target which defines insns with a zero_extract destination and that's been the
well understood way to handle this stuff for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #42 from Segher Boessenkool ---
The "movk" failures... This is from insv_1.c:
Trying 7, 6 -> 8:
7: r95:DI=0x1d6b
6: r93:DI=r97:DI&0x
REG_DEAD r97:DI
8: r94:DI=r93:DI|r95:DI
REG_DEAD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #41 from Segher Boessenkool ---
Seeing that the code in your examples can be expressed as a bitfield insert
requires that combine sees that only the low 8 bits of reg 93 can be non-zero,
by the way. It usually does not know this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #40 from Segher Boessenkool ---
You'll get much better results if you don't use insv in your machine
description; writing it with the input and output separate (and then
using a "0" constraint) is much friendlier to the optimisers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
Jeffrey A. Law changed:
What|Removed |Added
CC||segher at kernel dot
crashing.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #38 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #37)
> (In reply to Jeffrey A. Law from comment #36)
> > I wonder if we could pass in a scratch register from try_combine down to
> > make_field_assignment to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #37 from Andrew Pinski ---
(In reply to Jeffrey A. Law from comment #36)
> I wonder if we could pass in a scratch register from try_combine down to
> make_field_assignment to facilitate something like this...
I have found that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #36
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #35 from Tamar Christina ---
Hi Steve,
Thanks for the patch and sorry for the delay! I don't think it was the
intention to discourage people. I have also pinged the AArch64 maintainers to
review it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #34 from Steve Ellcey ---
I submitted a patch that would fix gcc.target/aarch64/combine_bfi_1.c back
in February but have not gotten any feedback on the final version of the
patch despite a couple of pings. I have resubmitted the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
Tamar Christina changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #32 from Wilco ---
Author: wilco
Date: Fri Jan 25 13:29:06 2019
New Revision: 268265
URL: https://gcc.gnu.org/viewcvs?rev=268265=gcc=rev
Log:
[PATCH][AArch64] Fix generation of tst (PR87763)
The TST instruction no longer matches in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #31 from Segher Boessenkool ---
Please use -fdump-rtl-combine-all if you want to see the whole story.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #30 from Jakub Jelinek ---
Looking at rs6000, I see:
*rotl3_insert and *rotl3_insert_2 patterns doing what has been
discussed above (two variants for IOR operand order), *rotl3_insert_3
without one of the ANDs (not needing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #29 from Jakub Jelinek ---
(In reply to Richard Earnshaw from comment #28)
> Yes, it's always possible to write patterns for this, but as you point out,
> we end up with many variants: insert in bottom (no left shift), insert in
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #28 from Richard Earnshaw ---
Yes, it's always possible to write patterns for this, but as you point out, we
end up with many variants: insert in bottom (no left shift), insert in top
(left shift then doesn't need an additional AND
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #27 from Jakub Jelinek ---
So, looking at what other targets do on the #c21 testcase, e.g. rs6000 actually
matches what the combiner produces:
Trying 10, 9 -> 11:
10: r131:SI=r133:DI#0&0xfff00fff
REG_DEAD r133:DI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #26 from Richard Earnshaw ---
(In reply to Jakub Jelinek from comment #25)
> We have BIT_INSERT_EXPR on GIMPLE, which in the end is a quarternary
> operation previous value, value to insert, bit position and bit size (the
> last one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #25 from Jakub Jelinek ---
We have BIT_INSERT_EXPR on GIMPLE, which in the end is a quarternary operation
previous value, value to insert, bit position and bit size (the last one is
implicit in this GIMPLE op), so you're arguing we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #24 from Richard Earnshaw ---
(In reply to Steve Ellcey from comment #21)
> Successfully matched this instruction:
> (set (zero_extract:SI (reg/i:SI 0 x0)
> (const_int 8 [0x8])
> (const_int 12 [0xc]))
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #23 from Wilco ---
Author: wilco
Date: Tue Jan 22 17:49:46 2019
New Revision: 268159
URL: https://gcc.gnu.org/viewcvs?rev=268159=gcc=rev
Log:
Fix vect-nop-move.c test
Fix a failing test - changes in Combine mean the test now fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #22 from Wilco ---
(In reply to Steve Ellcey from comment #21)
> If I look at this specific example:
>
> int f2 (int x, int y)
> {
> return (x & ~0x0ff000) | ((y & 0x0ff) << 12);
> }
>
> Is this because of x0 (a hard register)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #21 from Steve Ellcey ---
If I look at this specific example:
int f2 (int x, int y)
{
return (x & ~0x0ff000) | ((y & 0x0ff) << 12);
}
Before the combine change, I see in x.c.260r.combine:
Trying 8, 9 -> 15:
8:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #20 from Segher Boessenkool ---
(In reply to Wilco from comment #19)
> (In reply to Segher Boessenkool from comment #18)
> > https://gcc.gnu.org/ml/gcc/2019-01/msg00112.html
>
> Thanks, I hadn't noticed that yet... I need to look at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #19 from Wilco ---
(In reply to Segher Boessenkool from comment #18)
> https://gcc.gnu.org/ml/gcc/2019-01/msg00112.html
Thanks, I hadn't noticed that yet... I need to look at it in more detail, but
are you saying that combine no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #18 from Segher Boessenkool ---
https://gcc.gnu.org/ml/gcc/2019-01/msg00112.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #17 from Wilco ---
(In reply to Vladimir Makarov from comment #14)
> I've checked cvtf_1.c generated code and I don't see additional fmov
> anymore. I guess it was fixed by an ira-costs.c change (a special
> consideration of moves
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #16 from Segher Boessenkool ---
(In reply to Wilco from comment #13)
> (In reply to Segher Boessenkool from comment #12)
> > Before the change combine forwarded all argument (etc.) hard registers
> > wherever
> > it could, doing part
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #14 from Vladimir Makarov ---
I've checked cvtf_1.c generated code and I don't see additional fmov anymore.
I guess it was fixed by an ira-costs.c change (a special consideration of
moves containing hard regs). I think this PR is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #13 from Wilco ---
(In reply to Segher Boessenkool from comment #12)
> Before the change combine forwarded all argument (etc.) hard registers
> wherever
> it could, doing part of RA's job (and doing a lousy job of it). If after the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #12 from Segher Boessenkool ---
Before the change combine forwarded all argument (etc.) hard registers wherever
it could, doing part of RA's job (and doing a lousy job of it). If after the
change it no longer two ranges, than a)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #11 from Wilco ---
A SPEC2006 run shows the codesize cost of make_more_copies is 0.05%.
Practically all tests are worse, the largest increases are perlbench at 0.20%,
gromacs 0.12%, calculix 0.12%, soplex 0.08%, xalancbmk 0.07%, wrf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #10 from Sam Tebbs ---
Author: samtebbs
Date: Fri Jan 4 16:26:38 2019
New Revision: 267579
URL: https://gcc.gnu.org/viewcvs?rev=267579=gcc=rev
Log:
[PATCH][GCC][Aarch64] Change expected bfxil count in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
samtebbs at gcc dot gnu.org changed:
What|Removed |Added
CC||samtebbs at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #7 from Wilco ---
(In reply to Richard Earnshaw from comment #6)
> (In reply to Wilco from comment #5)
> > (In reply to Segher Boessenkool from comment #4)
> > > (In reply to Wilco from comment #3)
> > > > IRA costing doesn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #6 from Richard Earnshaw ---
(In reply to Wilco from comment #5)
> (In reply to Segher Boessenkool from comment #4)
> > (In reply to Wilco from comment #3)
> > > IRA costing doesn't consider the possibility of a simple move being
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #5 from Wilco ---
(In reply to Segher Boessenkool from comment #4)
> (In reply to Wilco from comment #3)
> > IRA costing doesn't consider the possibility of a simple move being
> > removeable.
>
> Not always, yeah (only if you have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #4 from Segher Boessenkool ---
(In reply to Wilco from comment #3)
> IRA costing doesn't consider the possibility of a simple move being
> removeable.
Not always, yeah (only if you have matching constraints, which are silly to
have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
--- Comment #3 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
Richard Biener changed:
What|Removed |Added
Target||aarch64
Target Milestone|---
55 matches
Mail list logo
