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.
~d
P.S. I'll think about jump instad of call at the func. tail, but cannot
imagine how right away.
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
> Mspgcc-users@lists.sourceforge.net
> 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
*********************************************************************
