jhuber6 wrote:
This seems like something we should discuss at one of the weekly meetings,
since it has pretty large implications for what this library is supposed to do.
https://github.com/llvm/llvm-project/pull/148648
___
llvm-branch-commits mailing
https://github.com/RossBrunton converted_to_draft
https://github.com/llvm/llvm-project/pull/148648
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
RossBrunton wrote:
@jhuber6 That would mean that any program that wants to do dynamic linking
would need to ship a full clang install alongside `libLLVMOffload.so`. The
programmer would also have to mess around with writing/reading files and
invoking a subprocess.
IMO, since this code already
jhuber6 wrote:
> @jhuber6 I'm looking at implementing a version of
> [urProgramLink](https://oneapi-src.github.io/unified-runtime/core/api.html#urprogramlink)
> for liboffload, which is used by SYCL.
>
> More generally though, linking is very backend dependant, and liboffload
> already has lo
https://github.com/jhuber6 commented:
I'm kind of iffy here, I'm not sure if it's the runtime's job to be a linker.
The `createProgram` interface already should handle 'JIT' compilation by
detecting magics bits for LLVM-IR, ELF, PTX, or SPIR-V or whatever, but it's
expected that the user provi
llvmbot wrote:
@llvm/pr-subscribers-offload
Author: Ross Brunton (RossBrunton)
Changes
A version of `olCreateProgram` that inputs many bitcode files and links
them together before loading them.
---
Full diff: https://github.com/llvm/llvm-project/pull/148648.diff
11 Files Affected:
- (
https://github.com/RossBrunton created
https://github.com/llvm/llvm-project/pull/148648
A version of `olCreateProgram` that inputs many bitcode files and links
them together before loading them.
>From 8589fcc6d053cb2937cf970d1ce354abfb84da31 Mon Sep 17 00:00:00 2001
From: Ross Brunton
Date: M
