[cairo] JIT for pixman

[keita abdoul-kaker]

i also think that LLVM is the way to go.From what i have seen, the
major shortcoming with the others attempt was the lack of optimization
of the outputted code , and with LLVM we have that for free.
But do we really need  a JIT ? i think that for  a first attempt a
clever static compilation can be good enough. JIT only make sense when
the execution environment change a lot or evolve somewhat ,but i don't
think that's the case.Given the platform and the supported image
format ,what new information the execution context bring ? and even if
there are new information can we use that to do any optimization ?
So what i propose for a start would be to statically compile all the
given operation for the (arch,supported images formats) combinaison.
First we use LLVM compiler  to compile the section of the code we
judge necessary, we may have to write our own parser to recognize non
standard C syntax (the new syntax is use to me more imperative and
give more freedom to optimization passes), then we write an
optimization pass that work on the IR produce and do some *magic*,
then translate back the IR to C code.
The resulting C code is merge back to original code base, and the
whole code is compile using  gcc.
Why output C code with LLVM ? First gcc have much more aggressive
optimization pass than LLVM and it also  support more backend. Plus
that approach allow to concentrate only on how to express what we want
to do in a ew syntax and how to find the best way to do what we want
to do given a context ( architechture,operation,output&input image
formats)



On Thu, Jan 8, 2009 at 1:44 PM, Behdad Esfahbod <behdad at behdad.org> wrote:
> Dan Amelang wrote:
>> On Thu, Jan 8, 2009 at 12:48 PM, Behdad Esfahbod <behdad at behdad.org> wrote:
>>> Dan Amelang wrote:
>>>> FWIW, if I were to start over on jitblt, with the goal of producing
>>>> "real world" software, I would base it on LLVM and work on
>>>> fixing/hacking around the above issues. My intuition is that
>>>> fixing/hacking around those issues is less work and a better approach
>>>> for the long-term than the other options.
>>> But linking cairo to LLVM is not something many people will be fond of.
>>
>> They will be if their concerns are met.
>
> Ideally the generated code should be cached on disk and mmapped by all
> processes.  At that point, a heavier framework may be less of a concern.
>
>> Dan
>
> _______________________________________________
> cairo mailing list
> cairo at cairographics.org
> http://lists.cairographics.org/mailman/listinfo/cairo
>