llvm dev - Jun 2009 - [LLVMdev] Using LLVM on an embedded device

Hi Evan,

Sorry for the delayed reply. We've compiled llvm on Linux with only the x86
target, which produced an lli executable that's about 5.5MB. The
LLVMX86CodeGen.o alone is 1.7MB. We've configured with

--disable-assertions --enable-optimized --enable-targets=x86
--disable-debug-runtime --enable-bindings=none --disable-ltdl-install
--disable-shared --enable-static

Are there any tips on making them even smaller? It seems that the ARM backend
would be smaller but I am not sure if we could get it under 2MB. Also I guess,
the interpreter could be removed, but it is quite small (145KB).

Thank you,
Anna.
 
> Hi,
>
> I am researching a possibility of running LLVM components (such as  
> JIT) on an embedded device, where the memory footprint and RAM usage  
> are the main concerns. So I was wondering if anyone could share  
> their experience with running LLVM on an embedded device. What is  
> the approximate code footprint that we are looking at? For example,  
> on an x86 with a minimum set of optimizations and with only the x86  
> backend, it seems difficult to get the LLVM JIT occupy less than  
> 5MB. Is there any performance and memory usage data available?
That seems too high. I would think it's more in the 2MB range. How did  
you come about that figure? x86 instruction selector itself is quite  
large due to the complex selection patterns. I would expect ARM's  
footprint to be smaller.

There are ways to reduce memory foot print further. But it will  
require someone to drive the effort. One of the (very rough) idea is  
to switch to a table driven instruction selector.

Evan
>
> Thank you!
> Anna.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20090626/10cf7d68/attachment.html>

On Jun 26, 2009, at 3:11 PM, Anna Zaks wrote:
> Hi Evan,
>
> Sorry for the delayed reply. We've compiled llvm on Linux with only  
> the x86 target, which produced an lli executable that's about 5.5MB.  
> The LLVMX86CodeGen.o alone is 1.7MB. We've configured with
>
> --disable-assertions --enable-optimized --enable-targets=x86 -- 
> disable-debug-runtime --enable-bindings=none --disable-ltdl-install  
> --disable-shared --enable-static
>
> Are there any tips on making them even smaller? It seems that the  
> ARM backend would be smaller but I am not sure if we could get it  
> under 2MB. Also I guess, the interpreter could be removed, but it is  
> quite small (145KB).
>
Size of lli is a poor indicator for dynamic memory footprint. You  
really have to measure in a JIT environment. That said, there are  
definitely possibilities for reducing the size. But I don't think  
there is anyone actively working on it.

Evan
>
> Thank you,
> Anna.
>
>
> > Hi,
> >
> > I am researching a possibility of running LLVM components (such as
> > JIT) on an embedded device, where the memory footprint and RAM usage
> > are the main concerns. So I was wondering if anyone could share
> > their experience with running LLVM on an embedded device. What is
> > the approximate code footprint that we are looking at? For example,
> > on an x86 with a minimum set of optimizations and with only the x86
> > backend, it seems difficult to get the LLVM JIT occupy less than
> > 5MB. Is there any performance and memory usage data available?
>
> That seems too high. I would think it's more in the 2MB range. How did
> you come about that figure? x86 instruction selector itself is quite
> large due to the complex selection patterns. I would expect ARM's
> footprint to be smaller.
>
> There are ways to reduce memory foot print further. But it will
> require someone to drive the effort. One of the (very rough) idea is
> to switch to a table driven instruction selector.
>
> Evan
>
> >
> > Thank you!
> > Anna.
> >
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20090629/82b284a5/attachment.html>