<div dir="ltr">I thought the target options were older than FMF. I don't think they were created as a workaround for a shortcoming of FMF. Though that may be what they've become.<div><br clear="all"><div><div dir="ltr" data-smartmail="gmail_signature">~Craig</div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Oct 30, 2021 at 9:44 AM Wang, Pengfei via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div lang="EN-US">
<div>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">As far as I understand it, they are two different things.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">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.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">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.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">I think this is the problem Andy wants to solve.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">I didn’t learn it much, forgive me if I understand something wrong here :)<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">Thanks<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">Phoebe (Pengfei)<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"><u></u> <u></u></span></p>
<div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(225,225,225);padding:3pt 0in 0in">
<p class="MsoNormal"><b>From:</b> Renato Golin <<a href="mailto:rengolin@gmail.com" target="_blank">rengolin@gmail.com</a>> <br>
<b>Sent:</b> Sunday, October 31, 2021 12:28 AM<br>
<b>To:</b> Wang, Pengfei <<a href="mailto:pengfei.wang@intel.com" target="_blank">pengfei.wang@intel.com</a>><br>
<b>Cc:</b> Kaylor, Andrew <<a href="mailto:andrew.kaylor@intel.com" target="_blank">andrew.kaylor@intel.com</a>>; Yaxun Liu <<a href="mailto:yaxun.liu@amd.com" target="_blank">yaxun.liu@amd.com</a>>; Sebastian Pop <<a href="mailto:sebpop@gmail.com" target="_blank">sebpop@gmail.com</a>>; Ammarguellat, Zahira <<a href="mailto:zahira.ammarguellat@intel.com" target="_blank">zahira.ammarguellat@intel.com</a>>; Ulrich Weigand <<a href="mailto:Ulrich.Weigand@de.ibm.com" target="_blank">Ulrich.Weigand@de.ibm.com</a>>; Ballman, Aaron <<a href="mailto:aaron.ballman@intel.com" target="_blank">aaron.ballman@intel.com</a>>;
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<b>Subject:</b> Re: [llvm-dev] [RFC] Eliminating non-IR floating-point controls in the selection DAG<u></u><u></u></p>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">On Sat, 30 Oct 2021 at 17:15, Wang, Pengfei <<a href="mailto:pengfei.wang@intel.com" target="_blank">pengfei.wang@intel.com</a>> wrote:<u></u><u></u></p>
</div>
<div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">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><u></u><u></u></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">Here’s an example
<a href="https://reviews.llvm.org/D84518" target="_blank">https://reviews.llvm.org/D84518</a></span><u></u><u></u></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">This problem has been greatly improved since
<a href="https://reviews.llvm.org/D87361" target="_blank">https://reviews.llvm.org/D87361</a></span><u></u><u></u></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">I think we have the similar problem in MIR based optimizations, but I didn’t dig into it.</span><u></u><u></u></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">This sounds like a somewhat large, but mostly mechanical problem to solve, correct?<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></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.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></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).<u></u><u></u></p>
</div>
</div>
</div>
</div>
</div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>