> > This is OK. In general, I think we could also go with assert on
> > mem_cost <= 2, since that is kind of bogus setting (I don't think we
> > will ever need to support x86 CPU with memory stores being as cheap as
> > reg-reg moves), but current form is good.
>
> Unless the loading/storing integer costs in x86-tune-costs.h are unrelated,
> there are tons of tunings which have cost 2:
>
> grep
> '\(processor_costs\|2.*cost.of.loading.integer\|2.*cost.of.storing.integer\)'
> x86-tune-costs.h
> struct processor_costs ix86_size_cost = {/* costs for tuning for size */
> {2, 2, 2}, /* cost of loading integer registers
> {2, 2, 2}, /* cost of storing integer registers */
> {2, 2, 2}, /* cost of loading integer registers
> {2, 2, 2}, /* cost of storing integer registers */
> struct processor_costs i386_cost = { /* 386 specific costs */
> {2, 4, 2}, /* cost of loading integer registers
> {2, 4, 2}, /* cost of storing integer registers */
> {2, 4, 2}, /* cost of loading integer registers
> {2, 4, 2}, /* cost of storing integer registers */
> struct processor_costs i486_cost = { /* 486 specific costs */
> {2, 4, 2}, /* cost of loading integer registers
> {2, 4, 2}, /* cost of storing integer registers */
> {2, 4, 2}, /* cost of loading integer registers
> {2, 4, 2}, /* cost of storing integer registers */
> struct processor_costs pentium_cost = {
> {2, 4, 2}, /* cost of loading integer registers
> {2, 4, 2}, /* cost of storing integer registers */
> {2, 4, 2}, /* cost of loading integer registers
> {2, 4, 2}, /* cost of storing integer registers */
> struct processor_costs lakemont_cost = {
> {2, 4, 2}, /* cost of loading integer registers
> {2, 4, 2}, /* cost of storing integer registers */
> {2, 4, 2}, /* cost of loading integer registers
> {2, 4, 2}, /* cost of storing integer registers */
> struct processor_costs pentiumpro_cost = {
> {2, 2, 2}, /* cost of storing integer registers */
> {2, 2, 2}, /* cost of storing integer registers */
> struct processor_costs geode_cost = {
> {2, 2, 2}, /* cost of loading integer registers
> {2, 2, 2}, /* cost of storing integer registers */
> {2, 2, 2}, /* cost of loading integer registers
> {2, 2, 2}, /* cost of storing integer registers */
> struct processor_costs k6_cost = {
> {2, 3, 2}, /* cost of storing integer registers */
> {2, 3, 2}, /* cost of storing integer registers */
Hmm, this is bit odd, indeed. ix86_register_move_cost return 2 for
integer-integer and all costs should be relative to that to get
meaningful register class preferences.
This is even documented:
/* Start of register allocator costs. integer->integer move cost is 2. */
4, /* cost for loading QImode using movzbl */
{2, 4, 2}, /* cost of loading integer registers
in QImode, HImode and SImode.
Relative to reg-reg move (2). */
{2, 4, 2}, /* cost of storing integer registers */
Thus I think all loads/stores should be more expensive than that (at
least by 1 since they are longer). I can not claim it predates me since
I added k6_cost.
I will see how changing those costs to something more realistic changes
the codegeon. these costs were tuned for old RA and I do not think
(possibly except for lakemont) they were retuned for IRA. But even old
RA was comparing relative cost of a spill to reg-reg move...
So the patch is OK without an assert.
Honza
