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

Hal Finkel via llvm-dev llvm-dev at lists.llvm.org
Wed Apr 25 17:49:39 PDT 2018


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]
> *Sent:* Wednesday, April 25, 2018 4:14 PM
> *To:* Lin, Jin <jin.lin at intel.com>; '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-gnucannot 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 list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180425/0afd4f8c/attachment.html>


More information about the llvm-dev mailing list