> The truth you're saying.... > > some func. attributes will partly solve your problem. > > Also, if you see some stupidity in a code, just send me sources. > I'll see waht I can do.
Here's a small C file that generates a pair of instructions
111 000c 5FF3 and.b #llo(1), r15
112 000e 7FF3 and.b #-1,r15
The second and is, as far as I can see, completly redundant. It would be
nice if the compiler could automatically change the case constants so that
it did not need to do the rotate, but I suspect that's asking a bit too much
in the general case!
I'll try to make another simple test for the redundant register moves I
mentioned below.
The compiler flags I used were :
msp430-gcc -mmcu=msp430x149 -c -g -O2 -Wa,-ahld=test.lst test.c
>
> ~d
>
> P.S. I'll think about jump instad of call at the func. tail, but cannot
> imagine how right away.
>
There is a gcc flag "-foptomise-sibling-calls" (if I've got the spelling
right...), which I suppose should do something like this but does not seem
to have any effect. This optomisation would be useful when you have many
small functions, and can also reduce the stack space used.
mvh.
David
>
> On Friday 06 December 2002 23:16, David Brown wrote:
> > Hi Dmitry,
> >
> > I hope this is of interest to you. I know I have the source, and could
> > fiddle things myself, but this is way beyond my knowledge.
> >
> > I've been playing about with bitfields, and looking at the code
generated
> > by gcc for various manipulations. Normally I tend to use chars to hold
> > flag registers and #defines to specify different flags, but I thought I
> > might try bitfields since I now have a good debugger that can display
them
> > properly. There are a couple of places where I have spotted sub-optimal
> > code, even with -O2 or -O3 with plenty of flags. I doubt if there is
any
> > point in making an effort to optomise these particular points - after
all,
> > they are purely artificial test cases, which are unlikely to be the same
in
> > real code. But it may be that you can generalise from them.
> >
> > I have a bitfield structure defined:
> >
> > typedef struct { unsigned char a : 1; unsigned char b : 1; } t;
> > t Test(t x) {
> > x.a = x.b;
> > return x;
> > }
> >
> > The code generated is:
> > mov.b r15, r14
> > clrc
> > rrc.b r14
> > and.b #llo(1), r14
> > bic.b #llo(1), r15
> > bis.b r15, r14
> > mov.b r14, r15
> > ret
> >
> > As far as I can see, the final mov should be removed, and the bis.b
should
> > be "bis.b r14, r15". I think the clrc could also be eliminated.
> >
> > I have noticed on several occasions a tendancy to over-use r15. For
> > example, in a switch statement I have seen the switch variable
calculated
> > in another register (such as r14), which is then mov'ed into r15 before
> > doing the compares.
> >
> > Finally, doing a switch on bitfields generates a lot of extra code, some
of
> > which should definitely have been removed by the peephole optomisers:
> >
> > switch(y.b) { ... // y is in r11 here
> > mov.b r11, r13
> > clrc
> > rrcb r13
> > mov.b r13, r15 // All this could have been mov.b r11,
r15;
> > rrcb r15
> > and.b #llo(1), r15
> > and.b #-1, r15 // ???
> > cmp #llo(0), r15, etc.
> >
> >
> >
> > Also, is there any way to optomise tail calls (if that is the right
word) ?
> > I am thinking of a function that ends with a call to another function,
> > where the "call #...; ret" pair is replaced with a "jmp ..."
instruction.
> >
> >
> > I always like to examine generated assembly, and look for ideas to
improve
> > the generated code. I must say it has been extremly difficult to find
such
> > cases with msp430-gcc !
> >
> > mvh.
> >
> > David
> >
> >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Mspgcc-users mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>
> --
> *********************************************************************
> ("`-''-/").___..--''"`-._ (\ Dimmy the Wild UA1ACZ
> `6_ 6 ) `-. ( ).`-.__.`) Enterprise Information Sys
> (_Y_.)' ._ ) `._ `. ``-..-' Nevsky prospekt, 20 / 44
> _..`--'_..-_/ /--'_.' ,' Saint Petersburg, Russia
> (il),-'' (li),' ((!.-' +7 (812) 314-8860, 5585314
> *********************************************************************
>
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Mspgcc-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>
>
test.c
Description: Binary data
test.lst
Description: Binary data
