Message: 3
Date: Mon, 06 Dec 2010 14:11:07 +0100
From: Maurizio De Cecco <jmax(a)dececco.name>
Subject: Re: [LAD] Project proposition: llvm based dsp engine
To: Paul Davis <paul(a)linuxaudiosystems.com>
Cc: The Linux Audio Developers' Mailing List
<linux-audio-dev(a)lists.linuxaudio.org>rg>, llvmdev(a)cs.uiuc.edu
Message-ID: <1291641067-065c11f3c738513db43420e758ad7e5d(a)dececco.name>
Content-Type: text/plain; charset="iso-8859-1"
Hi, and thanks for the feedback.
My own gut feeling on this is that you'd be
better off figuring out
how to do this in the context of Faust, which already does a important
subset of what you are describing, though notably without (I think)
the LLVM part.
Surely a contribution to the discussion by the Faust people would
be welcome; and even more than to the discussion :->. By the way, they
do something with LLVM, but i do not know exactly what (Faust is included
in the list of projects using LLVM).
I think the interest, if any, would be in having a *low* level
library generic enough to be used by multiple applications, so
to factor the work. It may be that an existing project have internally
a large part of the needed code, though.
Note also that hosts which run plugins at the
level of LADSPA/LV2,
VST, AU, DSSI etc are unlikely to be easy candidates for any
cross-plugin optimization.
I was actually talking about two different context, reusing existing
binaries, and having cross plugin optimisations for native plugins.
But, if the plugins are compiled with a different compilation chain
(using the LLVM compiler producing LLVM byte code, so introducing a different
binary format for them), than cross plugin optimisation is possible also for
existing plugins like a LADSPA plugin.
Would that be worthwhile ? Difficult to know for sure, but it is an interesting
subject to explore.
Maurizio
I'm quite dubious of any real optimization you would achieve with this kind of
approach, using LLVM. AFAIKS LLVM link time optimization allows some kind of inter module
inlining or possibly constant propagation (see
) but I am not sure it would help a lot in
our domain.
Again staying in the imperative world makes things much more complicated... go
functional!
Stéphane
PS: BTW LLVM is a really nice tool and very interesting things can be done with it, like
using LLVM bitcode format as an interchange format for different architectures and using
the JIT for dynamic compilation. We can already do that with Faust LLVM backend where we
can generate a bitcode binary, then load it and JIT with a generic "LLVM faust
plug-in" loader. This would allow the same bitcode object to be produced by the Faust
online compiler for instance and be executed on any target machine.