https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99083
Richard Biener changed:
What|Removed |Added
Target Milestone|11.5|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99083
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|11.4|11.5
--- Comment #17 from Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99083
Richard Biener changed:
What|Removed |Added
Target Milestone|11.3|11.4
--- Comment #16 from Richard Biene
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99083
Richard Biener changed:
What|Removed |Added
Target Milestone|11.2|11.3
--- Comment #15 from Richard Biene
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99083
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|11.0|11.2
--- Comment #14 from Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99083
Uroš Bizjak changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99083
--- Comment #12 from Martin Jambor ---
For the record, I have benchmarked the patches from comment #4 and comment #10
on top of commit 6b1633378b7 (for which I already have unpatched benchmark
results) and the regression of 519.lbm_r compiled wit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99083
Uroš Bizjak changed:
What|Removed |Added
Target Milestone|--- |11.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99083
Uroš Bizjak changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99083
--- Comment #10 from Uroš Bizjak ---
(In reply to Richard Biener from comment #7)
> There are a lot of targets that define REG_ALLOC_ORDER ^
> HONOR_REG_ALLOC_ORDER and thus are affected by this change...
The following patch should solve this is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99083
--- Comment #9 from Martin Jambor ---
I will benchmark the patch later this week, just so that we know, but I agree
that reverting the patch and applying it again at the beginning of stage1 is
probably the best.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99083
--- Comment #8 from Uroš Bizjak ---
(In reply to Richard Biener from comment #7)
> Btw, for GCC 11 it might be tempting to simply revert the "no-op" change?
I agree, this is the safest way at this time. The situation now looks like
going into ra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99083
--- Comment #7 from Richard Biener ---
Btw, for GCC 11 it might be tempting to simply revert the "no-op" change?
There are a lot of targets that define REG_ALLOC_ORDER ^ HONOR_REG_ALLOC_ORDER
and thus are affected by this change...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99083
--- Comment #6 from Uroš Bizjak ---
As a side note, it is strange that ADJUST_REG_ALLOC_ORDER somehow require
REG_ALLOC_ORDER to be defined (c.f. Comment #3), while its documentation says:
The macro body should not assume anything about the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99083
--- Comment #5 from Uroš Bizjak ---
Martin, can you please benchmark the patch from Comment #4?
The patch is not totally trivial, because it introduces HONOR_REG_ALLOC_ORDER
to x86 and this define disables some other code in ira-color.c,
assign_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99083
--- Comment #4 from Uroš Bizjak ---
Created attachment 50185
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50185&action=edit
Proposed patch
Proposed patch that fixes ira-color.c and introduces HONOR_REG_ALLOC_ORDER.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99083
--- Comment #3 from Uroš Bizjak ---
It looks to me another one is in reload1.c, find_reg:
if (this_cost < best_cost
/* Among registers with equal cost, prefer caller-saved ones, or
use REG_ALLOC_ORDER if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99083
--- Comment #2 from Richard Biener ---
The following ira-color.c piece has heuristics that get triggered differently:
/* Return TRUE if spilling pseudo-registers whose numbers are in array
REGNOS is better than spilling pseudo-registers with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99083
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99083
--- Comment #1 from Uroš Bizjak ---
This should be a no-op. According to the documentation:
--q--
Macro: REG_ALLOC_ORDER
If defined, an initializer for a vector of integers, containing the numbers
of hard registers in the order in which GCC
20 matches
Mail list logo
