<div dir="ltr"><div dir="ltr"><div dir="ltr">Hi Andres,<div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">That would be of interest to me too. One thing around this I have been<br>wondering about is whether it's realistic to merge the optimization and<br>code generation phases - right now we spend a lot of time re-doing<br>analyses during codegen that we already had done during optimization.</blockquote></div><div><br></div><div>Sounds good to me. I think there are two sub-topics here:<br></div><div>(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?</div><div>(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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Possibly also related to LLJIT design - having LLJIT first generate<br>minimally optimized code and then, while that is in use, doing optimization<br>and optimized codegen concurrently, would be neat. It feels like that'd<br>fit well into LLJIT, given that it already provides things like<br>background compile threads.</blockquote><div><br></div><div>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.</div><div><br></div><div>-- Lang.</div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Oct 2, 2020 at 10:21 AM Andres Freund <<a href="mailto:andres@anarazel.de">andres@anarazel.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
On 2020-09-29 01:52:48 +0530, Praveen Velliengiri wrote:<br>
> I'm also interested in reducing the compilation time of code in JIT<br>
> component independent of static compiler. Is it sounds interesting? :)<br>
<br>
That would be of interest to me too. One thing around this I have been<br>
wondering about is whether it's realistic to merge the optimization and<br>
code generation phases - right now we spend a lot of time re-doing<br>
analyses during codegen that we already had done during optimization.<br>
<br>
Possibly also related to LLJIT design - having LLJIT first generate<br>
minimally optimized code and then, while that is in use, doing optimization<br>
and optimized codegen concurrently, would be neat. It feels like that'd<br>
fit well into LLJIT, given that it already provides things like<br>
background compile threads.<br>
<br>
- Andres<br>
</blockquote></div>