<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 05/10/2017 06:57 PM, Kaylor, Andrew
      wrote:<br>
    </div>
    <blockquote
cite="mid:0983E6C011D2DC4188F8761B533492DE57765D81@ORSMSX115.amr.corp.intel.com"
      type="cite">
      <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;}
@font-face
        {font-family:Consolas;
        panose-1:2 11 6 9 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;
        color:black;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:#0563C1;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:#954F72;
        text-decoration:underline;}
pre
        {mso-style-priority:99;
        mso-style-link:"HTML Preformatted Char";
        margin:0in;
        margin-bottom:.0001pt;
        font-size:10.0pt;
        font-family:"Courier New";
        color:black;}
span.EmailStyle17
        {mso-style-type:personal;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
span.HTMLPreformattedChar
        {mso-style-name:"HTML Preformatted Char";
        mso-style-priority:99;
        mso-style-link:"HTML Preformatted";
        font-family:"Consolas",serif;
        color:black;}
span.EmailStyle20
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:#1F497D;}
.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;}
--></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]-->
      <div class="WordSection1">
        <p class="MsoNormal"><span style="color:#1F497D">>Unless you
            want to assume that the frontend knows about all functions
            that backend
            <o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D">>knows
            about, which I don't think we do, I think this will
            essentially mean adding nobuiltin<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D">>to all
            calls. This is what we do if you compile using Clang with
            -fno-builtin or
            <o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D">>-ffreestanding.
            This will work, although it seems better to have a dedicated
            attribute for this.<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D">>
            no_fp_opts, no_fp_builtin or whatever.<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">I considered
            the idea of an FP-specific attribute anyway, because
            eventually I think I’ll want to do things with these calls
            that nobuiltins really should be disallowing.  It hadn’t
            occurred to me that the front end doesn’t know which calls
            we might be tinkering with.  I guess I was assuming that
            we’d add something to the front end to recognize the FP
            library calls, but I can understand why we might want to not
            do that.</span></p>
      </div>
    </blockquote>
    <br>
    Yea, I don't think we want that coupling. We obviously do know the
    standard C ones, but the backend can recognize all sorts of things.<br>
    <br>
    <blockquote
cite="mid:0983E6C011D2DC4188F8761B533492DE57765D81@ORSMSX115.amr.corp.intel.com"
      type="cite">
      <div class="WordSection1">
        <p class="MsoNormal"><span style="color:#1F497D"><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">Other than
            that, will this approach solve my problem?</span></p>
      </div>
    </blockquote>
    <br>
    Yes. I believe that it will.<br>
    <br>
    <blockquote
cite="mid:0983E6C011D2DC4188F8761B533492DE57765D81@ORSMSX115.amr.corp.intel.com"
      type="cite">
      <div class="WordSection1">
        <p class="MsoNormal"><span style="color:#1F497D"><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">Apart from the
            existing intrinsics (which I believe the front end uses for
            builtins?) and LibFunc handling, are there other cases I
            need to be thinking about?</span></p>
      </div>
    </blockquote>
    <br>
    I think that should be everything.<br>
    <br>
     -Hal<br>
    <br>
    <blockquote
