[llvm-dev] LLVM Developers Meeting JIT BoF -- Request for Topics of Interest

[Lang Hames via llvm-dev]

Hi Andres,

That would be of interest to me too. One thing around this I have been
> wondering about is whether it's realistic to merge the optimization and
> code generation phases - right now we spend a lot of time re-doing
> analyses during codegen that we already had done during optimization.


Sounds good to me. I think there are two sub-topics here:
(1) JIT specifics. E.g. What default optimization pipelines should we
provide in the JIT? The standard 0/1/2/3/s options, or would it make sense
to develop something JIT specific?
(2) General compile time improvements. Everyone will benefit from compile
time improvements, but JIT clients are likely to be extra sensitive to it.
Have we identified any problem areas or redundancies that would be of
interest to the broader LLVM community, and that we could solicit help in
fixing.

Possibly also related to LLJIT design - having LLJIT first generate
> minimally optimized code and then, while that is in use, doing optimization
> and optimized codegen concurrently, would be neat. It feels like that'd
> fit well into LLJIT, given that it already provides things like
> background compile threads.


Absolutely. Supporting this use-case was one of the motivations for the
concurrency support in OrcV2. It's doable at the moment, but it requires a
fair bit of manual work on the client's part. Implementation and API design
in this area seem like good topics.

-- Lang.

On Fri, Oct 2, 2020 at 10:21 AM Andres Freund <andres at anarazel.de> wrote:

> Hi,
>
> On 2020-09-29 01:52:48 +0530, Praveen Velliengiri wrote:
> > I'm also interested in reducing the compilation time of code in JIT
> > component independent of static compiler. Is it sounds interesting? :)
>
> That would be of interest to me too. One thing around this I have been
> wondering about is whether it's realistic to merge the optimization and
> code generation phases - right now we spend a lot of time re-doing
> analyses during codegen that we already had done during optimization.
>
> Possibly also related to LLJIT design - having LLJIT first generate
> minimally optimized code and then, while that is in use, doing optimization
> and optimized codegen concurrently, would be neat. It feels like that'd
> fit well into LLJIT, given that it already provides things like
> background compile threads.
>
> - Andres
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201002/efc89c36/attachment.html>