Are MODES_TIEABLE registers incorrectly defined and incorrect set on AVR target?

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

 



MODES_TIEABLE_P for the AVR port is set zero. I Believe this is incorrect and results in sub-optimal code.

What follows is my logic. Can anybody please comment disagree or agree ?


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."

MODES_TIEABLE_P= 0  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 for MODES_TIEABLE_P)


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?





[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