Re: FENV_ACCESS

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Re: FENV_ACCESS

Jon Chesterfield via cfe-dev
BoF in Bristol on this is a good plan. I'd certainly go to it.

On 9 Feb 2018 16:02, "via cfe-dev" <[hidden email]> wrote:
Send cfe-dev mailing list submissions to
        [hidden email]

To subscribe or unsubscribe via the World Wide Web, visit
        http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
or, via email, send a message with subject or body 'help' to
        [hidden email]

You can reach the person managing the list at
        [hidden email]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of cfe-dev digest..."


Today's Topics:

   1. Re: Why is #pragma STDC FENV_ACCESS not supported?
      (Ulrich Weigand via cfe-dev)
   2. Re: Emitting full clang command line into Debug Info
      (David Blaikie via cfe-dev)
   3. Re: [Release-testers] [6.0.0 Release] Release Candidate 2
      tagged (Michał Górny via cfe-dev)


----------------------------------------------------------------------

Message: 1
Date: Fri, 9 Feb 2018 15:44:48 +0100
From: Ulrich Weigand via cfe-dev <[hidden email]>
To: "Kaylor, Andrew" <[hidden email]>
Cc: "[hidden email]" <[hidden email]>,
        "[hidden email]" <[hidden email]>, llvm-dev
        <[hidden email]>, Richard Smith <[hidden email]>,
        "[hidden email]" <[hidden email]>,
        "[hidden email]" <[hidden email]>
Subject: Re: [cfe-dev] Why is #pragma STDC FENV_ACCESS not supported?
Message-ID:
        <[hidden email]>

Content-Type: text/plain; charset="utf-8"

Oh, and other thing:   Are you planning to attend the upcoming LLVM
developer's meeting in Bristol?  I thought it might be good idea to get all
parties interested in this feature together in person, if we're at the same
meeting anyway.  So I was thinking of submitting a proposal for a BoF
session on this topic ...


Mit freundlichen Gruessen / Best Regards

Ulrich Weigand

--
  Dr. Ulrich Weigand | Phone: <a href="tel:%2B49-7031%2F16-3727" value="+497031163727">+49-7031/16-3727
  STSM, GNU/Linux compilers and toolchain
  IBM Deutschland Research & Development GmbH
  Vorsitzende des Aufsichtsrats: Martina Koederitz | Geschäftsführung: Dirk
Wittkopp
  Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht
Stuttgart, HRB 243294



From:   "Kaylor, Andrew" <[hidden email]>
To:     Ulrich Weigand <[hidden email]>,
            "[hidden email]" <[hidden email]>
Cc:     Hal Finkel <[hidden email]>, Richard Smith
            <[hidden email]>, "[hidden email]"
            <[hidden email]>, "[hidden email]"
            <[hidden email]>, "[hidden email]"
            <[hidden email]>, llvm-dev <[hidden email]>
Date:   09.01.2018 19:55
Subject:        RE: [cfe-dev] Why is #pragma STDC FENV_ACCESS not supported?



I think we’re going to need to create a new mechanism to communicate strict
FP modes to the backend. I think we need to avoid doing anything that will
require re-inventing or duplicating all of the pattern matching that goes
on in instruction selection (which is the reason we’re currently dropping
that information). I’m out of my depth on this transition, but I think
maybe we could handle it with some kind of attribute on the MBB.

In C/C++, at least, it’s my understanding that the pragmas always apply at
the scope-level (as opposed to having the possibility of being
instruction-specific), and we’ve previously agreed that our implementation
will really need to apply the rules across entire functions in the sense
that if any part of a function uses the constrained intrinsics all FP
operations in the function will need to use them (though different metadata
arguments may be used in different scopes). So I think that opens our
options a bit.

Regarding constant folding, I think you are correct that it isn’t happening
anywhere in the backends at the moment. There is some constant folding done
during instruction selection, but the existing mechanism prevents that. My
concern is that given LLVM’s development model, if there is nothing in
place to prevent constant folding and no consensus that it shouldn’t be
allowed then we should probably believe that someone will eventually do it.

-Andy

From: Ulrich Weigand [mailto:[hidden email]]
Sent: Tuesday, January 09, 2018 9:59 AM
To: Kaylor, Andrew <[hidden email]>; [hidden email]
Cc: Hal Finkel <[hidden email]>; Richard Smith <[hidden email]>;
[hidden email]; [hidden email]; [hidden email];
[hidden email]; llvm-dev <[hidden email]>
Subject: Re: [cfe-dev] Why is #pragma STDC FENV_ACCESS not supported?



