Re: A question about HARD_REGNO_MODE_OK and MODES_TIEABLE_P

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

 



Anthony Brandon <anthony.brandon@xxxxxxxxx> writes:

> I have a question about the usage of HARD_REGNO_MODE_OK and
> MODES_TIEABLE_P in gcc.
> The processor we are adding the target for has basically two types of registers:
> some 32 bit general registers, and some 1 bit branch registers.
> The 32 bit registers are always written as 32 bit values,
> So if you do a load byte from memory, the byte is either sign, or zero
> extended and written to the register.
> The same is true when doing a move from a branch register to a general
> register. (in that case the bit is zero extended to the full 32 bits).
> So there is no way to write an 8 bit value without overwriting the
> other bits (or 16 bits, or 1 bit for that matter).
> However there are some instructions that can read these registers as
> either 1, 8, or 16 bit values.
>
> So my question is should i set hard_regno_mode_ok to 0 for all modes
> except for the SI mode?
> and then have modes_tieable_p return 1 for (SI,WI) (SI,QI), (SI,BI).
> Or do I misunderstand the usage of these macros?

Since your processor has a load-byte instruction, and presumably also a
store-byte instruction, you should set HARD_REGNO_MODE_OK to any mode
which fits in a register.  The fact that the value is automatically
sign- or zero-extended when stored in a register does not mean that the
register does not hold the value.  The case when the register does not
hold the mode is when you can not move it in and out of register.  For
example, on some processors the floating point registers can only hold
floating point values; HARD_REGNO_MODE_OK would be used to prevent
storing an integer value in such a register.


> Also in this case do I still need to define the movqi and movhi patterns?
> Because there are no instructions that can write to registers in these modes.
> (other than store instructions, but those write to memory, not registers)
> Basically this is the real problem, currently the movqi and movhi
> patterns map to the same one as the movsi.

Presumably movqi and movhi do not generate the same instruction when
loading from or storing to memory.


> However this seems to cause very strange code to be generated where
> gcc inserts sign extension operations even though they aren't needed.

You may need to define PROMOTE_MODE.

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