On Mon, Jan 30, 2017 at 6:34 AM mats petersson via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> On 30 January 2017 at 10:37, Siddharth Shankar Swain via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> When to JIT from AST and when to JIT from LLVM IR? What is the logic
> behind extreme laziness? In what situations can it be beneficial and in
> what it is not? Does it depends on target architecture?
>
>
> I've quite possibly misunderstodd the question, but as far as I know,
you
> have to generate IR to use LLVM's JIT functionality.
>
I think Siddharth is asking about when to defer IR generation and when not
to.
The Kaleidoscope ORC JIT examples demonstrate the possibility of deferring
IR generation until the moment that function is needed - rather than
generating all the IR up front for a given script/source file/etc.
So the question is what tradeoffs might there be in taking advantage of
that flexibility/possibility.
Really hard to say - as with many optimization problems - there could be
cache effects that mean visiting all the AST and generating all the IR up
front is better than generating fragments of IR from AST on an as-needed
basis.
Chances are, in the end, I expect the 'right' answer is going to be a
chunking conversion - where it's not one function at a time and not whole,
large programs in one go, but a good "chunk" of the program to
minimize the
constant overheads of building a new module, walking your AST, etc.
>
> Since this is probably an "XY question", it would help if you
explain what
> you actually want to do.
>
> --
> Mats
>
>
> Siddharth
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170130/cc777e63/attachment.html>