<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body dir="auto">
<br>
<br>
<div id="AppleMailSignature" dir="ltr">Best regards,
<div>Alexey Bataev</div>
</div>
<div dir="ltr"><br>
2 июля 2019 г., в 14:34, Finkel, Hal J. via Openmp-dev <<a href="mailto:openmp-dev@lists.llvm.org">openmp-dev@lists.llvm.org</a>> написал(а):<br>
<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<p><br>
</p>
<div class="moz-cite-prefix">On 6/28/19 11:56 PM, James Beyer wrote:<br>
</div>
<blockquote type="cite" cite="mid:MWHPR12MB1501CEF51C31136B85489564ABFF0@MWHPR12MB1501.namprd12.prod.outlook.com">
<meta name="Generator" content="Microsoft Word 15 (filtered
        medium)">
<style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Consolas;
        panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;
        color:black;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:#0563C1;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:#954F72;
        text-decoration:underline;}
pre
        {mso-style-priority:99;
        mso-style-link:"HTML Preformatted Char";
        margin:0in;
        margin-bottom:.0001pt;
        font-size:10.0pt;
        font-family:"Courier New";
        color:black;}
p.msonormal0, li.msonormal0, div.msonormal0
        {mso-style-name:msonormal;
        mso-margin-top-alt:auto;
        margin-right:0in;
        mso-margin-bottom-alt:auto;
        margin-left:0in;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;
        color:black;}
span.HTMLPreformattedChar
        {mso-style-name:"HTML Preformatted Char";
        mso-style-priority:99;
        mso-style-link:"HTML Preformatted";
        font-family:Consolas;
        color:black;}
span.EmailStyle21
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal"><span style="color:windowtext">Recursive data structures are important if you consider linked lists important. 
</span></p>
</div>
</blockquote>
<p><br>
</p>
<p>I definitely agree, and I do.<br>
</p>
<p><br>
</p>
<blockquote type="cite" cite="mid:MWHPR12MB1501CEF51C31136B85489564ABFF0@MWHPR12MB1501.namprd12.prod.outlook.com">
<div class="WordSection1">
<p class="MsoNormal"><span style="color:windowtext"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:windowtext"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:windowtext">Supporting these is challenging but not impossible, I would expect that if someone manages to implement a cost effective way to support linked lists we would add support to OpenMP with ease.</span></p>
</div>
</blockquote>
<p><br>
</p>
<p>In the context of the current proposal, supporting recursion seems to have two effects:</p>
<p> 1. You would not want to use a two-pass traversal to precalculate the size of the mapping table (because if you did two passes, you would traverse the list twice, and hat would be unnecessarily expensive).<br>
</p>
</div>
</blockquote>
<div><br>
</div>
In this case we should review 2 remaining schemes: the original from Lingda and alternative scheme with functional part moved to the runtime and mappers called indirectly by the runtime (see the description provided by Lingda).<br>
<blockquote type="cite">
<div dir="ltr">
<p></p>
<p> 2. We'd need to also maintain a "visited addresses" hash table to prevent infinite recursion. As we build up the array of mapping descriptors, we would also add the addresses to the hash table, and should the address already be present , we'd avoid recursing
 (i.e., just use a regular visited set as one does with a graph traversal).<br>
</p>
<p>Am I overlooking something?</p>
<p> -Hal<br>
</p>
<p><br>
</p>
<blockquote type="cite" cite="mid:MWHPR12MB1501CEF51C31136B85489564ABFF0@MWHPR12MB1501.namprd12.prod.outlook.com">
<div class="WordSection1">
<p class="MsoNormal"><span style="color:windowtext"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:windowtext"><o:p> </o:p></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in
          0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #E1E1E1
              1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="color:windowtext">From:</span></b><span style="color:windowtext"> Finkel, Hal J.
