Re: Code folding from JSR/RTS -> {Local}

byron@archone.tamu.edu (Byron Rakitzis)
2 May 91 16:35:56 GMT

          From comp.compilers

Related articles
Code folding from JSR/RTS -> {Local} carter@cs.wisc.edu (1991-05-01)
Re: Code folding from JSR/RTS -> {Local} byron@archone.tamu.edu (1991-05-02)
Re: Code folding from JSR/RTS -> {Local} pardo@june.cs.washington.edu (1991-05-02)
Re: Code folding from JSR/RTS -> {Local} preston@ariel.rice.edu (1991-05-03)
Re: Code folding from JSR/RTS -> {Local} deutsch@lix.polytechnique.fr (1991-05-13)
| List of all articles for this month |
Newsgroups: comp.compilers
From: byron@archone.tamu.edu (Byron Rakitzis)
Keywords: optimize, architecture
Organization: College of Architecture, Texas A&M University.
References: <9104262025.AA21840@enuxva.eas.asu.edu> <7524@ecs.soton.ac.uk> <1991May1.035622.25021@daffy.cs.wisc.edu>
Date: 2 May 91 16:35:56 GMT

In article <1991May1.035622.25021@daffy.cs.wisc.edu> carter@cs.wisc.edu (Gregory Carter) writes:
>I don't know if this is incredibly obvious or what, but in the OLDEN DAYS
>when I was working on a 6502 machine. Speed was of the upmost...ad nauseum..


Hmm... are we seeing an "all the world's a 6502" attitude in this article?
(although, I admit that my subsequent comments assume "all the world's a
machine with slow memory and fast registers (e.g., most RISC architectures)")


>What I want to know, if any of you have considered, for high speed
>applications to get that extra push, what the problems would be in compiler
>design to:


>1) Transcribe all local variables to global ones.


Ouch. This will kill register allocation on most compilers. You WANT your
code in blocks with local declarations of variables; this gives an
optimizing compiler a better chance at allocating registers over variable
lifetimes. However, even the simplest optimizations can be killed by
making your variables global; compilers like gcc usually make pessimal
assumptions about how global variables are used:


        x = 1; /* assume x is global. gcc writes x to memory */
        foo();
        bar(x); /*gcc will reload x from memory, even if foo() does not touch */
/* x or the register that x was stored in */
/* (i.e., there's no interprocedural optimization on globals) */


>2) Replacing subroutine calls with the actual code.


This is already done.


>3) minimizing stack frame usage to almost ZIPPO.


If you have a good compiler on a RISC archictecture, then you probably
touch the stack frame as little as possible ANYWAY. Even return addresses
are not stored on the stack in leaf subroutines on the MIPS, for example.
(or rather, they shouldn't be!)


Sorry to pick nits. Now, to address the ideas in your article: yes, it's
clear that it should be possible for you to configure your compiler to
trade space for time. Most of the optimizations you suggest are more
readily accomplished by good interprocedural optimization, though.


--
Byron Rakitzis, Texas A&M., byron@archone.tamu.edu
--


Post a followup to this message

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