https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #67 from Richard Biener ---
(In reply to Segher Boessenkool from comment #66)
> (In reply to rguent...@suse.de from comment #64)
> > As promised I'm going to revert the revert after 14.1 is released
> > (hopefully tomorrow).
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #66 from Segher Boessenkool ---
(In reply to rguent...@suse.de from comment #64)
> As promised I'm going to revert the revert after 14.1 is released
> (hopefully tomorrow).
Thank you! beer++
> As for distros I have decided to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #65 from Segher Boessenkool ---
On Sat, May 04, 2024 at 01:14:18PM +, sarah.kriesch at opensuse dot org
wrote:
Do not reply to a PR comment in private mail.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #64 from rguenther at suse dot de ---
On Sat, 4 May 2024, segher at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
>
> --- Comment #61 from Segher Boessenkool ---
> We used to do the wrong thing in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #63 from Segher Boessenkool ---
(In reply to Sarah Julia Kriesch from comment #62)
> (In reply to Segher Boessenkool from comment #61)
> > (In reply to Sarah Julia Kriesch from comment #60)
> > > I have to agree with Richard. This
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #62 from Sarah Julia Kriesch ---
(In reply to Segher Boessenkool from comment #61)
> (In reply to Sarah Julia Kriesch from comment #60)
> > I have to agree with Richard. This problem has been serious for a long time
> > but has been
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #61 from Segher Boessenkool ---
(In reply to Sarah Julia Kriesch from comment #60)
> I have to agree with Richard. This problem has been serious for a long time
> but has been ignored by IBM based on distribution choices.
What?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #60 from Sarah Julia Kriesch ---
I have to agree with Richard. This problem has been serious for a long time but
has been ignored by IBM based on distribution choices.
Anyway, we want to live within the open source community
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #59 from Richard Biener ---
(In reply to Segher Boessenkool from comment #57)
> (In reply to Richard Biener from comment #56)
> > The fix was reverted but will be re-instantiated for GCC 15 by me.
>
> And I still protest.
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #58 from Jakub Jelinek ---
(In reply to Segher Boessenkool from comment #57)
> (In reply to Richard Biener from comment #56)
> > The fix was reverted but will be re-instantiated for GCC 15 by me.
>
> And I still protest.
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #57 from Segher Boessenkool ---
(In reply to Richard Biener from comment #56)
> The fix was reverted but will be re-instantiated for GCC 15 by me.
And I still protest.
PR101523 is a very serious problem, way way way more "P1" than
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
Richard Biener changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #55 from Richard Biener ---
(In reply to Segher Boessenkool from comment #54)
> Propose a patch, then? With justification. It should also work for 10x
> bigger testcases.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #54 from Segher Boessenkool ---
Propose a patch, then? With justification. It should also work for 10x
bigger testcases.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #53 from Richard Biener ---
So just to recap, with reverting the change and instead doing
diff --git a/gcc/combine.cc b/gcc/combine.cc
index a4479f8d836..ff25752cac4 100644
--- a/gcc/combine.cc
+++ b/gcc/combine.cc
@@ -4186,6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
Segher Boessenkool changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #51 from Segher Boessenkool ---
(In reply to Richard Biener from comment #46)
> Maybe combine already knows that it just "keeps i2" rather than replacing it?
It never does that. Instead, it thinks it is making a new I2, but it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #50 from GCC Commits ---
The master branch has been updated by Segher Boessenkool :
https://gcc.gnu.org/g:839bc42772ba7af66af3bd16efed4a69511312ae
commit r14-9692-g839bc42772ba7af66af3bd16efed4a69511312ae
Author: Segher
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #33 from Andreas Krebbel ---
(In reply to Andrew Pinski from comment #26)
...
> I suspect if we change the s390 backend just slightly to set the cost when
> there is an index to the address to 1 for the MEM, combine won't be acting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #32 from Andreas Krebbel ---
(In reply to Segher Boessenkool from comment #25)
> So this testcase compiles on powerpc64-linux (-O2) in about 34s. Is s390x
> way worse, or is this in lie what you are seeing?
Way worse. See #c22 :
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #31 from Segher Boessenkool ---
I need a configure flag, hrm.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #29 from Segher Boessenkool ---
I did manage to build one, but it does not know _Float64x and stuff.
Do you have a basic C-only testcase, maybe?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #28 from Segher Boessenkool ---
For Q111: on rs6000:
;; Combiner totals: 53059 attempts, 52289 substitutions (7135 requiring new
space),
;; 229 successes.
I don't have C++ cross-compilers built (those are not trivial to do, hrm).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #27 from Andrew Pinski ---
(In reply to Segher Boessenkool from comment #25)
> So this testcase compiles on powerpc64-linux (-O2) in about 34s. Is s390x
> way worse, or is this in lie what you are seeing?
I should note that in the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #26 from Andrew Pinski ---
So looking into the s390 backend, I notice that s390_address_cost says the
addressing mode `base+index` is slightly more expensive than just `base`:
from s390_address_cost :
return ad.indx? COSTS_N_INSNS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #25 from Segher Boessenkool ---
So this testcase compiles on powerpc64-linux (-O2) in about 34s. Is s390x
way worse, or is this in lie what you are seeing?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #24 from Segher Boessenkool ---
(In reply to Andreas Krebbel from comment #21)
> Wouldn't it in this particular case be possible to recognize already in
> try_combine that separating the move out of the parallel cannot lead to
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #23 from Andreas Krebbel ---
Created attachment 57646
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57646=edit
Testcase for comment #22
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #22 from Andreas Krebbel ---
I did a git bisect which ended up pointing at this commit, somewhere between
GCC 8 and 9:
commit c4c5ad1d6d1e1e1fe7a1c2b3bb097cc269dc7306 (bad)
Author: Segher Boessenkool
Date: Mon Jul 30 15:18:17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #21 from Andreas Krebbel ---
(In reply to Segher Boessenkool from comment #16)
...
> When some insns have changed (or might have changed, combine does not always
> know
> the details), combinations of the insn with later insns are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #20 from Andreas Krebbel ---
(In reply to Segher Boessenkool from comment #17)
...
> So what is really happening? And, when did this start, anyway, because
> apparently at some point in time all was fine?
Due to the C++ constructs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #19 from Andreas Krebbel ---
(In reply to Sarah Julia Kriesch from comment #15)
> (In reply to Segher Boessenkool from comment #13)
> > (In reply to Sarah Julia Kriesch from comment #12)
> > A bigger case of what? What do you mean?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #18 from Andrew Pinski ---
Hmm, looking at what is done in combine, I wonder why forwprop didn't do the
address add into the memory. That would definitely decrease the # of combines
being done.
Maybe it is because it is used more
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #17 from Segher Boessenkool ---
Why does this happen so extremely often for s390x customers? It should from
first principles happen way more often for e.g. powerpc, but we never see such
big problems, let alone "all of the time"!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #16 from Segher Boessenkool ---
(In reply to Andreas Krebbel from comment #14)
> If my analysis from comment #1 is correct, combine does superfluous steps
> here. Getting rid of this should not cause any harm, but should be
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #15 from Sarah Julia Kriesch ---
(In reply to Segher Boessenkool from comment #13)
> (In reply to Sarah Julia Kriesch from comment #12)
> A bigger case of what? What do you mean?
Not only one software package is affected by this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #14 from Andreas Krebbel ---
If my analysis from comment #1 is correct, combine does superfluous steps here.
Getting rid of this should not cause any harm, but should be beneficial for
other targets as well. I agree that the patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #13 from Segher Boessenkool ---
(In reply to Sarah Julia Kriesch from comment #12)
> I expect also, that this bug is a bigger case.
A bigger case of what? What do you mean?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #12 from Sarah Julia Kriesch ---
Raise your hand if you need anything new from my side.
We have got enough use cases in our build system and upstream open source
projects gave warnings to remove the s390x support because of long
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #11 from Segher Boessenkool ---
Okay, so it is a function with a huge BB, so this is not a regression at all,
there will have been incredibly many combination attempts since the day combine
has existed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #10 from Andreas Krebbel ---
Created attachment 57599
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57599=edit
Testcase - somewhat reduced from libecpint
Verified with rev 146f16c97f6
cc1plus -O2 t.cc
try_combine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #9 from Segher Boessenkool ---
Yeah.
Without a testcase we do not know what is going on. Likely it is a testcase
with some very big basic block, which naturally gives very many combination
opportunities: the problem by nature is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
Sam James changed:
What|Removed |Added
CC||sjames at gcc dot gnu.org
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
Sarah Julia Kriesch changed:
What|Removed |Added
CC||sarah.kriesch at opensuse dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #6 from Segher Boessenkool ---
There is no attached testcase, btw. This makes investigating this kind of
tricky ;-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #5 from Segher Boessenkool ---
Hrm. When did this start, can you tell?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
Andreas Krebbel changed:
What|Removed |Added
CC||stefansf at linux dot ibm.com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
Segher Boessenkool changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |segher at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #2 from Andreas Krebbel ---
Created attachment 51174
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51174=edit
Experimental Fix
With that patch the number of combine attempts goes back to normal.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #1 from Andreas Krebbel ---
This appears to be triggered by try_combine unnecessarily setting back the
position by returning the i2 insn.
When 866 is inserted into 973 866 still needs to be kept around for other
users. So
51 matches
Mail list logo
