<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">By the definitions I’m hearing, it sounds like this option also disable fusion of offset calculations into loads and stores. Ditto immediate materialization directly into instructions instead of as separate immediate move.<div class=""><br class=""></div><div class="">That doesn’t sound like what “contraction” was designed for. It sounds like you want a different knob, and it sounds like a knob LLVM rarely offers, if ever. Can you provide concrete cases where the compiler is wrong? Are those cases intractably unsolvable as performance defects?<br class=""><div class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Jul 10, 2019, at 3:14 PM, Scott Manley via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">>
I think you have a different definition of fused then. Fused is a description of how the operation is computed/rounded, not an instruction count. <br class=""><div class=""><br class=""></div><div class=""><span style="font-family: Calibri, sans-serif; font-size: 16px;" class="">"Only fuse FP ops when the result won't be affected" is what the existing comment says. So it can't be both a fused op and not a fused op if it's only meant to imply a difference in rounding. I'm just re-using the existing wording, and I agree it could be cleaned up if that's the intent of the -fp-contract option -- which I why I was asking for context.</span></div><div class=""><span style="font-family: Calibri, sans-serif; font-size: 16px;" class=""><br class=""></span></div><div class="">> For FMA, I think your example IR is correctly handled. The fast instruction flag should override the global FP option you’re providing. For the issue you are describing, this is more of a question of whether clang should be emitting the fast flag or not. </div><div class=""><span style="font-family: Calibri, sans-serif; font-size: 16px;" class=""><br class=""></span></div><div class=""><font face="Calibri, sans-serif" class=""><span style="font-size:16px" class="">I disagree. How does clang know what would ultimately form an FMA? It would have to blanket remove 'fast' from all fadds. </span></font></div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jul 10, 2019 at 4:16 PM Matt Arsenault <<a href="mailto:arsenm2@gmail.com" target="_blank" class="">arsenm2@gmail.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Jul 10, 2019, at 16:56, Scott Manley <<a href="mailto:rscottmanley@gmail.com" target="_blank" class="">rscottmanley@gmail.com</a>> wrote:</div><br class="gmail-m_4306197701785154487gmail-m_-8592497960956107562Apple-interchange-newline"><div class=""><span style="font-family:Helvetica;font-size:12px;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;float:none;display:inline" class="">At any rate, I was only offering an additional reason. Personally I think it's strange for an option to say "this will never fuse ops" and then under the covers will fuse ops, regardless of how FMAD is defined. However, my primary concern is for FMAs. They have both numeric and performance implications and I do not think it's unreasonable that off means off.</span><br class="gmail-m_4306197701785154487gmail-m_-8592497960956107562Apple-interchange-newline"></div></blockquote></div><br class=""><div class="">I think you have a different definition of fused then. Fused is a description of how the operation is computed/rounded, not an instruction count. The F in FMAD is not fused (I know this naming scheme is not great. Every other FP node besides FMA has an F prefix)</div><div class=""><br class=""></div><div class="">For FMA, I think your example IR is correctly handled. The fast instruction flag should override the global FP option you’re providing. For the issue you are describing, this is more of a question of whether clang should be emitting the fast flag or not.</div><div class=""><br class=""></div><div class="">-Matt</div></div></blockquote></div>
_______________________________________________<br class="">cfe-dev mailing list<br class=""><a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a><br class="">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev<br class=""></div></blockquote></div><br class=""></div></div></body></html>