https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
Jakub Jelinek changed:
What|Removed |Added
Priority|P1 |P2
--- Comment #60 from Jakub Jelinek -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #59 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #58)
> If we don't want to go with #c35 at least for GCC 9, would the #c44 patch be
> still useful without it (does it ever trigger say on the kernel where it
> d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #58 from Jakub Jelinek ---
If we don't want to go with #c35 at least for GCC 9, would the #c44 patch be
still useful without it (does it ever trigger say on the kernel where it didn't
trigger before)?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #57 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
Peter Bergner changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|bergner at gcc do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #55 from Peter Bergner ---
Author: bergner
Date: Thu Apr 18 22:14:17 2019
New Revision: 270448
URL: https://gcc.gnu.org/viewcvs?rev=270448&root=gcc&view=rev
Log:
PR rtl-optimization/87871
* ira-lives.c (make_object_de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #54 from Segher Boessenkool ---
(In reply to Wilco from comment #52)
> (In reply to Segher Boessenkool from comment #48)
> > With just Peter's and Jakub's patch, it *improves* code size by 0.090%.
> > That does not fix this PR though
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #53 from Segher Boessenkool ---
(In reply to Richard Earnshaw from comment #51)
> In the more general case splitting this would produce worse code, not
> better, since then we'd end up with two instructions rather than one.
Sure, it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #52 from Wilco ---
(In reply to Segher Boessenkool from comment #48)
> With just Peter's and Jakub's patch, it *improves* code size by 0.090%.
> That does not fix this PR though :-/
But it does fix most of the codesize regression. Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #51 from Richard Earnshaw ---
(In reply to Segher Boessenkool from comment #50)
> The insn is
>
> (insn 7 3 8 2 (parallel [
> (set (reg:CC 100 cc)
> (compare:CC (reg:SI 0 r0 [116])
> (c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #50 from Segher Boessenkool ---
The insn is
(insn 7 3 8 2 (parallel [
(set (reg:CC 100 cc)
(compare:CC (reg:SI 0 r0 [116])
(const_int 0 [0])))
(set (reg/v:SI 4 r4 [orig:112
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #49 from Segher Boessenkool ---
(In reply to Wilco from comment #47)
> (In reply to Segher Boessenkool from comment #46)
> > With all three patches together (Peter's, mine, Jakub's), I get a code size
> > increase of only 0.047%, much
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #48 from Segher Boessenkool ---
With just Peter's and Jakub's patch, it *improves* code size by 0.090%.
That does not fix this PR though :-/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #47 from Wilco ---
(In reply to Segher Boessenkool from comment #46)
> With all three patches together (Peter's, mine, Jakub's), I get a code size
> increase of only 0.047%, much more acceptable. Now looking what that diff
> really *
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #46 from Segher Boessenkool ---
With all three patches together (Peter's, mine, Jakub's), I get a code size
increase of only 0.047%, much more acceptable. Now looking what that diff
really *is* :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
Peter Bergner changed:
What|Removed |Added
URL||https://gcc.gnu.org/ml/gcc-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #44 from Jakub Jelinek ---
Well, it requires that the RA looks specially for this kind of pattern and if
it ends up being a noop move, nothing simplifies the pattern again back to
normal comparison, and as Segher noted, it can negativ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #43 from Peter Bergner ---
(In reply to Jakub Jelinek from comment #40)
> The question is what the code size differences would be with those changes
> (i.e. how often does it help not to have *movsi_compare0 make RA decisions
> worse
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #42 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #40)
> The question is what the code size differences would be with those changes
> (i.e. how often does it help not to have *movsi_compare0 make RA decisions
> w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #41 from Segher Boessenkool ---
(In reply to Wilco from comment #38)
> Well the question really is what is bad about movsi_compare0 that could be
> easily fixed?
"Easily fixed"... There is no such thing here.
Because it is a parall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #40 from Jakub Jelinek ---
(In reply to Segher Boessenkool from comment #39)
> On a linux kernel defconfig build it increases code size by 0.567%.
> That seems a bit much :-(
>
> The peephole only recognises
>
> mov rA,rB
> cmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #39 from Segher Boessenkool ---
On a linux kernel defconfig build it increases code size by 0.567%.
That seems a bit much :-(
The peephole only recognises
mov rA,rB
cmp rB,#0
and not
mov rA,rB
cmp rA,#0
or
cmp rB,#0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #38 from Wilco ---
(In reply to Segher Boessenkool from comment #37)
> Yes, it is a balancing act. Which option works better?
Well the question really is what is bad about movsi_compare0 that could be
easily fixed?
The move is for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #37 from Segher Boessenkool ---
Yes, it is a balancing act. Which option works better?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #36 from Richard Earnshaw ---
(In reply to Segher Boessenkool from comment #35)
> Peter's patch solves this particular problem, but not the PR unfortunately.
>
> I finally understand Jakub's comment 30. This patch solves the PR (als
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #35 from Segher Boessenkool ---
Peter's patch solves this particular problem, but not the PR unfortunately.
I finally understand Jakub's comment 30. This patch solves the PR (also
without Peter's patch):
===
diff --git a/gcc/config
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
Peter Bergner changed:
What|Removed |Added
Attachment #46189|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
Peter Bergner changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #32 from Peter Bergner ---
(In reply to Peter Bergner from comment #26)
> (In reply to Vladimir Makarov from comment #25)
> > (In reply to Peter Bergner from comment #24)
> >> I don't know why r0 isn't in profitable_regs for pseudo 11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #31 from Segher Boessenkool ---
It's how you do a parallel of a mov and a flags set, which of course you
can have before RA, and you want created by combine, typically. Or do I
misunderstand the question?
(I though Arm have a "movs"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #30 from Jakub Jelinek ---
Is the *movsi_compare0 pattern actually ever a benefit before RA? At least in
this case it clearly results in a worse generated code rather than better, and
I bet in other cases too, it just ties the hands
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #29 from Peter Bergner ---
(In reply to Segher Boessenkool from comment #27)
> > Note: I'm assuming we're missing a \n after p116's empty conflicts above?
>
> The code is
Right. I already whipped up a patch that gives me:
;; a5(r1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #28 from Peter Bergner ---
Vlad, in looking at add_insn_allocno_copies(), it looks like it relies on
seeing REG_DEAD notes on whether to record a copy/shuffle that should be
handled. Shouldn't we instead be looking at whether the sou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #27 from Segher Boessenkool ---
(In reply to Peter Bergner from comment #26)
> ;; a4(r117,l0) conflicts: a3(r112,l0)
> ;; total conflict hard regs:
> ;; conflict hard regs:
>
> ;; a5(r116,l0) conflicts: cp0:a0(r111)<->a4(r11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #26 from Peter Bergner ---
(In reply to Vladimir Makarov from comment #25)
> (In reply to Peter Bergner from comment #24)
>> I don't know why r0 isn't in profitable_regs for pseudo 116.
>
> Profitable regs there contain also conflic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #25 from Vladimir Makarov ---
(In reply to Peter Bergner from comment #24)
> So improve_allocation() initially looks at using r0, but disregards it
> because check_hard_reg_p() returns false for r0, and that is because we fail
> this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #24 from Peter Bergner ---
So improve_allocation() initially looks at using r0, but disregards it because
check_hard_reg_p() returns false for r0, and that is because we fail this test:
/* Checking only profitable hard regs. */
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #23 from Segher Boessenkool ---
It says (I added some debug)
Insn 50(l0): point = 27
ignoring for conflicts:
(reg:SI 0 r0 [ a ])
but non_conflicting_reg_copy_p isn't called at all where it is improving
the allocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #22 from Peter Bergner ---
(In reply to Wilco from comment #21)
> (In reply to Vladimir Makarov from comment #20)
>> The question is why p116 conflicts with hr0. Before RA we have
>
> That's a bug since register copies should not cr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #21 from Wilco ---
(In reply to Vladimir Makarov from comment #20)
> (In reply to Wilco from comment #19)
> > (In reply to Peter Bergner from comment #18)
> > > (In reply to Segher Boessenkool from comment #15)
> > > > Popping a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #20 from Vladimir Makarov ---
(In reply to Wilco from comment #19)
> (In reply to Peter Bergner from comment #18)
> > (In reply to Segher Boessenkool from comment #15)
> > > Popping a5(r116,l0) -- assign reg 3
> > > Poppi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #19 from Wilco ---
(In reply to Peter Bergner from comment #18)
> (In reply to Segher Boessenkool from comment #15)
> > Popping a5(r116,l0) -- assign reg 3
> > Popping a3(r112,l0) -- assign reg 4
> > Popping a2(r11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #18 from Peter Bergner ---
(In reply to Segher Boessenkool from comment #15)
> Popping a5(r116,l0) -- assign reg 3
> Popping a3(r112,l0) -- assign reg 4
> Popping a2(r114,l0) -- assign reg 3
> Popping a0(r11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #16 from Segher Boessenkool ---
(Which would make insn 50 go away, if you prefer to look at it that way).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #15 from Segher Boessenkool ---
Forming thread by copy 0:a0r111-a4r117 (freq=500):
Result (freq=3500): a0r111(2500) a4r117(1000)
Forming thread by copy 2:a3r112-a5r116 (freq=125):
Result (freq=4500): a3r112
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #14 from Peter Bergner ---
(In reply to Segher Boessenkool from comment #12)
> Disposition:
> 0:r111 l0 03:r112 l0 41:r113 l0 22:r114 l0 3
> 5:r116 l0 44:r117 l0 0
>
> If r116 had been
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #13 from Richard Biener ---
Can we xfail/defer the bug?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #12 from Segher Boessenkool ---
(In reply to Segher Boessenkool from comment #11)
> (In reply to Wilco from comment #8)
> > mov r4, r0
> > cmp r4, #0
>
> Why does it copy r0 to r4 and then compare r4? On more modern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #11 from Segher Boessenkool ---
(In reply to Wilco from comment #8)
> push{r4, lr}
> mov r4, r0
> cmp r4, #0
Why does it copy r0 to r4 and then compare r4? On more modern machines it
is faster to compar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
Richard Earnshaw changed:
What|Removed |Added
CC||rearnsha at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #9 from Richard Earnshaw ---
(In reply to Wilco from comment #8)
> (In reply to Segher Boessenkool from comment #5)
> > The first one just needs an xfail. I don't know if it should be *-*-* there
> > or only arm*-*-* should be added.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
--- Comment #8 from Wil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
Priority|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
Ramana Radhakrishnan changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
Ramana Radhakrishnan changed:
What|Removed |Added
CC||ramana at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #5 from Segher Boessenkool ---
The first one just needs an xfail. I don't know if it should be *-*-* there
or only arm*-*-* should be added.
The other two need some debugging by someone who knows the target and/or
these tests.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #4 from Christophe Lyon ---
As of r266293, the following regressions reported here are still failing:
FAIL: gcc.dg/ira-shrinkwrap-prep-1.c scan-rtl-dump pro_and_epilogue "Performing
shrink-wrapping"
FAIL: gcc.target/arm/addr-modes-flo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #3 from Segher Boessenkool ---
I don't know, this is up to the arm people. I don't know if all problems
reported here are fixed now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #1 from Segher Boessenkool ---
Author: segher
Date: Mon Nov 5 21:18:22 2018
New Revision: 265821
URL: https://gcc.gnu.org/viewcvs?rev=265821&root=gcc&view=rev
Log:
combine: Don't make an intermediate reg for assigning to sfp (PR8787
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |9.0
62 matches
Mail list logo
