<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:SimSun;
panose-1:2 1 6 0 3 1 1 1 1 1;}
@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:"\@SimSun";
panose-1:2 1 6 0 3 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#1F497D;
font-weight:normal;
font-style:normal;
text-decoration:none none;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@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="EN-US" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span style="color:#1F497D">As far as I understand it, they are two different things.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Backends used to use target option due to some mechanical problem. But backends strictly respect the FMFs in instructions. This is also the reason why they use target options that way.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Frontends don’t strictly respect the FMFs in instructions, so if there’s no FMFs in instructions, the FMFs are determined by module/function attributes.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">I think this is the problem Andy wants to solve.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">I didn’t learn it much, forgive me if I understand something wrong here :)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Thanks<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Phoebe (Pengfei)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Renato Golin <rengolin@gmail.com> <br>
<b>Sent:</b> Sunday, October 31, 2021 12:28 AM<br>
<b>To:</b> Wang, Pengfei <pengfei.wang@intel.com><br>
<b>Cc:</b> Kaylor, Andrew <andrew.kaylor@intel.com>; Yaxun Liu <yaxun.liu@amd.com>; Sebastian Pop <sebpop@gmail.com>; Ammarguellat, Zahira <zahira.ammarguellat@intel.com>; Ulrich Weigand <Ulrich.Weigand@de.ibm.com>; Ballman, Aaron <aaron.ballman@intel.com>;
llvm-dev@lists.llvm.org<br>
<b>Subject:</b> Re: [llvm-dev] [RFC] Eliminating non-IR floating-point controls in the selection DAG<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Sat, 30 Oct 2021 at 17:15, Wang, Pengfei <<a href="mailto:pengfei.wang@intel.com">pengfei.wang@intel.com</a>> wrote:<o:p></o:p></p>
</div>
<div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:#1F497D">SelectionDAG has many overloaded methods of “getNode”, some of which don’t need to specify the Flags argument. This is reasonable because only FP nodes
need that. But it also easily results in losing the Flags in the FP nodes too.</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:#1F497D">Here’s an example
<a href="https://reviews.llvm.org/D84518" target="_blank">https://reviews.llvm.org/D84518</a></span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:#1F497D">This problem has been greatly improved since
<a href="https://reviews.llvm.org/D87361" target="_blank">https://reviews.llvm.org/D87361</a></span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:#1F497D">I think we have the similar problem in MIR based optimizations, but I didn’t dig into it.</span><o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">This sounds like a somewhat large, but mostly mechanical problem to solve, correct?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Once we have a way to propagate the flags down to instruction selection, then we don't need the target info overriding IR semantics.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Andrew, is that what you're proposing originally? (Sorry if I'm slow to catch, I worried about changing the IR for front-ends but it seems it was misplaced).<o:p></o:p></p>
</div>
</div>
</div>
</div>
</body>
</html>