[llvm-dev] [LLVM][RFC] Representing the target device information in the LLVM IR
Hal Finkel via llvm-dev
llvm-dev at lists.llvm.org
Thu Apr 26 17:14:06 PDT 2018
On 04/26/2018 07:03 PM, Narayanaswamy, Ravi wrote:
>
> Hi Hal,
>
> We are not trying to address issues where the object mapped are of
> different sizes between host and target with different ABI.
>
Why are you not trying to address that issue?
-Hal
> The issue is when the objects are of same size like double which is
> 8bytes on both 32bit and 64bit platform. If a double is used in a
> first_private on a target clause, the 64 bit side will pass it as
> value whereas on the 32bit side since the value does not fit in the
> argument it will be passed as pointer to a double. There will be a
> mis-match at the call site and entry site on this value.
>
> The main reason for this change is that when we do backend outlining
> for target pragmas the targets information needs to be communicated to
> the backend to generate the tables with the right names. Generate
> LLVM IR for passing this information is one mechanism and other is
> passing the command option to the backend. For the later each pass
> which needs this info will have to change.
>
> Thanks
>
> Ravi
>
>
>
> *From:*Hal Finkel [mailto:hfinkel at anl.gov]
> *Sent:* Wednesday, April 25, 2018 5:50 PM
> *To:* Lin, Jin <jin.lin at intel.com <mailto:jin.lin at intel.com>>;
> Friedman, Eli <efriedma at codeaurora.org
> <mailto:efriedma at codeaurora.org>>; 'llvm-dev at lists.llvm.org'
> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>
> *Subject:* Re: [llvm-dev] [LLVM][RFC] Representing the target device
> information in the LLVM IR
>
>
>
> 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> <mailto:jin.lin at intel.com>;
> 'llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>'
> <llvm-dev at lists.llvm.org> <mailto: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 <mailto: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
--
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/20180426/ba734e34/attachment.html>
More information about the llvm-dev
mailing list