<a class="moz-txt-link-rfc2396E" href="mailto:hfinkel@anl.gov"><hfinkel@anl.gov></a>
<br>
<b>Sent:</b> Friday, June 28, 2019 10:46 PM<br>
<b>To:</b> Alexey Bataev <a class="moz-txt-link-rfc2396E" href="mailto:Alexey.Bataev@ibm.com">
<Alexey.Bataev@ibm.com></a>; Li, Lingda <a class="moz-txt-link-rfc2396E" href="mailto:lli@bnl.gov">
<lli@bnl.gov></a><br>
<b>Cc:</b> Alexandre Eichenberger <a class="moz-txt-link-rfc2396E" href="mailto:alexe@us.ibm.com">
<alexe@us.ibm.com></a>; Chapman, Barbara (Contact) <a class="moz-txt-link-rfc2396E" href="mailto:barbara.chapman@stonybrook.edu">
<barbara.chapman@stonybrook.edu></a>; Kevin K O'Brien <a class="moz-txt-link-rfc2396E" href="mailto:caomhin@us.ibm.com">
<caomhin@us.ibm.com></a>; Carlo Bertolli <a class="moz-txt-link-rfc2396E" href="mailto:cbertol@us.ibm.com">
<cbertol@us.ibm.com></a>; Deepak Eachempati <a class="moz-txt-link-rfc2396E" href="mailto:deachempat@cray.com">
<deachempat@cray.com></a>; Denny, Joel E. <a class="moz-txt-link-rfc2396E" href="mailto:dennyje@ornl.gov">
<dennyje@ornl.gov></a>; David Oehmke <a class="moz-txt-link-rfc2396E" href="mailto:doehmke@cray.com">
<doehmke@cray.com></a>; Ettore Tiotto <a class="moz-txt-link-rfc2396E" href="mailto:etiotto@ca.ibm.com">
<etiotto@ca.ibm.com></a>; <a class="moz-txt-link-abbreviated" href="mailto:fraggamuffin@gmail.com">
fraggamuffin@gmail.com</a>; Rokos, Georgios <a class="moz-txt-link-rfc2396E" href="mailto:georgios.rokos@intel.com">
<georgios.rokos@intel.com></a>; Gheorghe-Teod Bercea <a class="moz-txt-link-rfc2396E" href="mailto:Gheorghe-Teod.Bercea@ibm.com">
<Gheorghe-Teod.Bercea@ibm.com></a>; <a class="moz-txt-link-abbreviated" href="mailto:gregory.rodgers@amd.com">
gregory.rodgers@amd.com</a>; Sharif, Hashim <a class="moz-txt-link-rfc2396E" href="mailto:hsharif3@illinois.edu">
<hsharif3@illinois.edu></a>; Cownie, James H <a class="moz-txt-link-rfc2396E" href="mailto:james.h.cownie@intel.com">
<james.h.cownie@intel.com></a>; Sjodin, Jan <a class="moz-txt-link-rfc2396E" href="mailto:Jan.Sjodin@amd.com">
<Jan.Sjodin@amd.com></a>; James Beyer <a class="moz-txt-link-rfc2396E" href="mailto:jbeyer@nvidia.com">
<jbeyer@nvidia.com></a>; Doerfert, Johannes <a class="moz-txt-link-rfc2396E" href="mailto:jdoerfert@anl.gov">
<jdoerfert@anl.gov></a>; Jones, Jeff C <a class="moz-txt-link-rfc2396E" href="mailto:jeff.c.jones@intel.com">
<jeff.c.jones@intel.com></a>; <a class="moz-txt-link-abbreviated" href="mailto:josem@udel.edu">
josem@udel.edu</a>; Robichaux, Joseph <a class="moz-txt-link-rfc2396E" href="mailto:joseph.robichaux@intel.com">
<joseph.robichaux@intel.com></a>; Jeff Heath <a class="moz-txt-link-rfc2396E" href="mailto:jrheath@ca.ibm.com">
<jrheath@ca.ibm.com></a>; <a class="moz-txt-link-abbreviated" href="mailto:khaldi.dounia@gmail.com">
khaldi.dounia@gmail.com</a>; Kelvin Li <a class="moz-txt-link-rfc2396E" href="mailto:kli@ca.ibm.com">
<kli@ca.ibm.com></a>; Bobrovsky, Konstantin S <a class="moz-txt-link-rfc2396E" href="mailto:konstantin.s.bobrovsky@intel.com">
<konstantin.s.bobrovsky@intel.com></a>; Kotsifakou, Maria <a class="moz-txt-link-rfc2396E" href="mailto:kotsifa2@illinois.edu">
<kotsifa2@illinois.edu></a>; Li, Lingda (Contact) <a class="moz-txt-link-rfc2396E" href="mailto:lildmh@gmail.com">
<lildmh@gmail.com></a>; Lopez, Matthew Graham <a class="moz-txt-link-rfc2396E" href="mailto:lopezmg@ornl.gov">
<lopezmg@ornl.gov></a>; <a class="moz-txt-link-abbreviated" href="mailto:lopezmg@ornl.org">
lopezmg@ornl.org</a>; Menard, Lorri <a class="moz-txt-link-rfc2396E" href="mailto:lorri.menard@intel.com">
<lorri.menard@intel.com></a>; Martin Kong <a class="moz-txt-link-rfc2396E" href="mailto:martin.richard.kong@gmail.com">
<martin.richard.kong@gmail.com></a>; Sarah McNamara <a class="moz-txt-link-rfc2396E" href="mailto:mcnamara@ca.ibm.com">
<mcnamara@ca.ibm.com></a>; Rice, Michael P <a class="moz-txt-link-rfc2396E" href="mailto:michael.p.rice@intel.com">
<michael.p.rice@intel.com></a>; Matt Martineau <a class="moz-txt-link-rfc2396E" href="mailto:m.martineau@bristol.ac.uk">
<m.martineau@bristol.ac.uk></a>; <a class="moz-txt-link-abbreviated" href="mailto:oscar@ornl.gov">
oscar@ornl.gov</a>; Jeeva Paudel <a class="moz-txt-link-rfc2396E" href="mailto:pjeeva01@ca.ibm.com">
<pjeeva01@ca.ibm.com></a>; Rao, Premanand M <a class="moz-txt-link-rfc2396E" href="mailto:premanand.m.rao@intel.com">
<premanand.m.rao@intel.com></a>; Krishnaiyer, Rakesh <a class="moz-txt-link-rfc2396E" href="mailto:rakesh.krishnaiyer@intel.com">
<rakesh.krishnaiyer@intel.com></a>; Narayanaswamy, Ravi <a class="moz-txt-link-rfc2396E" href="mailto:ravi.narayanaswamy@intel.com">
<ravi.narayanaswamy@intel.com></a>; Monteleone, Robert <a class="moz-txt-link-rfc2396E" href="mailto:robert.monteleone@intel.com">
<robert.monteleone@intel.com></a>; Lieberman, Ron <a class="moz-txt-link-rfc2396E" href="mailto:Ron.Lieberman@amd.com">
<Ron.Lieberman@amd.com></a>; Samuel Antao <a class="moz-txt-link-rfc2396E" href="mailto:Samuel.Antao@ibm.com">
<Samuel.Antao@ibm.com></a>; Jeffrey Sandoval <a class="moz-txt-link-rfc2396E" href="mailto:sandoval@cray.com">
<sandoval@cray.com></a>; Sunita Chandrasekaran <a class="moz-txt-link-rfc2396E" href="mailto:schandra@udel.edu">
<schandra@udel.edu></a>; <a class="moz-txt-link-abbreviated" href="mailto:sergey.y.ostanevich@gmail.com">
sergey.y.ostanevich@gmail.com</a>; Sergio Pino Gallardo <a class="moz-txt-link-rfc2396E" href="mailto:sergiop@udel.edu">
<sergiop@udel.edu></a>; Dmitriev, Serguei N <a class="moz-txt-link-rfc2396E" href="mailto:serguei.n.dmitriev@intel.com">
<serguei.n.dmitriev@intel.com></a>; Chan, SiuChi <a class="moz-txt-link-rfc2396E" href="mailto:siuchi.chan@amd.com">
<siuchi.chan@amd.com></a>; Sunil Shrestha <a class="moz-txt-link-rfc2396E" href="mailto:sshrestha@cray.com">
<sshrestha@cray.com></a>; Wilmarth, Terry L <a class="moz-txt-link-rfc2396E" href="mailto:terry.l.wilmarth@intel.com">
<terry.l.wilmarth@intel.com></a>; Tianyi Zhang <a class="moz-txt-link-rfc2396E" href="mailto:tzhan18@lsu.edu">
<tzhan18@lsu.edu></a>; <a class="moz-txt-link-abbreviated" href="mailto:vadve@illinois.edu">
vadve@illinois.edu</a>; Wang Chen <a class="moz-txt-link-rfc2396E" href="mailto:wdchen@ca.ibm.com">
<wdchen@ca.ibm.com></a>; Wael Yehia <a class="moz-txt-link-rfc2396E" href="mailto:wyehia@ca.ibm.com">
<wyehia@ca.ibm.com></a>; Tian, Xinmin <a class="moz-txt-link-rfc2396E" href="mailto:xinmin.tian@intel.com">
<xinmin.tian@intel.com></a>; <a class="moz-txt-link-abbreviated" href="mailto:cfe-dev@lists.llvm.org">
cfe-dev@lists.llvm.org</a>; <a class="moz-txt-link-abbreviated" href="mailto:openmp-dev@lists.llvm.org">
openmp-dev@lists.llvm.org</a><br>
<b>Subject:</b> Re: Comparison of 2 schemes to implement OpenMP 5.0 declare mapper codegen<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p>Hi, Alexey, Lingda,<o:p></o:p></p>
<p>I haven't been following this closely, so a few questions/comments:<o:p></o:p></p>
<p> 1. Recursive mappers are not supported in OpenMP 5, but do we expect that to change in the future?<o:p></o:p></p>
<p> 2. Our experience so far suggests that the most important optimization in this space is to limit the number of distinct host-to-device transfers (or data copies) on systems where data needs to be copied. In these schemes, where does that coalescing occur?<o:p></o:p></p>
<p> 3. So long as the mappers aren't recursive, I agree with Alexey that the total number of to-be-mapped components should be efficient to calculate. The counting function should simplify to a trivial expression in nearly all cases. The only case where it
 might not is where the type contains an array section with dynamic bounds, and the element type also has a mapper with an array section with dynamic bounds. In this case (similar to the unsupported recursive cases, which as an aside, we should probably support
 it as an extension) we could need to walk the data structure twice to precalculate the number of total components to map. However, this case is certainly detectable by static analysis of the declared mappers, and so I think that we can get the best of both
 worlds: we could use Alexey's proposed scheme except in cases where we truly need to walk the data-structure twice, in which case we could use Lingda's combined walk/push_back scheme. Is there any reason why that wouldn't work?<o:p></o:p></p>
