MODES_TIEABLE_P yes or no

[Andy Hutchinson]

Thanks for input.

Yes I too see significant improvments in code size.

I haven't managed to break it yet. I did manage to create paradoxical 
subreg - probabley because I was doing things the wrong way in other areas.

Anyway the effect on the back end was to ask for a word mov from an odd 
register. Solution is simply to narrow the move. e.g.

movw r25,r22 => mov r25,r22.

Because the "upper byte" is a dont care.

something like:
          /*check for paradoxical move - AWH*/
          if (avr_hard_regno_mode_ok(true_regnum(src),HImode))
            return (AS2 (movw,%0,%1));
          else
            return (AS2 (mov,%0,%1)";paradox");

So dealing with paradoxical subreg is easy. If they can occur!

Like I said - I got them  because I was probably doing things the wrong 
way - I have not seen it pop up for a while - I added big 
fprintf(stderr, to keep an eye on it.


Thanks again.


bjoern.m.haase@web.de wrote:
> Hi,
> 
> thank you for having a look at these aspects of the AVR back-end! If I 
> understand the meaning of MODES_TIEABLE_P correctly, I agree with you. I have 
> also done a preliminary test of your suggestion and found out that with your 
> suggested change the code is *much* more efficient for all cases I have 
> looked at so far.
> 
> Concerning the AVR convention for mode alignment:
> IIUC, the *only* reason for aligning all modes of size HI and upward is, that 
> this way it is easier to make use of the move-word (movw) instruction. This 
> instruction can move 2 bytes simultaneously, given that the first register 
> has an even number. By forcing all "larger" modes to start in even registers, 
> there is no need to check whether a variable of this mode starts in an even 
> register. Otherwise it would be cumbersome for the back-end implementation.
> I, therefore, do not expect any problem concerning alignment, when changing 
> the definition of MODES_TIEABLE_P.
> 
> The main question in my opinion is, whether it may happen that paradoxial 
> subreg expressions show up. IIUC, when trying to perform a SI operation on a 
> HI register, gcc allways generates appropriate SIGN_EXTEND or ZERO_EXTEND 
> patterns. If this is allways true, I do not expect any problem. However, in 
> order to get a really reliable answer, one probably would need to ask Marek 
> Michalkiewicz or Denis Chertykov.
> 
> I have done a couple of course tests concerning your suggestion:
> Indeed, when changing the macro definition, gcc generates considerably better 
> code! I have compiled the following example with a gcc-4.0.0 snapshot dating 
> from 12/12/2004 (head presently is broken again) after using of a patch 
> concerning the reload problem. Indeed the four superfluous mov instructions 
> have vanished.
> 
> Yours, 
> 
> Björn
> 
> /// Sample program
> #include <inttypes.h>
> int8_t 
> foo  (int16_t a, int32_t b)
> { int8_t c;
>   c = a - b;
>   if (c)
>    { return 1;
>    }
>   else
>   { return 2;
>   }
> }
> 
> Compilation result with MODES_TIEABLE_P  defined to be 0
> foo:
> /* prologue: frame size=0 */
> /* prologue end (size=0) */
>      ;  basic block 0
>     mov r18,r20
>     mov r19,r21
>     mov r20,r22
>     mov r21,r23
>     cp r24,r18
>     breq .L2
>      ;  basic block 1
>     ldi r24,lo8(1)
>     ldi r25,hi8(1)
>     ret
> .L2:
>      ;  basic block 2
>     ldi r24,lo8(2)
>     ldi r25,hi8(2)
>     ret
> /* epilogue: frame size=0 */
> 
> 
> Compilation result with MODES_TIEABLE_P  defined to be 1
> foo:
> /* prologue: frame size=0 */
> /* prologue end (size=0) */
>      ;  basic block 0
>     cp r24,r20
>     breq .L2
>      ;  basic block 1
>     ldi r24,lo8(1)
>     ldi r25,hi8(1)
>     ret
> .L2:
>      ;  basic block 2
>     ldi r24,lo8(2)
>     ldi r25,hi8(2)
>     ret
> /* epilogue: frame size=0 */