> Aurelien Buhrig <aurelien.buhrig.gcc@xxxxxxxxx> writes: > >> To sum things up, I'm trying to define movdf/movsi patterns with >> post_reload split and I have 7 HI regs in DATA_REGS class. 4 of them >> (R0:HI->R3:HI, Big endian) may carry function parameters and return value. >> >> When chaining function calls (lib calls), gcc may keep R0 alive between >> such calls, even when TARGET_SMALL_REGISTER_CLASSES_FOR_MODE_P returns >> true for such modes. For example, when chaining an extendsfdf lib call >> with a muldf, R0:DF is alive between the 2 calls. If the second >> parameter of the muldf function call need a reload, the reload may fail >> because DATA_REGS class has only 3 HI regs left. >> >> My GENERAL_REGS class is partitioned into {DATA_REGS,ADDRESS_REGS}. >> ADDRESS_REGS class could be used for such reloads. But it seems the IRA >> is stick to its preferred class, DATA_REG, despite the alternative class >> is GENERAL_REGS. Is it the normal behavior ? >> >> And is there a way to fix this without changing the ABI? > > I just want to let you know that you are asking a perfectly reasonable > question. I just don't happen to know the answer. You are running into > trouble in one of the most complex parts of gcc: > http://gcc.gnu.org/wiki/reload . I don't think it is IRA that is at > fault here. I think you are going to have to study the reload debugging > dumps to see if you can figure out a way to make this work. > > It's certainly true that gcc is happier with more registers. Having a > data type which burns more than half the available registers is always > going to be problematic. This is the answer I was afraid of. So I really need to deal with Satan... Thank you for your reply, Aurélien