This is the mail archive of the gcc@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]

MODES_TIEABLE_P yes or no


MODES_TIEABLE_P for the AVR port is set zero. 

Indeed looking at the definition:

"If HARD_REGNO_MODE_OK (r, mode1) and HARD_REGNO_MODE_OK (r, mode2) are always the same for any r, then MODES_TIEABLE_P (mode1, mode2) should be nonzero."

this would be correct.

However, I think the definition might be  misleading.

The AVR only has h/w byte QI registers. Other sizes are formed by concatenation (e.g. r4(SI) is r4+r5+r6+r7). Everything including Stack and Frame Pointers is byte accessible. 

HARD_REGNO_MODE_OK (r, mode1) does differ as HImode registers (and larger) must be aligned on even register numbers.

This alignment does not prevent a register being accessed in any equally sized or smaller mode. (which I believe is the true definition)

I dont believe a paradoxical subreg type situation would ever be presented to final code generation (if it were it would be relatively easy to handle). Similary, I dont believe gcc would try to take un-aligned access (say the two middle bytes out of a SImode register).

So given that all possible accesses will either not happen or be valid, I think MODES_TIEABLE_P should be safely NONZERO for optimal code and the definition clarified accordingly.

On the otherhand I could be wrong?



__________________________________________________________________
Switch to Netscape Internet Service.
As low as $9.95 a month -- Sign up today at http://isp.netscape.com/register

Netscape. Just the Net You Need.

New! Netscape Toolbar for Internet Explorer
Search from anywhere on the Web and block those annoying pop-ups.
Download now at http://channels.netscape.com/ns/search/install.jsp


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