Re: [Lightning] Re: Stack register control?

[Sandro Magi]

On 9/30/07, Eli Barzilay <address@hidden> wrote:
>
> > Not really, feel free to keep this on list.
>
> Well, there wasn't really anything that would surprise...  Comparing
> lightning and llvm is like comparing a tool that does a basic job like
> ed to something that throws the kitchen sink in like Emacs.  Sandro
> asked if we tried to compare speeds -- we didn't, but I suspect that
> this comparison depends heavily on the level of optimization that we
> do, if any.  Our hope with the llvm experiment was to benefit from
> some of its advanced optimization -- like good inlining and register
> allocation,

Right, I was wondering what sorts of optimizations are needed before
the quality of generated machine code with Lightning approached say,
90% of LLVM's speed, and whether investing the time to do these
optimizations myself was worth the tradeoff in avoiding LLVM.

The Lightning manual mentions peephole optimizations, and obviously
register allocation is significant. Are there any other optimizations
of note? I'm not as familiar with low-level optimizations as I am at
high-level program transformations, so any pointers are much
appreciated.

Code generation speed was also discussed, but no hard numbers on that;
I think it's obvious that Lightning has the pure speed advantage, but
I'm not sure what the margin is.

> In any case, the big advantage of LLVM is, of course, also its big
> disadvantage -- incorporating LLVM to an existing project requires
> much more work (probably on the same scale as embedding gcc)

All reports I've read indicate LLVM is much easier than gcc, but that
isn't necessarily saying much given the herculean effort that
involves. :-)

> than Lightning.  File sizes were also a problem -- the size is usually not
> an issue when you have a 1mb library, but with an executable size of
> 1.8mb it does become a point of consideration.

I'm curious, what's the Lightning code generator size for your 1.8MB
executable? As I mentioned before, code generator size has a
significant impact on performance due to cache residency; if your
whole code generator can fit in cache, code generation speed would be
incredible, which is quite important to multi-staged languages for
example.

The only other point discussed was that Lightning provides more
low-level control over resources than LLVM does, which is what I need;
I wasn't quite sure how to accomplish some of the same in LLVM, but I
eventually managed to formulate the right question and got a
satisfactory answer from the LLVM list [1].

Sandro

[1] http://lists.cs.uiuc.edu/pipermail/llvmdev/2007-September/010934.html