<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 17, 2019 at 11:07 AM Cameron McInally <<a href="mailto:cameron.mcinally@nyu.edu">cameron.mcinally@nyu.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">On Mon, Sep 16, 2019 at 9:43 PM Matt Arsenault via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><br><div><br><blockquote type="cite"><div>On Sep 16, 2019, at 19:57, Kaylor, Andrew via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="gmail-m_-4493815041522952565gmail-m_2624837108875827113gmail-m_-6609843901662790517Apple-interchange-newline"><div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><u></u> <u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none">Do we need an ftz fast-math flag?</div></div></blockquote><div><br></div><div>This would be useful for matching a handful of AMDGPU instructions (a fmad that only always flushes being the most important). We have a dedicated intrinsic to allow flushing in this case when denormals are enabled</div></div></div></blockquote><div><br></div><div>+1 </div><div><br></div><div>For FTZ/DAZ, we're currently getting cases like this incorrect:</div><div><br></div><div><div>  %add = fadd nnan ninf nsz float %a, 0.000000e+00</div></div><div><br></div><div>That cannot be safely optimized to 'a' with FTZ/DAZ enabled. Although, there's admittedly a small chance of problems, since a following FP operation would normalize it, but here be dragons.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div><blockquote type="cite"><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none">Are there any other facets to this problem that I've overlooked?</div></blockquote><div><br></div>For AMDGPU we need to split -denormal-fp-math into per-FP type flags (and the corresponding IR attribute). The denorm mode register has separate fields for f32, and f64+f16. The default for each of these is different depending on the subtarget/language combination. Mostly we want f64+f16 to always be on, and only change the f32 mode. The current naming implies changing all of the modes.</div><div><br></div><div>The different sign of 0 modes as exist now aren’t available. There are however separate flags for enabling flushing on input and output. This isn’t particular important, and currently we just set both bits at the same time but it might be something to think about if this is being expanded.<br></div></div></blockquote><div><br></div><div>At the command-line level, I don't see a lot of value in separating the two flags. <span style="color:rgb(0,0,0);font-family:-webkit-standard;font-size:medium">At the Function/Loop/Block/Instruction level, separating the two would be more useful though. E.g. normalizing input/output; or sacrificing accuracy to speed up a hot loop. </span></div></div></div></div></div></blockquote><div><br></div><div>EDIT: 'accuracy' should be 'precision'. </div></div></div>