llvm dev - Jun 2008 - [LLVMdev] jit DLLs

> ?yvind Harboe wrote:
>> Are JIT DLLs supported?
>>
>> The idea is to use llvm to put performance sensitive code into
>> a DLL that a Windows app can then use.
>>
>> This would build the performance sensitive code on the target
>> machine making it possible to exploit CPU specific x86
>> vector instructions.
>>
>> The code that calls fn's in the DLL should, ideally, be unaware
>> that a llvm JIT is being used.
>
> because of the size of the LLVM libraries, it would usually be preferable
to pre-build versions of the performance
> sensitive code for all target CPUs in separate dlls and use CPU
identification code (similar to what the LLVM JIT does)
> to resolve which dll to load at run time.
Actually size doesn't matter. What's 10-20mByte amongst friends these
days? :-)

What's the compressed size? (Decompressed *really* does not matter
on a PC these days...)

What matters is that the binaries can be shipped
as part of the installation and live side by side by other installations and
that the solution is as complete as possible so as for me to be able
to hit the ground running.


-- 
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 XScale Cortex
JTAG debugger and flash programmer

On Jun 24, 2008, at 12:46 PM, Øyvind Harboe wrote:
>> ?yvind Harboe wrote:
>>> Are JIT DLLs supported?
>>>
>>> The idea is to use llvm to put performance sensitive code into
>>> a DLL that a Windows app can then use.
>>>
>>> This would build the performance sensitive code on the target
>>> machine making it possible to exploit CPU specific x86
>>> vector instructions.
>>>
>>> The code that calls fn's in the DLL should, ideally, be unaware
>>> that a llvm JIT is being used.
>>
>> because of the size of the LLVM libraries, it would usually be  
>> preferable to pre-build versions of the performance
>> sensitive code for all target CPUs in separate dlls and use CPU  
>> identification code (similar to what the LLVM JIT does)
>> to resolve which dll to load at run time.
>
> Actually size doesn't matter. What's 10-20mByte amongst friends  
> these days? :-)
>
> What's the compressed size? (Decompressed *really* does not matter
> on a PC these days...)
>
> What matters is that the binaries can be shipped
> as part of the installation and live side by side by other  
> installations and
> that the solution is as complete as possible so as for me to be able
> to hit the ground running.
For the JIT and a couple of optimizers on x86 (suitably stripped etc),  
we see it taking ~2M uncompressed.  Additionally, as you say, this is  
very compressible for an install image.

-Chris