On 04/14/2011 05:55 PM, Hagen Paul Pfeifer wrote:

On Thu, 14 Apr 2011 17:40:03 +0300, Avi Kivity[off-list ref]  wrote:

quoted

 Have you considered putting the compiler in userspace?

Kernelspace (modules, threads, etc) can register BPF filters too. It is
possible that there is no userspace involved at all.

A userspace jit would still work just fine, no?  I don't want the user 
who supplied the program to also supply the jit; rather, when the kernel 
installs the bpf program, it also asks an independent userspace compiler 
to translate it.

quoted

 The upside is that you can use established optimizing compilers like
 LLVM or GCC, which already support more target architectures.  It may
 not matter much for something simple like bpf, but other VMs may be a
 lot more complicated.

BPF is another domain. Standard compiler optimization are not comparable
to BPF optimizations so there is no gain there. Maybe writing a gcc front
_and_ back-end may gain some valuable advantages.

I'm talking about optimizing the generated code.  For example, bpf has 
just two registers so a complex program generates a lot of loads and 
stores.  An optimizing compiler can use extra target registers to avoid 
those spills, and doesn't need to keep A and X in fixed registers.

If you translate the bpf program to C and optimize that with gcc you'll 
probably get much better machine code that the jit in the patch.

-- 
error compiling committee.c: too many arguments to function