a peculiar fpload problem on an inferior processor

a peculiar fpload problem on an inferior processor

[Amker.Cheng]

Hi :
   Our processor has an errata that the direct fpu load cannot work right,
so I have to substitute instruction sequence "load_into_gpr ; move_gpr_into_fpr"
for direct fpload insn.
  Currently I thought of two potential methods as following:

method 1:
   step1 :  keep a scratch register when expanding fpload;
   step2 :  split insn fpload into "load_into_gpr ; move_gpr_into_fpr"
sequence by using the reserved scratch register;

method 2:
   generate "load_into_gpr ; move_gpr_into_fpr" when expanding directly.

I have only tried the first method, which end up with the errro "insn
does not satisfy its constraints".
after tracing cc1, found that the problematic insn was generated by
reloading, which trying to
spill float register into memory, which itself using direct fpload.

here is the question : Is it possible to replace all direct fpload
with "load_into_gpr ; move_gpr_into_fpr"
sequence. I doubt it since the reload pass might generate direct
fpload insn for spilling fpu register.

BTW, I prefer to do the replacement in gcc, rather than assembler,
since it might produce lots of pipeline stalls.

So, any advice? Thank you all.

-- 
Best Regards.

Re: a peculiar fpload problem on an inferior processor

[Dave Korn]

On 06/05/2010 10:00, Amker.Cheng wrote:

> here is the question : Is it possible to replace all direct fpload
> with "load_into_gpr ; move_gpr_into_fpr"
> sequence. I doubt it since the reload pass might generate direct
> fpload insn for spilling fpu register.

  It is possible.  Your expander can handle it before reload; to handle it
during and after reload, you need to implement a TARGET_SECONDARY_RELOAD hook.

http://gcc.gnu.org/onlinedocs/gccint/Register-Classes.html#index-TARGET_005fSECONDARY_005fRELOAD-3974

    cheers,
      DaveK

Re: a peculiar fpload problem on an inferior processor

[Amker.Cheng]

>  It is possible.  Your expander can handle it before reload; to handle it
> during and after reload, you need to implement a TARGET_SECONDARY_RELOAD hook.
>
> http://gcc.gnu.org/onlinedocs/gccint/Register-Classes.html#index-TARGET_005fSECONDARY_005fRELOAD-3974
>
Thanks Dave, It works, but I found that reload is not the only pass
which might generate fpload/fpstore instructions.
I am working with GCC 4.4(mips), there is function(mips_emit_move),
which is called in many pass after register allocation
and might generate fpload/fpstore.
For example, in pass pro_and_epilogue, it generates load/store for fpu
register which saved by function prologue/epilogue.

Seems I have to track down all calling of this function and make sure
it works in my way.

Thanks.

-- 
Best Regards.

Re: a peculiar fpload problem on an inferior processor

[Dave Korn]

On 07/05/2010 12:04, Amker.Cheng wrote:
>>  It is possible.  Your expander can handle it before reload; to handle it
>> during and after reload, you need to implement a TARGET_SECONDARY_RELOAD hook.
>>
>> http://gcc.gnu.org/onlinedocs/gccint/Register-Classes.html#index-TARGET_005fSECONDARY_005fRELOAD-3974
>>
> Thanks Dave, It works, but I found that reload is not the only pass
> which might generate fpload/fpstore instructions.
> I am working with GCC 4.4(mips), there is function(mips_emit_move),
> which is called in many pass after register allocation
> and might generate fpload/fpstore.
> For example, in pass pro_and_epilogue, it generates load/store for fpu
> register which saved by function prologue/epilogue.
> 
> Seems I have to track down all calling of this function and make sure
> it works in my way.

  Ah, I forgot pro/epilogue generation, but I think that's the only other
thing that happens after reload.  That is a special case: it has to generate
strict rtl that directly matches the insns it wants.  You'll probably have to
arrange for it to save at least one GPR early enough in the prologue sequence
to be able to use it as a temp for your FP moves, and similar in the epilogue
sequence.

    cheers,
      DaveK

Re: a peculiar fpload problem on an inferior processor

[Amker.Cheng]

>  Ah, I forgot pro/epilogue generation, but I think that's the only other
> thing that happens after reload.  That is a special case: it has to generate
> strict rtl that directly matches the insns it wants.  You'll probably have to
> arrange for it to save at least one GPR early enough in the prologue sequence
> to be able to use it as a temp for your FP moves, and similar in the epilogue
> sequence.

Yes, Thanks for your help , Dave



-- 
Best Regards.

Re: a peculiar fpload problem on an inferior processor

[Amker.Cheng]

On Sat, May 8, 2010 at 2:52 PM, Amker.Cheng <amker.cheng@gmail.com> wrote:
>>  Ah, I forgot pro/epilogue generation, but I think that's the only other
>> thing that happens after reload.  That is a special case: it has to generate
>> strict rtl that directly matches the insns it wants.  You'll probably have to
>> arrange for it to save at least one GPR early enough in the prologue sequence
>> to be able to use it as a temp for your FP moves, and similar in the epilogue
>> sequence.
>

Sorry to disturb again, concerning this problem, There is another case
have to be handled.
the reload pass also takes care of call saved registers by generating
save/restore insns,
which might generate direct fpload/fpstore instructions. (in
save_call_clobbered_regs, etc.)

I see no way to keep GPR for this case, except using the temporary
register of the ABI,
and it seems safe in this case since the temp register are only used
around calling insn.
Actually I am not very sure about this.

Any suggestion? Thanks.

-- 
Best Regards.