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]

Re: MODES_TIEABLE_P yes or no


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 */


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