<p>Thanks again,<o:p></o:p></p>
<p>Hal<o:p></o:p></p>
<div>
<p class="MsoNormal">On 6/28/19 9:00 AM, Alexey Bataev wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p><span style="font-size:10.0pt">Hi Lingda, thanks for your comments.</span><br>
<span style="font-size:10.0pt">We can allocate the buffer either by allocating it on the stack or calling OpenMP allocate function.</span><br>
<span style="font-size:10.0pt">With this solution, we allocate memory only once (no need to resize buffer after push_backs) and we do not need to call the runtime function to put map data to the buffer, compiler generated code can do it.</span><br>
<span style="font-size:10.0pt">But anyway, I agree, it would be good to hear some other opinions.</span><br>
<span style="font-size:10.0pt">--------------</span><br>
<span style="font-size:10.0pt">Best regards,</span><br>
<span style="font-size:10.0pt">Alexey Bataev</span><o:p></o:p></p>
</blockquote>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p><span style="font-size:10.0pt">...</span><o:p></o:p></p>
</blockquote>
<pre>-- <o:p></o:p></pre>
<pre>Hal Finkel<o:p></o:p></pre>
<pre>Lead, Compiler Technology and Programming Languages<o:p></o:p></pre>
<pre>Leadership Computing Facility<o:p></o:p></pre>
<pre>Argonne National Laboratory<o:p></o:p></pre>
</div>
</div>
<div>
<hr>
</div>
<div>This email message is for the sole use of the intended recipient(s) and may contain confidential information.  Any unauthorized review, use, disclosure or distribution is prohibited.  If you are not the intended recipient, please contact the sender by
 reply email and destroy all copies of the original message. </div>
<div>
<hr>
</div>
</blockquote>
<pre class="moz-signature" cols="72">-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
</div>
</blockquote>
<blockquote type="cite">
<div dir="ltr"><span>_______________________________________________</span><br>
<span>Openmp-dev mailing list</span><br>
<span><a href="mailto:Openmp-dev@lists.llvm.org">Openmp-dev@lists.llvm.org</a></span><br>
<span><a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev">https://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev</a></span><br>
</div>
</blockquote>
</body>
</html>