Andrew Kaylor wrote:

>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.

Given that Kevin intends to target SystemZ, I'll be happy to work on the
SystemZ back-end support for this feature. I agree that we should be using
implicit control register dependencies, which will at least prevent moving
floating-point operations across instructions that e.g. change rounding
modes. However, the main property we need to model is that floating-point
operations may *trap*. I guess this can be done using UnmodeledSideEffects,
but I'm not quite clear on how to make this dependent on whether or not a
"strict" operation is requested (without duplicating all the instruction
patterns ...).

Once we do use something like UnmodeledSideEffects, I think MachineIR
passes should handle everything correctly; in the end, the requirements are
not really different from those of other trapping instructions. B.t.w. I
don't think anybody does constant folding on floating-point constants at
the MachineIR level anyway ... have you seen this anywhere?


Mit freundlichen Gruessen / Best Regards

Ulrich Weigand

--
Dr. Ulrich Weigand | Phone: <a href="tel:%2B49-7031%2F16-3727" value="+497031163727">+49-7031/16-3727
STSM, GNU/Linux compilers and toolchain
IBM Deutschland Research & Development GmbH
Vorsitzende des Aufsichtsrats: Martina Koederitz | Geschäftsführung: Dirk
Wittkopp
Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart,
HRB 243294





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180209/a5046b72/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180209/a5046b72/attachment-0001.gif>

------------------------------

Message: 2
Date: Fri, 09 Feb 2018 15:39:59 +0000
From: David Blaikie via cfe-dev <[hidden email]>
To: Zachary Turner <[hidden email]>
Cc: Clang Dev <[hidden email]>
Subject: Re: [cfe-dev] Emitting full clang command line into Debug
        Info
Message-ID:
        <[hidden email]>
Content-Type: text/plain; charset="utf-8"

GCC produces the full command line in its producer string, Clang doesn't.
This may've come up in previous discussions/review threads, but I'm not
entirely sure.

There's this: https://reviews.llvm.org/D30760 - -grecord-gcc-switches. So
there's already a "flags" field in DICompileUnit you can use, and maybe
just add your condition ("if codeview") to the code in clang that
conditionally populates that field.

On Thu, Feb 8, 2018 at 4:00 PM Zachary Turner via cfe-dev <
[hidden email]> wrote:

> For CodeView compatibility purposes, we need to be able to emit the full
> command line of the clang driver into the debug info (cc1 command line is
> fine, at least for CV purposes).
>
> rnk@ tells me that he vaguely recalls some people needing this before,
> but he can't recall if there's been an actual effort to submit patches to
> this effect that got blocked on something, or if people are maintaining
> similar patches downstream, or none of the above / something else.
>
> Has anyone attempted something like this before?
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180209/8509dfb8/attachment-0001.html>

------------------------------

Message: 3
Date: Fri, 09 Feb 2018 17:00:59 +0100
From: Michał Górny via cfe-dev <[hidden email]>
To: Hans Wennborg <[hidden email]>, Release-testers
        <[hidden email]>
Cc: llvm-dev <[hidden email]>, cfe-dev
        <[hidden email]>, "openmp-dev \([hidden email]\)"
        <[hidden email]>, LLDB Dev <[hidden email]>
Subject: Re: [cfe-dev] [Release-testers] [6.0.0 Release] Release
        Candidate 2     tagged
Message-ID: <[hidden email]>
Content-Type: text/plain; charset="UTF-8"

W dniu śro, 07.02.2018 o godzinie 21∶51 +0100, użytkownik Hans Wennborg
via Release-testers napisał:
> Dear testers,
>
> There's been a lot of merges since rc1, and hopefully the tests are in
> a better state now.
>
> 6.0.0-rc2 was just tagged, after r324506.
>
> Please test, let me know how it goes, and upload binaries.
>

RC2 looks much better on Gentoo. The only remaining failures are LLDB
(as usual) and compiler-rt [1]. I've pushed the ebuilds without keywords
for brave users who want to play with them.

[1]:https://bugs.llvm.org/show_bug.cgi?id=36065

--
Best regards,
Michał Górny



------------------------------

Subject: Digest Footer

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev


------------------------------

End of cfe-dev Digest, Vol 128, Issue 28
****************************************


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev