Re: C code .vs. Assembly code for Microcontrollers/DSPs ?

cliffc@ami.sps.mot.com (Cliff Click)
21 Mar 1996 23:54:24 -0500

          From comp.compilers

Related articles
[34 earlier articles]
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? john.gilliver@gecm.com (1996-03-20)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? leichter@smarts.com (Jerry Leichter) (1996-03-21)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? stefan.monnier@lia.di.epfl.ch (Stefan Monnier) (1996-03-21)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? cdg@nullstone.com (1996-03-21)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? pdonovan@netcom.com (1996-03-21)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? fjh@cs.mu.OZ.AU (1996-03-21)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? cliffc@ami.sps.mot.com (1996-03-21)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? schwarz@mips.complang.tuwien.ac.at (1996-03-22)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? jfc@mit.edu (1996-03-22)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? chuck@aage.mit.edu (1996-03-22)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? preston@tera.com (1996-03-22)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? bobduff@world.std.com (1996-03-22)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? torbenm@diku.dk (1996-03-25)
[9 later articles]
| List of all articles for this month |

From: cliffc@ami.sps.mot.com (Cliff Click)
Newsgroups: comp.arch,comp.compilers
Date: 21 Mar 1996 23:54:24 -0500
Organization: none
References: 96-03-006 96-03-091 96-03-110
Keywords: optimize



Scott A. Berg <sberg@camtronics.com> wrote:
] 1 - Lousy C code can fool a compiler into thinking no optimization is
] possible. There is only so much "smarts" possible with compilers.
] For example, common sub-expression extraction can be fooled by using
] parentheses "for clarity" but which fool the parse tree into thinking
] two equivalent expressions are different.


Stefan Monnier <stefan.monnier@lia.di.epfl.ch> writes:
> It is possible to reorganize the parse tree into a "canonical
> representation". Of course, if the parenthesizing makes the two trees
> different enough the compiler might not notice the equivalence. But if
> you're able to notice the equivalence and factor it out manually (in C
> or assembly) it's probably not harder and not less readable to put the
> parentheses in such a way that it's obvious to the compiler that the
> two expressions are the same.


I think most CSE passes use an internal 3-address notation; parse
trees are not used precisely because they obfuscate CSE's.




> On another hand, the problem of alias-analysis which might fool the
> compiler into thinking that 2 expressions are not equivalent because
> some assignment inbetween might change the result is more
> difficult. In such cases manual CSE might be useful.


Yes. Alias analysis is improving, but by no means is it reliable
(meaning the compiler will miss lots of stuff that's obvious to the
programmer).




[...lots of good stuff removed...]
> in other words, even the programmer that wants his code to go fast
> should concentrate on the readability of his code more than on using
> tricks like '+='.


Yes. Readable code is much easier to do performance analysis on,
which can lead to algorithmic changes for big-O speedups (to say
nothing of what the programmer that follows you thinks of your code).




> Stefan


Cliff
--
Cliff Click, Ph.D. Compiler Researcher & Designer
RISC Software, Motorola PowerPC Compilers
cliffc@risc.sps.mot.com (512) 891-7240
http://members.aol.com/mjclick1


--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.