gnupic: Re: [gnupic] Linker Optimizations
Subject:
Re: [gnupic] Linker Optimizations
From:
"David Barnett" ####@####.####
Date:
5 Mar 2007 18:26:34 +0000
Message-Id: <0bde01c75f53$64887fe0$2001a8c0@barnett2>
----- Original Message -----
From: "Scott Dattalo" ####@####.####
To: ####@####.####
Sent: Monday, March 05, 2007 11:45 AM
Subject: Re: [gnupic] Linker Optimizations
> David Barnett wrote:
>> I'm not quite sure what constitutes pCode, though.
<snip>
> A few other features of the pCode are tail optimizations, live range
> analysis, and call tree analysis. These features don't make much sense
> living in the compiler. It's best to apply these optimizations in the
> linker. Take the call tree analysis. If the linker performs a call tree
> analysis and determine that certain functions are never called - then no
> code needs to be generated for them. Or if it determines that a certain
> function is only called once, then that function can be inlined. What's
> really cool is that after inlining you can run the code through the pCode
> optimizer again. This subsequent pass may end up removing things like
> parameter passing.
Just these optimizations would be worth all the effort. I'm used to working
with an 8-level stack and I've had to explicitly inline all kinds of
single-call functions just so that I could modularize the code. This
approach led to strange header file dependencies since the body has to be
defined at each inline declaration, which in turn led to some severe
headaches.
<snip>
> If we were to move pCode into gplink, then this is probably the high level
> approach that should be taken.
>
> - define a set of assembler directives that can control the linker.
> For example, we'd need to tell the linker things like 'the follow block is
> really data table and not instructions' or 'the following code has been
> hand crafted to run at a very specific rate and should not be optimized'
> or etc...
Good point. I think we'll also want to make sure that most of the
optimization needs to be explicitly enabled for backwards-compatibility.
<snip>
> It's going to take several man-months to accomplish these high level
> tasks.
Sounds fun =). If those function optimizations will work, it'll solve a lot
of problems for me, so I'll definitely keep it in mind to hack at when I get
some free time.
David
