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

Lang Hames via llvm-dev llvm-dev at lists.llvm.org
Tue Jan 19 15:24:46 PST 2021


Hi Geoff,

We always compile and execute in the same process, so I don't imagine that
> would make any difference to us...?


The runtime would be required for both in-process and out-of-process JITing
if you use any features that depend on it. Existing and planned features
that would require the runtime include: lazy compilation, exception
handling, static initializer / destructors, thread local variables, and API
based target memory access. Failure to load the runtime will cause any of
these features to issue an error when used (probably a "failed to resolve
symbol XXX" for the corresponding runtime implementation symbol).

So you'll need to build compiler-rt and ship the orc runtime alongside your
JIT to use any of the features above.

-- Lang.

On Wed, Jan 20, 2021 at 10:04 AM Geoff Levner <glevner at gmail.com> wrote:

> We always compile and execute in the same process, so I don't imagine that
> would make any difference to us...?
>
> Geoff
>
> On Tue, Jan 19, 2021 at 11:08 PM Lang Hames <lhames at gmail.com> wrote:
>
>> 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/a7579ea3/attachment.html>


More information about the llvm-dev mailing list