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.
Ian
