This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.

Ian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]