<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=utf-8">
<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;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
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;}
span.EmailStyle18
{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;}
/* List Definitions */
@list l0
{mso-list-id:1153571117;
mso-list-template-ids:-138248582;}
@list l0:level1
{mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level2
{mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level3
{mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level4
{mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level5
{mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level6
{mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level7
{mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level8
{mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level9
{mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></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="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal">We could also just change the intrinsic at the IR level so it isn’t ambiguous. It’s confusing to have an intrinsic that does either an integer add or a floating-point add depending on the type, anyway. Is it just llvm.aarch64.neon.addp
that has this issue?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">-Eli<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></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>From:</b> llvm-dev <llvm-dev-bounces@lists.llvm.org> <b>On Behalf Of
</b>Amara Emerson via llvm-dev<br>
<b>Sent:</b> Monday, March 11, 2019 12:31 PM<br>
<b>To:</b> llvm-dev <llvm-dev@lists.llvm.org><br>
<b>Subject:</b> [EXT] [llvm-dev] GlobalISel: Ambiguous intrinsic semantics problem<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">Hi GlobalISel interested parties,<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">A recent bug report (<a href="https://bugs.llvm.org/show_bug.cgi?id=40968">https://bugs.llvm.org/show_bug.cgi?id=40968</a>) on AArch64 exposed a problem with our modeling of intrinsic semantics when dealing with type overloaded calls. The
crux of the matter is that because GlobalISel’s LowLevelTypes only carry size and vector layout information, and not any information about whether a type is integer or fp, we lose information during IR translation of type overloaded intrinsics.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Most of the time, we don’t run into this issue because the generic opcodes distinguish between fp and int operations, and for most intrinsics the regbank can normally disambiguate the operation (e.g. the source operands are assigned either
gpr or fpr banks). However, this isn’t enough in the case of vectors on arm64, which can contain both fp and int elements, and if target intrinsics have been defined to use their type overloading to determine the semantics, then we can select the wrong instruction.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Some approaches to fix this:<o:p></o:p></p>
</div>
<div>
<ol start="1" type="1">
<li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1">
We can try to propagate the missing information through the G_INTRINSIC instruction. We could do this either through some additional storage in MachineInstr, or through an additional operand to store type information (a single bit per operand should suffice).
These come with the drawbacks of either increasing the size of MachineInstr, or breaking existing code that deals with intrinsics by adding a new operand somewhere.<o:p></o:p></li><li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1">
Change the LLT types in GISel to distinguish between fp and integer types. This seems like the most natural fix in that we match the IR type system more closely, but it also has very significant impacts on the existing GISel codebase. An fp “flag” on a type
that only affects types used by intrinsics sounds tempting, but it doesn’t work when we have to propagate those types through other users and copies. This means that if we decide to add an fp variant, we have to change the entire design of GISel to now handle
both integer and fp types, whereas before we only cared about their size/vector structure.<o:p></o:p></li><li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1">
Somehow do target intrinsic translation so that any ambiguous operations get split into sub-intrinsics to ensure they’re distinct. This approach has the disadvantages of requiring manual handling of these intrinsics, and that means that we can’t handle any
ambiguous intrinsics automatically through the current pattern importer or the future GISel-native pattern selector. We could potentially detect these by re-using the importer to do analysis and emit warnings when two different output instructions map to the
same input pattern. This is more of a workaround rather than an actual fix of the underlying problem.<o:p></o:p></li></ol>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Any strong preferences for a route forward?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Thanks,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Amara<o:p></o:p></p>
</div>
</div>
</div>
</div>
</body>
</html>