This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: movdi/df + reload issues
> Aurelien Buhrig <aurelien.buhrig.gcc@gmail.com> 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