[llvm-dev] [LLVM][RFC] Representing the target device information in the LLVM IR

[Eric Christopher via llvm-dev]

To follow on here:

This is most assuredly just the tip of the iceberg if you need to co-mingle
two targets as part of the module. Basically any solution is going to be
better than trying to do that.

-eric

On Wed, Apr 25, 2018 at 5:49 PM Hal Finkel via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Hi, Jin,
>
> Can you please back up a bit and talk about the programming environment in
> which this problem manifests?
>
> If I have a host and a target with different ABIs, then it seems we have
> lots of problems. For one thing, the layouts of structures are different,
> the sizes of some integer types are different, the sizes of pointers are
> different, and so on. It seems like a solution in this space should
> address, somehow, this general translation problem. Fixing this particular
> problem with the dispatch function's parameters feels like only the tip of
> the iceberg. What if I'm passing a pointer to some structure, or a pointer
> to other pointers, etc.?
>
> I understand that OpenMP v5 is expected to have some custom "mappers" to
> handle deep copying and translation. Is this related to the design space
> here?
>
> Thanks again,
>
> Hal
>
> On 04/25/2018 07:22 PM, Lin, Jin via llvm-dev wrote:
>
> For the firstprivate clause, the compiler generates code to pass it  by
> value or by reference to the outlined function. The reason the first
> private scalars is generally passed by value is for the performance reason.
>
> For this particular case, the compiler cannot generate code to pass the
> double @gg by value under i386-pc-linux-gnu since the value is 64 bit while
> the architecture is 32bit.
>
> For the host compilation, the compiler generates the code to pass the data
> as well as the outlined function name to the OMP runtime.
>
> For the target compilation, the compiler generates the outlined function
> so that it can be called by the OMP runtime.
>
> So, the compiler is required to generate a single call on the host to
> support all the targets. All the target versions must have the same
> interface. So the common interface of the outline function should be used.
> For this particular example, the variable @gcc should be passed by
> reference under x86_64-mic.
>
> Please let me know if you have more questions.
>
> Jin
>
>
>
> *From:* Friedman, Eli [mailto:efriedma at codeaurora.org
> <efriedma at codeaurora.org>]
> *Sent:* Wednesday, April 25, 2018 4:14 PM
> *To:* Lin, Jin <jin.lin at intel.com> <jin.lin at intel.com>; '
> llvm-dev at lists.llvm.org' <llvm-dev at lists.llvm.org>
> <llvm-dev at lists.llvm.org>
> *Subject:* Re: [llvm-dev] [LLVM][RFC] Representing the target device
> information in the LLVM IR
>
>
>
> On 4/25/2018 3:48 PM, Lin, Jin wrote:
>
> Given a global variable @gg, the compiler has to generate code on the host
> to specify whether it is passed by value or passed by reference. In the
> following example, if the compiler generates the code for passing by value,
> the outlined function on the target i386-pc-linux-gnu cannot get the
> correct value since it assumes the variable @gg is passed by reference.
>
>
>
> Here is the corresponding IR on the host side.
>
>   %0 = load double, double* @gg, align 8, !tbaa !3
>
>   %1 = bitcast double %0 to i64
>
>    …
>
>   %12 = getelementptr inbounds [4 x i8*], [4 x i8*]* %.offload_baseptrs,
> i32 0, i32 2
>
>   %13 = bitcast i8** %12 to i64*
>
>   store i64 %1, i64* %13, align 8
>
>
> Could you describe the overall process of calling an offloaded function in
> a bit more detail?  How do you describe the ABI of the called function to
> the OpenMP runtime?
>
> I suspect you shouldn't be trying to store things which aren't pointers
> into offload_baseptrs.
>
> -Eli
>
>
> --
>
> Employee of Qualcomm Innovation Center, Inc.
>
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
>
>
>
> _______________________________________________
> LLVM Developers mailing listllvm-dev at lists.llvm.orghttp://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
> --
> Hal Finkel
> Lead, Compiler Technology and Programming Languages
> Leadership Computing Facility
> Argonne National Laboratory
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180426/d06d5cad/attachment.html>