[LLVMdev] Supporting heterogeneous computing in llvm. (original) (raw)

Christos Margiolas chrmargiolas at gmail.com
Tue Jul 7 18:27:06 PDT 2015

Hi Sergey,

Apologies for the delayed response. All the transformations take place in IR. I will post more information later today or tomorrow.

thanks, chris

On Tue, Jun 9, 2015 at 4:40 PM, Sergey Ostanevich <sergos.gnu at gmail.com> wrote:

Chirs,

From those two replies you sent I can't get the point. Here you say modules compiled independently for host and target (accelerator) and that IR is not a good place to tackle the architecture differences: On Tue, Jun 9, 2015 at 10:17 AM, Christos Margiolas <chrmargiolas at gmail.com> wrote: > In fact, I have two modules: > a) the Host one > b) the Accelerator one > > Each one gets compiled independently. The runtime takes care of the > offloading operations and loads the accelerator code. Imagine that you want > to compile for amd64 and nvidia ptx. You cannot do it in a single module and > even if you support it, it is gonna become scary. How are you gonna handle > architecture differences that affect the IR in a nice way? e.g. pointer > size, stack alignment and much more... > And 11 minutes later you write: On Tue, Jun 9, 2015 at 10:28 AM, Christos Margiolas <chrmargiolas at gmail.com> wrote: > Hello, > > I can see some fundamental differences between this work and my work. > However, I think they are more complementary than "competitive". My work > handles code extraction for offloading (in IR level) and offloading control [...] > The scheme you refer could be supported on the top of my infrastructure. I > personally believe that code extraction and transformations for offloading > should be done in IR and not in source level. The reason is that in IR level > you have enough information about your program (e.g. datatypes) and a good > idea about your target architectures. > Can you please clarify the scheme you propose: whether modules are different from the source level? How do you plan to address the architecture differences in the IR level? Regards, Sergos -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150708/1e82de28/attachment.html>

More information about the llvm-dev mailing list