https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99083
--- Comment #1 from Uroš Bizjak <ubizjak at gmail dot com> ---
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 should prefer to use them (from
most preferred to least).
If this macro is not defined, registers are used lowest numbered first (all
else being equal).
One use of this macro is on machines where the highest numbered registers
must always be saved and the save-multiple-registers instruction supports only
sequences of consecutive registers. On such machines, define REG_ALLOC_ORDER to
be an initializer that lists the highest numbered allocable register first.
--/q--
and the patch removed:
-#define REG_ALLOC_ORDER
\
-{ 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15,
\
- 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, \
- 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, \
- 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, \
- 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75 }
It is trivial to revert the offending commit, but I think that this PR warrants
some more analysis of the underlying problem, presumably in the generic code.
