https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #49 from Sarah Julia Kriesch ---
(In reply to Sam James from comment #44)
> I'm really curious as to if there's other test cases which could be shared,
> as Andreas mentioned distributions were complaining about this even. That's
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #48 from Richard Biener ---
So another "simple" way is to keep the redundant insn walking ("it's O(1)") but
remember processsed insns and only re-process those we mark as such.
There might be a free "visited" bit on rtx_insn, who
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #47 from Richard Biener ---
The rtx_equal_p change gets us 50% improvement only, it's necessary to also
disable the added_{links,notes}_insn extra re-processing to get us all the
way to -O1 speed. We'd need the worklist to avoid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #46 from Richard Biener ---
Maybe combine already knows that it just "keeps i2" rather than replacing it?
When !newi2pat we seem to delete i2. Anyway, somebody more familiar with
combine should produce a good(TM) patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #45 from Sam James ---
(ah, not andreas, but sarah)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #44 from Sam James ---
I'm really curious as to if there's other test cases which could be shared, as
Andreas mentioned distributions were complaining about this even. That's
unlikely if it's a single degenerate case.
Even listing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #43 from Richard Biener ---
The interesting bit is that there are only 12026 overall loglinks, the
number of combine attempts is way higher than that would suggest also
given the few successful combinations. So something is odd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
Richard Biener changed:
What|Removed |Added
Known to fail||14.0
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #41 from Richard Biener ---
(In reply to Segher Boessenkool from comment #38)
> (In reply to Richard Biener from comment #36)
[...]
> But linear is linear, and stays linear, for way too big code it is just as
> acceptable as for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #40 from Richard Biener ---
(In reply to Segher Boessenkool from comment #39)
> (In reply to Richard Biener from comment #37)
> > Created attachment 57753 [details]
> > quick attempt at a limit
> >
> > So like this?
>
> Hrm. It
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #39 from Segher Boessenkool ---
(In reply to Richard Biener from comment #37)
> Created attachment 57753 [details]
> quick attempt at a limit
>
> So like this?
Hrm. It should be possible to not have the same test 28 times. Just
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #38 from Segher Boessenkool ---
(In reply to Richard Biener from comment #36)
> > No, it definitely should be done. As I showed back then, it costs less than
> > 1%
> > extra compile time on *any platform* on average, and it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #37 from Richard Biener ---
Created attachment 57753
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57753=edit
quick attempt at a limit
So like this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #36 from Richard Biener ---
(In reply to Segher Boessenkool from comment #35)
> (In reply to Richard Biener from comment #34)
> > The change itself looks reasonable given costs, though maybe 2 -> 2
> > combinations should not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #35 from Segher Boessenkool ---
(In reply to Richard Biener from comment #34)
> The change itself looks reasonable given costs, though maybe 2 -> 2
> combinations should not trigger when the cost remains the same? In
> this case it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #34 from Richard Biener ---
(In reply to Andreas Krebbel from comment #1)
> 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
16 matches
Mail list logo
