[cfe-dev] FENV_ACCESS

Fri Feb 9 08:36:18 PST 2018

BoF in Bristol on this is a good plan. I'd certainly go to it.

On 9 Feb 2018 16:02, "via cfe-dev" <cfe-dev at lists.llvm.org> wrote:

Send cfe-dev mailing list submissions to
        cfe-dev at lists.llvm.org

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
        cfe-dev-request at lists.llvm.org

You can reach the person managing the list at
        cfe-dev-owner at lists.llvm.org

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 <cfe-dev at lists.llvm.org>
To: "Kaylor, Andrew" <andrew.kaylor at intel.com>
Cc: "bumblebritches57 at gmail.com" <bumblebritches57 at gmail.com>,
        "bob.huemmer at sas.com" <bob.huemmer at sas.com>, llvm-dev
        <llvm-dev at lists.llvm.org>, Richard Smith <richard at metafoo.co.uk>,
        "cfe-dev at lists.llvm.org" <cfe-dev at lists.llvm.org>,
        "kpn at neutralgood.org" <kpn at neutralgood.org>
Subject: Re: [cfe-dev] Why is #pragma STDC FENV_ACCESS not supported?
Message-ID:
        <OFD633ADA1.0F70F775-ONC125822F.0050CB9B-C125822F.
00510189 at notes.na.collabserv.com>

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: +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" <andrew.kaylor at intel.com>
To:     Ulrich Weigand <Ulrich.Weigand at de.ibm.com>,
            "kpn at neutralgood.org" <kpn at neutralgood.org>
Cc:     Hal Finkel <hfinkel at anl.gov>, Richard Smith
            <richard at metafoo.co.uk>, "bob.huemmer at sas.com"
            <bob.huemmer at sas.com>, "bumblebritches57 at gmail.com"
            <bumblebritches57 at gmail.com>, "cfe-dev at lists.llvm.org"
            <cfe-dev at lists.llvm.org>, llvm-dev <llvm-dev at lists.llvm.org>
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:Ulrich.Weigand at de.ibm.com]
Sent: Tuesday, January 09, 2018 9:59 AM
To: Kaylor, Andrew <andrew.kaylor at intel.com>; kpn at neutralgood.org
Cc: Hal Finkel <hfinkel at anl.gov>; Richard Smith <richard at metafoo.co.uk>;
bob.huemmer at sas.com; bumblebritches57 at gmail.com; wei.ding2 at amd.com;
cfe-dev at lists.llvm.org; llvm-dev <llvm-dev at lists.llvm.org>
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: +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 <cfe-dev at lists.llvm.org>
To: Zachary Turner <zturner at google.com>
Cc: Clang Dev <cfe-dev at lists.llvm.org>
Subject: Re: [cfe-dev] Emitting full clang command line into Debug
        Info
Message-ID:
        <CAENS6Es2BoS_RxM_Hqt1RaAUtR1OLF4dQ3hq0Jjbgt1FVSZHag at mail.gmail.com>
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 <
cfe-dev at lists.llvm.org> 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
> cfe-dev at lists.llvm.org
> 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 <cfe-dev at lists.llvm.org>
To: Hans Wennborg <hans at chromium.org>, Release-testers
        <release-testers at lists.llvm.org>
Cc: llvm-dev <llvm-dev at lists.llvm.org>, cfe-dev
        <cfe-dev at lists.llvm.org>, "openmp-dev \(openmp-dev at lists.llvm.org\)"
        <openmp-dev at lists.llvm.org>, LLDB Dev <lldb-dev at lists.llvm.org>
Subject: Re: [cfe-dev] [Release-testers] [6.0.0 Release] Release
        Candidate 2     tagged
Message-ID: <1518192059.12338.2.camel at gentoo.org>
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
cfe-dev at lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

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

End of cfe-dev Digest, Vol 128, Issue 28
****************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180209/ff311cd6/attachment.html>