cite="mid:0983E6C011D2DC4188F8761B533492DE57765D81@ORSMSX115.amr.corp.intel.com"
      type="cite">
      <div class="WordSection1">
        <p class="MsoNormal"><span style="color:#1F497D"><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">Andy<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D"><o:p></o:p></span></p>
        <p class="MsoNormal"><a moz-do-not-send="true"
            name="_MailEndCompose"><span style="color:#1F497D"><o:p> </o:p></span></a></p>
        <div>
          <div style="border:none;border-top:solid #E1E1E1
            1.0pt;padding:3.0pt 0in 0in 0in">
            <p class="MsoNormal"><a moz-do-not-send="true"
                name="_____replyseparator"></a><b><span
                  style="color:windowtext">From:</span></b><span
                style="color:windowtext"> Hal Finkel
                [<a class="moz-txt-link-freetext" href="mailto:hfinkel@anl.gov">mailto:hfinkel@anl.gov</a>]
                <br>
                <b>Sent:</b> Wednesday, May 10, 2017 4:45 PM<br>
                <b>To:</b> Kaylor, Andrew
                <a class="moz-txt-link-rfc2396E" href="mailto:andrew.kaylor@intel.com"><andrew.kaylor@intel.com></a>; llvm-dev
                <a class="moz-txt-link-rfc2396E" href="mailto:llvm-dev@lists.llvm.org"><llvm-dev@lists.llvm.org></a><br>
                <b>Subject:</b> Re: [llvm-dev] FENV_ACCESS and floating
                point LibFunc calls<o:p></o:p></span></p>
          </div>
        </div>
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoNormal">On 05/10/2017 06:17 PM, Kaylor, Andrew via
          llvm-dev wrote:<br>
          <br>
          <span style="font-size:12.0pt"><o:p></o:p></span></p>
        <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
          <p class="MsoNormal">Hi all,<o:p></o:p></p>
          <p class="MsoNormal"> <o:p></o:p></p>
          <p class="MsoNormal">Background<o:p></o:p></p>
          <p class="MsoNormal">I’ve been working on adding the necessary
            support to LLVM for clang to be able to support the STDC
            FENV_ACCESS pragma, which basically allows users to modify
            rounding mode at runtime and depend on the value of
            floating-point status flags or to unmask floating point
            exceptions without unexpected side effects.  I’ve committed
            an initial patch (r293226) that adds constrained intrinsics
            for the basic FP operations, and I have a patch up for
            review now (<a moz-do-not-send="true"
              href="https://reviews.llvm.org/D32319">https://reviews.llvm.org/D32319</a>)
            that adds constrained versions of a number of libm-like FP
            intrinsics.<o:p></o:p></p>
          <p class="MsoNormal"> <o:p></o:p></p>
          <p class="MsoNormal">Current problem<o:p></o:p></p>
          <p class="MsoNormal">Now I’m trying to make sure I have a good
            solution for the way in which the optimizer handles
            recognized calls to libm functions (sqrt, pow, cos, sin,
            etc.).  Basically, I need to prevent all passes from making
            any modifications to these calls that would make assumptions
            about rounding mode or improperly affect the FP status flags
            (either suppressing flags that should be present or setting
            flags that should not be set).  For instance, there are
            circumstances in which the optimizer will constant fold a
            call to one of these functions if the value of the arguments
            are known at compile time, but this constant folding
            generally assumes the default rounding mode and if the
            library call would have set a status flag, I need the flag
            to be set.<o:p></o:p></p>
          <p class="MsoNormal"> <o:p></o:p></p>
          <p class="MsoNormal">Question<o:p></o:p></p>
          <p class="MsoNormal">My question is, can/should I just rely on
            the front end setting the “nobuiltin” attribute for the call
            site in any location where the FP behavior needs to be
            restricted?<o:p></o:p></p>
        </blockquote>
        <p class="MsoNormal"><span
            style="font-size:12.0pt;font-family:"Times New
            Roman",serif"><br>
            Unless you want to assume that the frontend knows about all
            functions that backend knows about, which I don't think we
            do, I think this will essentially mean adding nobuiltin to
            all calls. This is what we do if you compile using Clang
            with -fno-builtin or -ffreestanding. This will work,
            although it seems better to have a dedicated attribute for
            this. no_fp_opts, no_fp_builtin or whatever.<br>
            <br>
             -Hal<br>
            <br>
            <br>
            <o:p></o:p></span></p>
        <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
          <p class="MsoNormal"> <o:p></o:p></p>
          <p class="MsoNormal">Ideally, I would like to be able to
            conditionally enable optimizations like constant folding if
            I am able to prove that the rounding mode, though dynamic,
            is known for the callsite at compile time (the constrained
            intrinsics have a mechanism to enable this), but at the
            moment I am more concerned about correctness and would be
            willing to sacrifice optimizations to get correct behavior. 
            Long term, I was thinking that maybe I could do something
            like attach metadata to indicate rounding mode and exception
            behavior when they were known.<o:p></o:p></p>
          <p class="MsoNormal"> <o:p></o:p></p>
          <p class="MsoNormal">Is there a better way to do this?<o:p></o:p></p>
          <p class="MsoNormal"> <o:p></o:p></p>
          <p class="MsoNormal">Thanks,<o:p></o:p></p>
          <p class="MsoNormal">Andy<o:p></o:p></p>
          <p class="MsoNormal"> <o:p></o:p></p>
          <p class="MsoNormal"><span
              style="font-size:12.0pt;font-family:"Times New
              Roman",serif"><br>
              <br>
              <br>
              <o:p></o:p></span></p>
          <pre>_______________________________________________<o:p></o:p></pre>
          <pre>LLVM Developers mailing list<o:p></o:p></pre>
          <pre><a moz-do-not-send="true" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><o:p></o:p></pre>
          <pre><a moz-do-not-send="true" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><o:p></o:p></pre>
        </blockquote>
        <p class="MsoNormal"><span
            style="font-size:12.0pt;font-family:"Times New
            Roman",serif"><br>
            <br>
            <o:p></o:p></span></p>
        <pre>-- <o:p></o:p></pre>
        <pre>Hal Finkel<o:p></o:p></pre>
        <pre>Lead, Compiler Technology and Programming Languages<o:p></o:p></pre>
        <pre>Leadership Computing Facility<o:p></o:p></pre>
        <pre>Argonne National Laboratory<o:p></o:p></pre>
      </div>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
  </body>
</html>