<div dir="auto"><div>BoF in Bristol on this is a good plan. I'd certainly go to it.<br><div class="gmail_extra"><br><div class="gmail_quote">On 9 Feb 2018 16:02, "via cfe-dev" <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Send cfe-dev mailing list submissions to<br>
<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<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>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:cfe-dev-request@lists.llvm.org">cfe-dev-request@lists.llvm.org</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:cfe-dev-owner@lists.llvm.org">cfe-dev-owner@lists.llvm.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of cfe-dev digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Re: Why is #pragma STDC FENV_ACCESS not supported?<br>
(Ulrich Weigand via cfe-dev)<br>
2. Re: Emitting full clang command line into Debug Info<br>
(David Blaikie via cfe-dev)<br>
3. Re: [Release-testers] [6.0.0 Release] Release Candidate 2<br>
tagged (Michał Górny via cfe-dev)<br>
<br>
<br>
------------------------------<wbr>------------------------------<wbr>----------<br>
<br>
Message: 1<br>
Date: Fri, 9 Feb 2018 15:44:48 +0100<br>
From: Ulrich Weigand via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>><br>
To: "Kaylor, Andrew" <<a href="mailto:andrew.kaylor@intel.com">andrew.kaylor@intel.com</a>><br>
Cc: "<a href="mailto:bumblebritches57@gmail.com">bumblebritches57@gmail.com</a>" <<a href="mailto:bumblebritches57@gmail.com">bumblebritches57@gmail.com</a>>,<br>
"<a href="mailto:bob.huemmer@sas.com">bob.huemmer@sas.com</a>" <<a href="mailto:bob.huemmer@sas.com">bob.huemmer@sas.com</a>>, llvm-dev<br>
<<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>>, Richard Smith <<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>>,<br>
"<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>" <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>>,<br>
"<a href="mailto:kpn@neutralgood.org">kpn@neutralgood.org</a>" <<a href="mailto:kpn@neutralgood.org">kpn@neutralgood.org</a>><br>
Subject: Re: [cfe-dev] Why is #pragma STDC FENV_ACCESS not supported?<br>
Message-ID:<br>
<<a href="mailto:OFD633ADA1.0F70F775-ONC125822F.0050CB9B-C125822F.00510189@notes.na.collabserv.com">OFD633ADA1.0F70F775-<wbr>ONC125822F.0050CB9B-C125822F.<wbr>00510189@notes.na.collabserv.<wbr>com</a>><br>
<br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Oh, and other thing: Are you planning to attend the upcoming LLVM<br>
developer's meeting in Bristol? I thought it might be good idea to get all<br>
parties interested in this feature together in person, if we're at the same<br>
meeting anyway. So I was thinking of submitting a proposal for a BoF<br>
session on this topic ...<br>
<br>
<br>
Mit freundlichen Gruessen / Best Regards<br>
<br>
Ulrich Weigand<br>
<br>
--<br>
Dr. Ulrich Weigand | Phone: <a href="tel:%2B49-7031%2F16-3727" value="+497031163727">+49-7031/16-3727</a><br>
STSM, GNU/Linux compilers and toolchain<br>
IBM Deutschland Research & Development GmbH<br>
Vorsitzende des Aufsichtsrats: Martina Koederitz | Geschäftsführung: Dirk<br>
Wittkopp<br>
Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht<br>
Stuttgart, HRB 243294<br>
<br>
<br>
<br>
From: "Kaylor, Andrew" <<a href="mailto:andrew.kaylor@intel.com">andrew.kaylor@intel.com</a>><br>
To: Ulrich Weigand <<a href="mailto:Ulrich.Weigand@de.ibm.com">Ulrich.Weigand@de.ibm.com</a>>,<br>
"<a href="mailto:kpn@neutralgood.org">kpn@neutralgood.org</a>" <<a href="mailto:kpn@neutralgood.org">kpn@neutralgood.org</a>><br>
Cc: Hal Finkel <<a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a>>, Richard Smith<br>
<<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>>, "<a href="mailto:bob.huemmer@sas.com">bob.huemmer@sas.com</a>"<br>
<<a href="mailto:bob.huemmer@sas.com">bob.huemmer@sas.com</a>>, "<a href="mailto:bumblebritches57@gmail.com">bumblebritches57@gmail.com</a>"<br>
<<a href="mailto:bumblebritches57@gmail.com">bumblebritches57@gmail.com</a>>, "<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>"<br>
<<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>>, llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>><br>
Date: 09.01.2018 19:55<br>
Subject: RE: [cfe-dev] Why is #pragma STDC FENV_ACCESS not supported?<br>
<br>
<br>
<br>
I think we’re going to need to create a new mechanism to communicate strict<br>
FP modes to the backend. I think we need to avoid doing anything that will<br>
require re-inventing or duplicating all of the pattern matching that goes<br>
on in instruction selection (which is the reason we’re currently dropping<br>
that information). I’m out of my depth on this transition, but I think<br>
maybe we could handle it with some kind of attribute on the MBB.<br>
<br>
In C/C++, at least, it’s my understanding that the pragmas always apply at<br>
the scope-level (as opposed to having the possibility of being<br>
instruction-specific), and we’ve previously agreed that our implementation<br>
will really need to apply the rules across entire functions in the sense<br>
that if any part of a function uses the constrained intrinsics all FP<br>
operations in the function will need to use them (though different metadata<br>
arguments may be used in different scopes). So I think that opens our<br>
options a bit.<br>
<br>
Regarding constant folding, I think you are correct that it isn’t happening<br>
anywhere in the backends at the moment. There is some constant folding done<br>
during instruction selection, but the existing mechanism prevents that. My<br>
concern is that given LLVM’s development model, if there is nothing in<br>
place to prevent constant folding and no consensus that it shouldn’t be<br>
allowed then we should probably believe that someone will eventually do it.<br>
<br>
-Andy<br>
<br>
From: Ulrich Weigand [mailto:<a href="mailto:Ulrich.Weigand@de.ibm.com">Ulrich.Weigand@de.ibm.<wbr>com</a>]<br>
Sent: Tuesday, January 09, 2018 9:59 AM<br>
To: Kaylor, Andrew <<a href="mailto:andrew.kaylor@intel.com">andrew.kaylor@intel.com</a>>; <a href="mailto:kpn@neutralgood.org">kpn@neutralgood.org</a><br>
Cc: Hal Finkel <<a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a>>; Richard Smith <<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>>;<br>
<a href="mailto:bob.huemmer@sas.com">bob.huemmer@sas.com</a>; <a href="mailto:bumblebritches57@gmail.com">bumblebritches57@gmail.com</a>; <a href="mailto:wei.ding2@amd.com">wei.ding2@amd.com</a>;<br>
<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>; llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>><br>
Subject: Re: [cfe-dev] Why is #pragma STDC FENV_ACCESS not supported?<br>
<br>
<br>
<br>
Andrew Kaylor wrote:<br>
<br>
>In general, the current "strict FP" handling stops at instruction<br>
>selection. At the MachineIR level we don't currently have a mechanism<br>
>to prevent inappropriate optimizations based on floating point<br>
>constraints, or indeed to convey such constraints to the backend.<br>
>Implicit register use modeling may provide some restriction on some<br>
>architectures, but this is definitely lacking for X86 targets. On the<br>
>other hand, I'm not aware of any specific current problems, so in many<br>
>cases we may "get lucky" and have the correct thing happen by chance.<br>
>Obviously that's not a viable long term solution. I have a rough plan<br>
>for adding improved register modeling to the X86 backend, which should<br>
>take care of instruction scheduling issues, but we'd still need a<br>
>mechanism to prevent constant folding optimizations and such.<br>
<br>
Given that Kevin intends to target SystemZ, I'll be happy to work on the<br>
SystemZ back-end support for this feature. I agree that we should be using<br>
implicit control register dependencies, which will at least prevent moving<br>
floating-point operations across instructions that e.g. change rounding<br>
modes. However, the main property we need to model is that floating-point<br>
operations may *trap*. I guess this can be done using UnmodeledSideEffects,<br>
but I'm not quite clear on how to make this dependent on whether or not a<br>
"strict" operation is requested (without duplicating all the instruction<br>
patterns ...).<br>
<br>
Once we do use something like UnmodeledSideEffects, I think MachineIR<br>
passes should handle everything correctly; in the end, the requirements are<br>
not really different from those of other trapping instructions. B.t.w. I<br>
don't think anybody does constant folding on floating-point constants at<br>
the MachineIR level anyway ... have you seen this anywhere?<br>
<br>
<br>
Mit freundlichen Gruessen / Best Regards<br>
<br>
Ulrich Weigand<br>
<br>
--<br>
Dr. Ulrich Weigand | Phone: <a href="tel:%2B49-7031%2F16-3727" value="+497031163727">+49-7031/16-3727</a><br>
STSM, GNU/Linux compilers and toolchain<br>
IBM Deutschland Research & Development GmbH<br>
Vorsitzende des Aufsichtsrats: Martina Koederitz | Geschäftsführung: Dirk<br>
Wittkopp<br>
Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart,<br>
HRB 243294<br>
<br>
<br>
<br>
<br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.llvm.org/pipermail/cfe-dev/attachments/20180209/a5046b72/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.llvm.org/<wbr>pipermail/cfe-dev/attachments/<wbr>20180209/a5046b72/attachment-<wbr>0001.html</a>><br>
-------------- next part --------------<br>
A non-text attachment was scrubbed...<br>
Name: graycol.gif<br>
Type: image/gif<br>
Size: 105 bytes<br>
Desc: not available<br>
URL: <<a href="http://lists.llvm.org/pipermail/cfe-dev/attachments/20180209/a5046b72/attachment-0001.gif" rel="noreferrer" target="_blank">http://lists.llvm.org/<wbr>pipermail/cfe-dev/attachments/<wbr>20180209/a5046b72/attachment-<wbr>0001.gif</a>><br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Fri, 09 Feb 2018 15:39:59 +0000<br>
From: David Blaikie via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>><br>
To: Zachary Turner <<a href="mailto:zturner@google.com">zturner@google.com</a>><br>
Cc: Clang Dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>><br>
Subject: Re: [cfe-dev] Emitting full clang command line into Debug<br>
Info<br>
Message-ID:<br>
<<a href="mailto:CAENS6Es2BoS_RxM_Hqt1RaAUtR1OLF4dQ3hq0Jjbgt1FVSZHag@mail.gmail.com">CAENS6Es2BoS_RxM_<wbr>Hqt1RaAUtR1OLF4dQ3hq0Jjbgt1FVS<wbr>ZHag@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
GCC produces the full command line in its producer string, Clang doesn't.<br>
This may've come up in previous discussions/review threads, but I'm not<br>
entirely sure.<br>
<br>
There's this: <a href="https://reviews.llvm.org/D30760" rel="noreferrer" target="_blank">https://reviews.llvm.org/<wbr>D30760</a> - -grecord-gcc-switches. So<br>
there's already a "flags" field in DICompileUnit you can use, and maybe<br>
just add your condition ("if codeview") to the code in clang that<br>
conditionally populates that field.<br>
<br>
On Thu, Feb 8, 2018 at 4:00 PM Zachary Turner via cfe-dev <<br>
<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br>
<br>
> For CodeView compatibility purposes, we need to be able to emit the full<br>
> command line of the clang driver into the debug info (cc1 command line is<br>
> fine, at least for CV purposes).<br>
><br>
> rnk@ tells me that he vaguely recalls some people needing this before,<br>
> but he can't recall if there's been an actual effort to submit patches to<br>
> this effect that got blocked on something, or if people are maintaining<br>
> similar patches downstream, or none of the above / something else.<br>
><br>
> Has anyone attempted something like this before?<br>
> ______________________________<wbr>_________________<br>
> cfe-dev mailing list<br>
> <a href="mailto:cfe-dev@lists.llvm.org">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>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.llvm.org/pipermail/cfe-dev/attachments/20180209/8509dfb8/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.llvm.org/<wbr>pipermail/cfe-dev/attachments/<wbr>20180209/8509dfb8/attachment-<wbr>0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Fri, 09 Feb 2018 17:00:59 +0100<br>
From: Michał Górny via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>><br>
To: Hans Wennborg <<a href="mailto:hans@chromium.org">hans@chromium.org</a>>, Release-testers<br>
<<a href="mailto:release-testers@lists.llvm.org">release-testers@lists.llvm.<wbr>org</a>><br>
Cc: llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>>, cfe-dev<br>
<<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>>, "openmp-dev \(<a href="mailto:openmp-dev@lists.llvm.org">openmp-dev@lists.llvm.org</a>\)"<br>
<<a href="mailto:openmp-dev@lists.llvm.org">openmp-dev@lists.llvm.org</a>>, LLDB Dev <<a href="mailto:lldb-dev@lists.llvm.org">lldb-dev@lists.llvm.org</a>><br>
Subject: Re: [cfe-dev] [Release-testers] [6.0.0 Release] Release<br>
Candidate 2 tagged<br>
Message-ID: <<a href="mailto:1518192059.12338.2.camel@gentoo.org">1518192059.12338.2.camel@<wbr>gentoo.org</a>><br>
Content-Type: text/plain; charset="UTF-8"<br>
<br>
W dniu śro, 07.02.2018 o godzinie 21∶51 +0100, użytkownik Hans Wennborg<br>
via Release-testers napisał:<br>
> Dear testers,<br>
><br>
> There's been a lot of merges since rc1, and hopefully the tests are in<br>
> a better state now.<br>
><br>
> 6.0.0-rc2 was just tagged, after r324506.<br>
><br>
> Please test, let me know how it goes, and upload binaries.<br>
><br>
<br>
RC2 looks much better on Gentoo. The only remaining failures are LLDB<br>
(as usual) and compiler-rt [1]. I've pushed the ebuilds without keywords<br>
for brave users who want to play with them.<br>
<br>
[1]:<a href="https://bugs.llvm.org/show_bug.cgi?id=36065" rel="noreferrer" target="_blank">https://bugs.llvm.org/<wbr>show_bug.cgi?id=36065</a><br>
<br>
--<br>
Best regards,<br>
Michał Górny<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
______________________________<wbr>_________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org">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>
<br>
------------------------------<br>
<br>
End of cfe-dev Digest, Vol 128, Issue 28<br>
******************************<wbr>**********<br>
</blockquote></div><br></div></div></div>