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

[Kevin Neal via llvm-dev]

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>