Re: reload in incompatible constraints

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Thanks for your help.

I'm trying to implement TARGET_SECONDARY_RELOAD but I cannot make it
work properly.
The hook seems to work for preventing from moving from BASE_REG to
BASE_REG in HImode by inserting a GENERAL_REG.
But I also want to insert a GENERAL_REGS intermediate register when
moving between BASE_REGS registers and memory in HImode.

So I wrote something like that in my TARGET_SECONDARY_RELOAD:
if (MEM_P(x) && (reload_mode == HImode) && reload_class == BASE_REGS)
     return GENERAL_REGS;


But it seems this do not work. For instance with DI function parameter
access (movdi reg:DI <-- m) which are (automatically) split into movhi
subreg:HI <-- m; then in movhi reg:HI <- m. But the hook do not seem
to work since the reg:HI is reloaded into a BASE_REG...

So when is this hook called? Is there something specific with spliting
insn? Or just a general thing about TARGET_SECONDARY_RELOAD I missed ?

Aurélien







2011/6/23 Ian Lance Taylor <iant@xxxxxxxxxx>:
> Aurelien Buhrig <aurelien.buhrig.gcc@xxxxxxxxx> writes:
>
>> My main problem is when defining a *movhi insn whose
>> constraints/predicates only support r registers, GCC may reload some r
>> register into A subreg:HI register, and complains because the insn
>> *movhi does not satisfy its constraints (r). How to prevent this ?
>
> I assume that the register can in principle hold the value, so changing
> HARD_REGNO_MODE_OK would not be appropriate.  What you want here is
> REGISTER_MOVE_COST.  However, gcc will try to use all available
> registers in some cases, so if you can't move values between the
> register classes easily you will need to define TARGET_SECONDARY_RELOAD.
>
>
>> BTW, to handle movhi from subreg:HI A to subreg:HI A, which is not
>> supported by the target: should I define a define_expand movhi whose
>> predicates supports such an operation, and then, provide a
>> define_split to froce passing through a r reg ? Is there a more
>> efficient way to do this ?
>
> This is what TARGET_SECONDARY_RELOAD is for.
>
> Ian
>



[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux