Vladimir Makarov <vmaka...@redhat.com> writes: > Instead of using explicitly necessary number of registers, I used > contains_reg_of_mode which also checks the number of necessary registers > but also it checks that the register class can hold value of given > mode. This resulted in different register pressure classes (before the > patch, they were GENERAL_REGS and FLOAT_REGS for x86. They became only > INT_FLOAT_REGS) because it became not costly to hold integer mode value > in FLOAT_REGS. The new register pressure class in own turn resulted in > low register pressure and one region allocation in most cases instead of > multiple region RA. As a consequence, we got a big degradation on Intel > 32 bit targets.
Sorry, I know I should be able to work this out, but could you explain in a bit more detail why contains_reg_of_mode (CL1, MODE) was wrong? The loop is calculating costs for moving values of mode MODE into and out of CL1, and I wouldn't have expected those costs to have any meaning if CL1 can't in fact store anything of mode MODE. It just looked at first glance as though: > /* Some subclasses are to small to have enough registers to hold > a value of MODE. Just ignore them. */ > - if (! contains_reg_of_mode[cl1][mode]) > + if (ira_reg_class_max_nregs[cl1][mode] > ira_available_class_regs[cl1]) > continue; > COPY_HARD_REG_SET (temp_hard_regset, reg_class_contents[cl1]); > AND_COMPL_HARD_REG_SET (temp_hard_regset, no_unit_alloc_regs); expects CLASS_MAX_NREGS (CL1, MODE) to have a certain meaning even if CL1 can't store values of mode MODE, whereas I'd assumed it was undefined in that case. Richard
