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

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-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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180426/01291d18/attachment.html>

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>

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>

Hi Hal,
   We are not trying to address issues where the object mapped are of different
sizes between host and target with different ABI.  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-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 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180427/3d3dfbf3/attachment.html>

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>