llvm dev - Oct 2020 - LLVM Developers Meeting JIT BoF -- Request for Topics of Interest

Hi,
I would like to discuss the future/potential use-cases of LLVM JIT. I'm
also interested in reducing the compilation time of code in JIT component
independent of static compiler. Is it sounds interesting? :)


On Sat, 26 Sep 2020 at 07:49, Andres Freund <andres at anarazel.de> wrote:
> Hi,
>
> On 2020-09-25 19:05:42 -0700, Lang Hames wrote:
> > The 2020 Virtual LLVM Developer's Meeting is coming up the week
after
> next.
> > I'll be hosting a JIT Birds-of-a-Feather session on Thursday the
8th at
> > 10:55am PDT (See http://llvm.org/devmtg/2020-09/schedule/). I'm
> planning to
> > run this more like a Round Table: Minimal introduction, plenty of time
> for
> > discussion.
> >
> > Does anyone have any LLVM JIT related topics that they would
particularly
> > like to discuss at this session? Any questions that they think could
be
> > best answered by a round-table style discussion? I'll aim to rope
in the
> > right people and prepare answers to make sure we get the most out of
the
> > session.
>
> A topic that I'd find interesting is what it'd take to make it
easier to
> use profile guided optimization in the context of JIT.  A few years back
> I crudely hacked this together, but it was fairly ugly. It'd be nice to
> make that easier.  Possibly too complicated for that type of session?
>
> I dimly recall that the main issue was that there is no good way to
> extract the profile information without going through files / applying
> the profile data without going through files.
>
> Greetings,
>
> Andres Freund
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200929/7d7e810a/attachment.html>

Hi Praveen,

I would like to discuss the future/potential use-cases of LLVM JIT.


That sounds like a great topic. I can mention a couple of my use cases in
the meeting, but I'll be very keen to hear what everyone else has in mind.

I'm also interested in reducing the compilation time of code in
JIT
> component independent of static compiler. Is it sounds interesting? :)

That sounds great too. To-date I've been focused on the API design
problems, but it's a great time for us to start monitoring/improving
performance too.

-- Lang.

On Mon, Sep 28, 2020 at 1:23 PM Praveen Velliengiri <
praveenvelliengiri at gmail.com> wrote:
> Hi,
> I would like to discuss the future/potential use-cases of LLVM JIT. I'm
> also interested in reducing the compilation time of code in JIT component
> independent of static compiler. Is it sounds interesting? :)
>
>
> On Sat, 26 Sep 2020 at 07:49, Andres Freund <andres at anarazel.de>
wrote:
>
>> Hi,
>>
>> On 2020-09-25 19:05:42 -0700, Lang Hames wrote:
>> > The 2020 Virtual LLVM Developer's Meeting is coming up the
week after
>> next.
>> > I'll be hosting a JIT Birds-of-a-Feather session on Thursday
the 8th at
>> > 10:55am PDT (See http://llvm.org/devmtg/2020-09/schedule/).
I'm
>> planning to
>> > run this more like a Round Table: Minimal introduction, plenty of
time
>> for
>> > discussion.
>> >
>> > Does anyone have any LLVM JIT related topics that they would
>> particularly
>> > like to discuss at this session? Any questions that they think
could be
>> > best answered by a round-table style discussion? I'll aim to
rope in the
>> > right people and prepare answers to make sure we get the most out
of the
>> > session.
>>
>> A topic that I'd find interesting is what it'd take to make it
easier to
>> use profile guided optimization in the context of JIT.  A few years
back
>> I crudely hacked this together, but it was fairly ugly. It'd be
nice to
>> make that easier.  Possibly too complicated for that type of session?
>>
>> I dimly recall that the main issue was that there is no good way to
>> extract the profile information without going through files / applying
>> the profile data without going through files.
>>
>> Greetings,
>>
>> Andres Freund
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200928/a7fc7409/attachment.html>

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

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>