[llvm-dev] LLVM Orc Weekly #28 -- ORC Runtime Prototype update

Kevin Neal via llvm-dev
Wed, 20 Jan 2021 21:48:00 -0000

Would this introduce start-up latency based on the size of the compilation? JIT
jobs with 100-200MB of source are not uncommon here, and I'd hate to see
latency get much worse.

A small enough fixed latency would be ok.
--
Kevin P. Neal
SAS/C and SAS/C++ Compiler
Compute Services
SAS Institute, Inc.


From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Lang
Hames via llvm-dev
Sent: Tuesday, January 19, 2021 5:09 PM
To: Stefan Gränitz <stefan.graenitz at gmail.com>
Cc: Vivien Millet <vivien.millet at gmail.com>; Athul Acharya <aacharya
at gmail.com>; LLVM Developers Mailing List <llvm-dev at
lists.llvm.org>; kris <cq.personal at gmail.com>; Jared Wyles
<jared.wyles at gmail.com>; Frances Mocnik <fmocnik at gmail.com>;
Jacob Lifshay <programmerjake at gmail.com>; Christian Schafmeister
<meister at temple.edu>
Subject: Re: [llvm-dev] LLVM Orc Weekly #28 -- ORC Runtime Prototype update


EXTERNAL
Big question for JIT clients: Does anyone have any objection to APIs in ORC
*relying* on the runtime being loaded in the target? If so, now is the time to
let me know. :)

I think possible objections are JIT'd program startup time (unlikely to be
very high, and likely fixable via careful runtime design and pre-linking of
parts of the runtime), and difficulties building compiler-rt (which sounds like
something we should fix in compiler-rt).

If we can assume that the runtime is loadable then we can significantly simplify
the TargetProcess library, and TargetProcessControl API, and further accelerate
feature development in LLVM 13.

-- Lang.


-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210120/d2e976be/attachment.html>