<div dir="ltr"><div dir="auto"><div><div class="gmail_extra"><div class="gmail_quote">On 8 Jan 2018 19:50, "Hal Finkel via cfe-dev" <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<blockquote class="m_5096431365501841374quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><div class="m_5096431365501841374quoted-text">
    <div class="m_5096431365501841374m_-6809584157971477114moz-cite-prefix">On 01/08/2018 07:06 PM, Richard Smith
      via llvm-dev wrote:<br>
    </div>
    <blockquote type="cite">
      
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">On 8 January 2018 at 11:15, Kaylor,
            Andrew via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span>
            wrote:<br>
            <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi
              Kevin,<br>
              <br>
              Thanks for reaching out about this, and thanks especially
              for offering to help. I've had some other priorities that
              have prevented me from making progress on this recently.<br>
              <br>
              As far as I know, there is no support at all in clang for
              handling the FENV_ACCESS pragma. I have a sample patch
              somewhere that I created to demonstrate how the front end
              would create the constrained intrinsics instead of normal
              FP operations, but correctly implementing support for the
              pragma requires more front end and language expertise than
              I possess. I believe Clark Nelson, who does have such
              expertise, has this on his long term TODO list but I don't
              know anything about the actual timeframe when the work
              will begin.<br>
            </blockquote>
            <div><br>
            </div>
            <div>If you want to work on this side of things, the place
              to start would be teaching the lexer to recognize the
              attribute and produce a suitable annotation token, then
              teaching the parser to parse the token in the places where
              the pragma can appear and to track the current FENV_ACCESS
              state. Then you'll need to find a suitable AST
              representation for the pragma (I have some ideas on this,
              feel free to ask), both for the affected compound
              statements and for the affected floating-point operations,
              build those representations when necessary, and teach the
              various AST consumers (LLVM IR generation and constant
              expression evaluation immediately spring to mind) how to
              handle them.</div>
          </div>
        </div>
      </div>
    </blockquote>
    <br></div>
    FWIW, I think it would be nice for the IRBuider to have a kind of
    "strict FP" state, kind of like how we have a "fast math" state for
    adding fast-math flags, that will cause CreateFAdd and friends to
    produce the associated intrinsics, instead of the IR instructions,
    when strictness is enabled.<br></div></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">I expect we'll need a "non-default FP environment" marker on each floating-point AST node (both on operations and on calls that could resolve to FP builtins) in order to properly handle constant expression evaluation for those things, so we will presumably have the relevant information to hand at the point of emitting an expression anyway. That said, this functionality may be useful if the IR representation needs to be different for FP operations appearing outside an FENV_ACCESS region but within a function that contains an FENV_ACCESS region (eg, using intrinsics rather than instructions).</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="m_5096431365501841374quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
     -Hal<div class="m_5096431365501841374elided-text"><br>
    <br>
    <blockquote type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div><br>
            </div>
            <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
              On the LLVM side of things there are a few significant
              holes. As you've noticed, the FP to integer conversions
              operations still need intrinsics, as do fcmp, fptrunc, and
              fpext. There are probably others that I'm overlooking. The
              FP to SI conversion has an additional wrinkle that needs
              to be worked out in that the default lowering of this
              conversion to machine instructions is not exception safe.<br>
              <br>
              In general, the current "strict FP" handling stops at
              instruction selection. At the MachineIR level we don't
              currently have a mechanism to prevent inappropriate
              optimizations based on floating point constraints, or
              indeed to convey such constraints to the backend. Implicit
              register use modeling may provide some restriction on some
              architectures, but this is definitely lacking for X86
              targets. On the other hand, I'm not aware of any specific
              current problems, so in many cases we may "get lucky" and
              have the correct thing happen by chance. Obviously that's
              not a viable long term solution. I have a rough plan for
              adding improved register modeling to the X86 backend,
              which should take care of instruction scheduling issues,
              but we'd still need a mechanism to prevent constant
              folding optimizations and such.<br>
              <br>
              As for what you could begin work on, it should be a fairly
              straight-forward task to implement the intrinsics for
              fptosi, fptoui, fcmp, fptrunc, and fpext. That would be a
              gentle introduction. Beyond that, it would be very helpful
              to have some pathfinding work done to solidify exactly
              what the remaining shortcomings are. I have a patch
              somewhere (stale by now, but I could refresh it pretty
              easily) that unconditionally converts all FP operations to
              the equivalent constrained intrinsics. You could use that
              to do testing and find out what's broken.<br>
              <br>
              Thanks,<br>
              Andy<br>
              <span><br>
                <br>
                -----Original Message-----<br>
                From: Kevin P. Neal [mailto:<a href="mailto:kpn@neutralgood.org" target="_blank">kpn@neutralgood.org</a>]<br>
                Sent: Monday, January 08, 2018 6:41 AM<br>
                To: Hal Finkel via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>><br>
                Cc: Richard Smith <<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>>;
                Kaylor, Andrew <<a href="mailto:andrew.kaylor@intel.com" target="_blank">andrew.kaylor@intel.com</a>>;
                Marcus Johnson <<a href="mailto:bumblebritches57@gmail.com" target="_blank">bumblebritches57@gmail.com</a>>;
                <a href="mailto:wei.ding2@amd.com" target="_blank">wei.ding2@amd.com</a>;
                Bob Huemmer <<a href="mailto:bob.huemmer@sas.com" target="_blank">bob.huemmer@sas.com</a>><br>
                Subject: Re: [cfe-dev] Why is #pragma STDC FENV_ACCESS
                not supported?<br>
                <br>
              </span>
              <div>
                <div class="m_5096431365501841374m_-6809584157971477114h5">On Thu, Aug 31, 2017 at 05:03:17PM
                  -0500, Hal Finkel via cfe-dev wrote:<br>
                  >    To be clear, we've had several extensive
                  discussions about this, on and<br>
                  >    off list, and Andy has started adding the
                  corresponding intrinsics into<br>
                  >    the IR. There was a presumption about a lack
                  of mixing, however, and we<br>
                  >    do need to work out how to prevent mixing the
                  native IR operations with<br>
                  >    the intrinsics (although, perhaps we just did
                  that).<br>
                  >     -Hal<br>
                  <br>
                  What's the current status of this work? My employeer
                  very much needs this work done sooner rather than
                  later, and I've been tasked with helping make it
                  happen.<br>
                  <br>
                  What, exactly, still needs to be done to complete this
                  work? I've seen some of the discussions about it, and
                  I've seen the documentation on the new llvm
                  constrained floating point intrinsics. But clang I
                  don't think supports them yet, fptosi is not on the
                  list anyway, and I'm not sure what else is needed. So
                  I'm asking, what all is needed and what can I work on
                  to move this forward?<br>
                  <br>
                  Is there any work in progress code that anyone would
                  be willing to share?<br>
                  For example, any code using the new intrinsics? Andy?<br>
                  <br>
                  <br>
                  The specific case we're running into today is that we
                  have code being reordered in ways that trigger traps
                  when handling a NaN. This code:<br>
                  <br>
                  #include <math.h><br>
                  <br>
                  int foo(double d) {<br>
                     int x = (!isnan(d) ? (int)d : 45);<br>
                     return x;<br>
                  }<br>
                  <br>
                  ... becomes this:<br>
                  <br>
                  define signext i32 @foo(double) local_unnamed_addr #0
                  !dbg !10 {<br>
                    tail call void @llvm.dbg.value(metadata double %0,
                  i64 0, metadata !15, metadata !17), !dbg !18<br>
                    %2 = tail call signext i32 @__isnan(double %0) #3,
                  !dbg !19<br>
                    %3 = icmp eq i32 %2, 0, !dbg !19<br>
                    %4 = fptosi double %0 to i32, !dbg !20<br>
                    %5 = select i1 %3, i32 %4, i32 45, !dbg !19<br>
                    tail call void @llvm.dbg.value(metadata i32 %5, i64
                  0, metadata !16, metadata !17), !dbg !21<br>
                    ret i32 %5, !dbg !22<br>
                  }<br>
                  <br>
                  So the fptosi gets moved _above_ the select and the
                  trap happens. This in code that was written to avoid a
                  trap in exactly this case.<br>
                  <br>
                  We're compiling with clang 5.0.0 "-g -O1" targeting
                  SystemZ.<br>
                  --<br>
                  Kevin P. Neal                                <a href="http://www.pobox.com/%7Ekpn/" rel="noreferrer" target="_blank">http://www.pobox.com/~kpn/</a><br>
                        'Concerns about "rights" and "ownership" of
                  domains are inappropriate.<br>
                   It is appropriate to be concerned about
                  "responsibilities" and "service"<br>
                   to the community.' -- RFC 1591, page 4: March 1994<br>
                  ______________________________<wbr>_________________<br>
                </div>
              </div>
              LLVM Developers mailing list<br>
              <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
              <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
            </blockquote>
          </div>
          <br>
        </div>
      </div>
      <br>
      <fieldset class="m_5096431365501841374m_-6809584157971477114mimeAttachmentHeader"></fieldset>
      <br>
      <pre>______________________________<wbr>_________________
LLVM Developers mailing list
<a class="m_5096431365501841374m_-6809584157971477114moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>
<a class="m_5096431365501841374m_-6809584157971477114moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a>
</pre>
    </blockquote>
    <br>
    </div><div class="m_5096431365501841374quoted-text"><pre class="m_5096431365501841374m_-6809584157971477114moz-signature" cols="72">-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
  </div></div>

<br>______________________________<wbr>_________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-dev</a><br>
<br></blockquote></div><br></div></div></div>
</div>