<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<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 Light";
panose-1:2 15 3 2 2 2 4 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin-top:0in;
margin-right:0in;
margin-bottom:8.0pt;
margin-left:0in;
line-height:105%;
font-size:11.0pt;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}
h1
{mso-style-priority:9;
mso-style-link:"Heading 1 Char";
margin-top:12.0pt;
margin-right:0in;
margin-bottom:0in;
margin-left:0in;
margin-bottom:.0001pt;
line-height:105%;
page-break-after:avoid;
font-size:16.0pt;
font-family:"Calibri Light",sans-serif;
color:#2E74B5;
mso-fareast-language:EN-US;
font-weight:normal;}
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;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.Heading1Char
{mso-style-name:"Heading 1 Char";
mso-style-priority:9;
mso-style-link:"Heading 1";
font-family:"Calibri Light",sans-serif;
color:#2E74B5;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}
@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]-->
</head>
<body lang="RU" link="#0563C1" vlink="#954F72">
<div class="WordSection1">
<h1><span lang="EN-US">Problem overview<o:p></o:p></span></h1>
<p class="MsoNormal"><span lang="EN-US">OpenMP offload functionality is currently not supported in static libraries. Because of that an attempt to use offloading in static libraries ends up with a fallback execution of target regions on the host. This limitation
clearly has significant impact on OpenMP offload usability.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">An output object file that is created by the compiler for offload compilation is a fat object. Such object files besides the code for the host architecture also contains code for the offloading targets which is stored
as data in ELF sections with predefined names. Thus, a static library that is created from object files produced by offload compilation would be an archive of fat objects.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Clang driver currently never passes fat objects directly to any toolchain. Instead it performs an unbundling operation for each fat object which extract host and device parts from the object. These parts are then independently
processed by the corresponding target toolchains. However, current implementation does not assume that static archives may also be composed from fat objects. No unbundling is done for static archives (they are passed to linker as is) and thus device parts
of objects from such archives get ignored.<o:p></o:p></span></p>
<h1><span lang="EN-US">Suggested solution<o:p></o:p></span></h1>
<p class="MsoNormal"><span lang="EN-US">It seems feasible to resolve this problem by changing the offload link process - adding an extra step to the link flow which will do a partial linking (ld -r) of fat objects and static libraries as shown on this diagram<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:8.0pt;line-height:105%;font-family:"Courier New"">[Fat objects] \ / [Target1 link] \<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:8.0pt;line-height:105%;font-family:"Courier New""> [Partial linking] - [Unbundling] – [TargetN link] – [Host link]<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:8.0pt;line-height:105%;font-family:"Courier New"">[Static libs] / \--- Host part --/<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">(You can also look at the .pdf file on this link
</span><a href="https://drive.google.com/file/d/1ZTNoB-Ghin1BTaiZ312FMSRS6rISDtlr/view?usp=sharing"><span lang="EN-US">https://drive.google.com/file/d/1ZTNoB-Ghin1BTaiZ312FMSRS6rISDtlr/view?usp=sharing</span></a><span lang="EN-US"> for illustrations for the
suggested change)<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Linker will pull in all necessary dependencies from static libraries while performing partial linking, so the result of partial linking would be a fat object with concatenated device parts from input fat objects and required
dependencies from static libraries. These concatenated device objects will be stored in the corresponding ELF sections of the partially linked object.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Unbundling operation on the partially linked object will create one or more device objects for each offloading target, and these objects will be linked by corresponding target toolchains the same way as it is done now.
Offload bundler tool would require enhancements to support unbundling of multiple concatenated device objects for each offloading target.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Host link action can be changed to use host part of the partially linked object while linking the final image.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Do you see any potential problems in the proposed change?<o:p></o:p></span></p>
</div>
</body>
</html>