[PATCH] D138109: [clang] Fix -fp-model={strict|precise} to disable -fapprox-func

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam added inline comments.



Comment at: clang/test/Driver/fp-model.c:162
+// CHECK-FASTMATH-FPM-STRICT-NOT: "-ffast-math"
+// CHECK-FASTMATH-FPM-STRICT-NOT: "-ffinite-math-only"

Shouldn't be worth adding a rule for -ffast-math and ffp-model=fast (even if it 
seems redundant)?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D138109/new/

https://reviews.llvm.org/D138109

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D137578: Fix 'unsafe-math-optimizations' flag dependencies

[Zahira Ammarguellat via Phabricator via cfe-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG91628f0616ca: The handling of 
funsafe-math-optimizations doesnt update the 
MathErrno (authored by zahiraam).

Changed prior to commit:
  https://reviews.llvm.org/D137578?vs=474515=474762#toc

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D137578/new/

https://reviews.llvm.org/D137578

Files:
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/test/CodeGenOpenCL/relaxed-fpmath.cl
  clang/test/Driver/fp-contract.c

Index: clang/test/Driver/fp-contract.c
===
--- clang/test/Driver/fp-contract.c
+++ clang/test/Driver/fp-contract.c
@@ -1,6 +1,8 @@
 // Test that -ffp-contract is set to the right value when combined with
-// the options -ffast-math and -fno-fast-math.
+// the options -ffast-math, -fno-fast-math, funsafe-math-optimizations,
+// fno-unsafe-math-optimizations.
 
+// ffast-math, fno-fast-math
 // RUN: %clang -### -ffast-math -c %s 2>&1  \
 // RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
 // CHECK-FPC-FAST: "-ffp-contract=fast"
@@ -112,3 +114,123 @@
 // RUN: %clang -### -fno-fast-math -ffast-math -ffp-contract=off \
 // RUN: -c %s 2>&1 | FileCheck --check-prefix=CHECK-FPC-OFF %s
 
+// funsafe-math-optimizations, fno-unsafe-math-optimizations
+// RUN: %clang -### -funsafe-math-optimizations -c %s 2>&1  \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -fno-unsafe-math-optimizations -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-ON %s
+
+// RUN: %clang -### -funsafe-math-optimizations -ffp-contract=on -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-ON %s
+
+// RUN: %clang -### -funsafe-math-optimizations -ffp-contract=off -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-OFF %s
+
+// RUN: %clang -### -funsafe-math-optimizations -ffp-contract=fast -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -ffp-contract=fast -funsafe-math-optimizations -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+// RUN: %clang -### -ffp-contract=on -funsafe-math-optimizations -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+// RUN: %clang -### -ffp-contract=off -funsafe-math-optimizations -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -ffp-contract=fast -fno-unsafe-math-optimizations -c \
+// RUN: %s 2>&1 | FileCheck --check-prefix=CHECK-FPC-FAST %s
+// RUN: %clang -### -ffp-contract=on -fno-unsafe-math-optimizations -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-ON %s
+// RUN: %clang -### -ffp-contract=off -fno-unsafe-math-optimizations -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-OFF %s
+
+// RUN: %clang -### -funsafe-math-optimizations -ffp-contract=fast \
+// RUN: -ffp-contract=on -c %s 2>&1 | FileCheck --check-prefix=CHECK-FPC-ON %s
+
+// RUN: %clang -### -funsafe-math-optimizations -ffp-contract=on \
+// RUN: -ffp-contract=off -c %s 2>&1 | FileCheck --check-prefix=CHECK-FPC-OFF %s
+
+// RUN: %clang -### -funsafe-math-optimizations -ffp-contract=on \
+// RUN: -ffp-contract=fast -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -funsafe-math-optimizations -ffp-contract=off \
+// RUN: -ffp-contract=on -c %s 2>&1 | FileCheck --check-prefix=CHECK-FPC-ON %s
+
+// RUN: %clang -### -funsafe-math-optimizations -ffp-contract=off \
+// RUN: -ffp-contract=fast \
+// RUN: -c %s 2>&1 | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -funsafe-math-optimizations -ffp-contract=on \
+// RUN: -fno-unsafe-math-optimizations -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-ON %s
+
+// RUN: %clang -### -funsafe-math-optimizations -ffp-contract=off \
+// RUN: -fno-unsafe-math-optimizations -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-OFF %s
+
+// RUN: %clang -### -funsafe-math-optimizations -ffp-contract=fast \
+// RUN: -fno-unsafe-math-optimizations -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -funsafe-math-optimizations -fno-unsafe-math-optimizations \
+// RUN: -c %s 2>&1 | FileCheck --check-prefix=CHECK-FPC-ON %s
+
+// RUN: %clang -### -fno-unsafe-math-optimizations -funsafe-math-optimizations \
+// RUN: -c %s 2>&1 | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -fno-unsafe-math-optimizations -ffp-contract=on -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-ON %s
+
+// RUN: %clang -### -fno-unsafe-math-optimizations -ffp-contract=off -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-OFF %s
+
+// RUN: %clang -### -fno-unsafe-math-optimizations -ffp-contract=fast -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// 

[PATCH] D137107: Allow MS extension: support of constexpr with __declspec(dllimport).

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam added a comment.

In D137107#3906766 , @rnk wrote:

> In D137107#3905443 , @zahiraam 
> wrote:
>
>>   extern int __declspec(dllimport) next(int n);
>>   int main () {
>> extern int _declspec(dllimport) val;
>> constexpr int& val_ref = val;
>> int i = next(val_ref);
>> return i;
>>   } 
>>
>> @rnk Shouldn't this run?
>
> Yes, I agree, this is a bug. Clang should compile this and reference 
> `__imp_next` here. However, Clang should continue producing errors when a 
> dllimport symbol is used to initialize a constexpr global variable, which was 
> one of the other cases mentioned in the initial report.

@rnk would you mind looking at the fix I am proposing for this bug? Thanks.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D137107/new/

https://reviews.llvm.org/D137107

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D137578: Fix 'unsafe-math-optimizations' flag dependencies

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam added a comment.

In D137578#3918314 , 
@michele.scandale wrote:

> Looks good to me

@michele.scandale Now that I opened up the patch to all, it needs another stamp 
from you. Would you mind reviewing it again please? I will wait for a day 
before pushing it to give time to others to look at it.  Thanks.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D137578/new/

https://reviews.llvm.org/D137578

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D137578: Fix 'unsafe-math-optimizations' flag dependencies

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam added inline comments.



Comment at: clang/lib/Frontend/CompilerInvocation.cpp:3957
 
-  if (Arg *A = Args.getLastArg(OPT_ffp_contract)) {
-StringRef Val = A->getValue();
-if (Val == "fast")
+  if (auto *A = Args.getLastArg(OPT_ffp_contract, OPT_cl_fast_relaxed_math,
+OPT_cl_unsafe_math_optimizations)) {

michele.scandale wrote:
> If I look only at the CC1 behavior then I think this is probably the desired 
> behavior.
> 
> However from the compiler driver perspective it seems that `-ffp-contract` 
> and `-cl-*` math options don't really play well together -- in 
> `RenderFloatingPointOptions` the OpenCL related options are not considered, 
> and similarly in `RenderOpenCLOptions` the other floating point options are 
> not considered.
> 
> It's not clear to me if it is expected to mix OpenCL specific options with 
> other floating point related options -- given todays code it seems that is 
> not expected.
> For the time being it is probably better to simply keep the `ffp_contract` 
> handling as is today, and modify the code around line 3803 as follow
> ```
>   if (Opts.FastRelaxedMath || Opts.CLUnsafeMath)
> Opts.setDefaultFPContractMode(LangOptions::FPM_Fast);
> ```
> to handle `-cl-unsafe-math-optimizations` similarly to 
> `-cl-fast-relaxed-math` w.r.t. contraction behavior.
>>
It's not clear to me if it is expected to mix OpenCL specific options with 
other floating point related options -- given todays code it seems that is not 
expected.
>>
Yes, it looks like the FP options and CL options are orthogonal. Even so not 
sure how OpenCL people will react to the LIT test behavioral change 
(relaxed-fpmath.cl). Thanks.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D137578/new/

https://reviews.llvm.org/D137578

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D137578: Fix 'unsafe-math-optimizations' flag dependencies

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam updated this revision to Diff 474515.
zahiraam edited the summary of this revision.
zahiraam added reviewers: andrew.w.kaylor, michele.scandale.
zahiraam set the repository for this revision to rG LLVM Github Monorepo.
zahiraam changed the visibility from "Custom Policy" to "All Users".
zahiraam added a project: clang.
zahiraam edited subscribers, added: cfe-commits; removed: andrew.w.kaylor, 
michele.scandale.
Herald added a subscriber: MaskRay.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D137578/new/

https://reviews.llvm.org/D137578

Files:
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/test/CodeGenOpenCL/relaxed-fpmath.cl
  clang/test/Driver/fp-contract.c

Index: clang/test/Driver/fp-contract.c
===
--- clang/test/Driver/fp-contract.c
+++ clang/test/Driver/fp-contract.c
@@ -1,6 +1,8 @@
 // Test that -ffp-contract is set to the right value when combined with
-// the options -ffast-math and -fno-fast-math.
+// the options -ffast-math, -fno-fast-math, funsafe-math-optimizations,
+// fno-unsafe-math-optimizations.
 
+// ffast-math, fno-fast-math
 // RUN: %clang -### -ffast-math -c %s 2>&1  \
 // RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
 // CHECK-FPC-FAST: "-ffp-contract=fast"
@@ -112,3 +114,123 @@
 // RUN: %clang -### -fno-fast-math -ffast-math -ffp-contract=off \
 // RUN: -c %s 2>&1 | FileCheck --check-prefix=CHECK-FPC-OFF %s
 
+// funsafe-math-optimizations, fno-unsafe-math-optimizations
+// RUN: %clang -### -funsafe-math-optimizations -c %s 2>&1  \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -fno-unsafe-math-optimizations -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-ON %s
+
+// RUN: %clang -### -funsafe-math-optimizations -ffp-contract=on -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-ON %s
+
+// RUN: %clang -### -funsafe-math-optimizations -ffp-contract=off -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-OFF %s
+
+// RUN: %clang -### -funsafe-math-optimizations -ffp-contract=fast -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -ffp-contract=fast -funsafe-math-optimizations -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+// RUN: %clang -### -ffp-contract=on -funsafe-math-optimizations -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+// RUN: %clang -### -ffp-contract=off -funsafe-math-optimizations -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -ffp-contract=fast -fno-unsafe-math-optimizations -c \
+// RUN: %s 2>&1 | FileCheck --check-prefix=CHECK-FPC-FAST %s
+// RUN: %clang -### -ffp-contract=on -fno-unsafe-math-optimizations -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-ON %s
+// RUN: %clang -### -ffp-contract=off -fno-unsafe-math-optimizations -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-OFF %s
+
+// RUN: %clang -### -funsafe-math-optimizations -ffp-contract=fast \
+// RUN: -ffp-contract=on -c %s 2>&1 | FileCheck --check-prefix=CHECK-FPC-ON %s
+
+// RUN: %clang -### -funsafe-math-optimizations -ffp-contract=on \
+// RUN: -ffp-contract=off -c %s 2>&1 | FileCheck --check-prefix=CHECK-FPC-OFF %s
+
+// RUN: %clang -### -funsafe-math-optimizations -ffp-contract=on \
+// RUN: -ffp-contract=fast -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -funsafe-math-optimizations -ffp-contract=off \
+// RUN: -ffp-contract=on -c %s 2>&1 | FileCheck --check-prefix=CHECK-FPC-ON %s
+
+// RUN: %clang -### -funsafe-math-optimizations -ffp-contract=off \
+// RUN: -ffp-contract=fast \
+// RUN: -c %s 2>&1 | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -funsafe-math-optimizations -ffp-contract=on \
+// RUN: -fno-unsafe-math-optimizations -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-ON %s
+
+// RUN: %clang -### -funsafe-math-optimizations -ffp-contract=off \
+// RUN: -fno-unsafe-math-optimizations -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-OFF %s
+
+// RUN: %clang -### -funsafe-math-optimizations -ffp-contract=fast \
+// RUN: -fno-unsafe-math-optimizations -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -funsafe-math-optimizations -fno-unsafe-math-optimizations \
+// RUN: -c %s 2>&1 | FileCheck --check-prefix=CHECK-FPC-ON %s
+
+// RUN: %clang -### -fno-unsafe-math-optimizations -funsafe-math-optimizations \
+// RUN: -c %s 2>&1 | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -fno-unsafe-math-optimizations -ffp-contract=on -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-ON %s
+
+// RUN: %clang -### -fno-unsafe-math-optimizations -ffp-contract=off -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-OFF %s
+
+// RUN: %clang -### 

[PATCH] D137618: [Clang] Fix behavior of -ffp-model option when overriden

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam added inline comments.



Comment at: clang/lib/Driver/ToolChains/Clang.cpp:3034
   RoundingFPMath = false;
+  FPExceptionBehavior = "";
   // If fast-math is set then set the fp-contract mode to fast.

 FPExceptionBehavior should be set here and in case options::OPT_ffp_model_EQ:



Comment at: clang/test/Driver/fp-model.c:69
 
+// RUN: %clang -### -ffp-model=fast -ffp-model=strict -c %s 2>&1 | FileCheck \
+// RUN:   --check-prefix=WARN11 %s

Add a RUN command for '-ffast-math -ffp-model=strict'. I would expect the same 
warning.
Currently (without your patch) it is generating this non-sense warning:
https://godbolt.org/z/eW679Y7G3


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D137618/new/

https://reviews.llvm.org/D137618

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D137618: [Clang] Fix behavior of -ffp-model option when overriden

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam added inline comments.



Comment at: clang/lib/Driver/ToolChains/Clang.cpp:2844
 FPContract = "fast";
+FPExceptionBehavior = "";
   } else if (Val.equals("precise")) {

I would expect the same thing should happen with -ffp-model=strict -ffast-math. 
This change is not enough to accomplish that.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D137618/new/

https://reviews.llvm.org/D137618

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D136786: Fix `unsafe-fp-math` attribute emission.

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam added a comment.

In D136786#3909043 , @zahiraam wrote:

> In D136786#3907235 , 
> @michele.scandale wrote:
>
>> In D136786#3903646 , @zahiraam 
>> wrote:
>>
>>> The changes in this patch look good to me. 
>>> @michele.scandale please make sure not to drop the driver changes that we 
>>> agreed upon in this patch. Thanks.
>>
>> I started looking at the change needed to have `unsafe-math => 
>> fp-contract=fast`.
>>
>> If I look how `-ffast-math` behave today, I see that in the driver code 
>> `-ffast-math` changes the state for `FPContract` 
>> (https://github.com/llvm/llvm-project/blob/main/clang/lib/Driver/ToolChains/Clang.cpp#L3032),
>>  but then the condition for which `-ffast-math` is forwarded to the CC1 
>> (https://github.com/llvm/llvm-project/blob/main/clang/lib/Driver/ToolChains/Clang.cpp#L3149)
>>  doesn't consider `FPContract`. This seems related to the fact that GCC does 
>> emit `__FAST_MATH__` even if the contraction mode is not fast.
>> From a quick look the `FastMath` language options is used mainly to guard 
>> some macro definition and a codegen path for complex floating point values, 
>> so this seems ok in practice.
>>
>> It seems intended that the semantic of `-ffast-math` for the CC1 is 
>> different than the semantic of `-ffast-math` for the compiler driver. Based 
>> on this, I'd expect a similar solution for `-funsafe-math-optimizations`, 
>> i.e. `-funsafe-math-optimizations => -ffp-contract=fast` only at the 
>> compiler driver level.  Does this sound good?
>>
>> If so, then the driver change for the `-funsafe-math-optimizations -> 
>> -ffp-contract=fast` could be done separately without affecting the code here.
>>
>>> I talked to @andrew.w.kaylor offline: I was thinking that it might be 
>>> necessary to make the two driver changes we talked about, before merging 
>>> this patch. But if the tests pass then I think it's okay to implement the 
>>> driver changes in an upcoming patch.
>>
>> In this patch the only suboptimal test change is the change to 
>> `clang/test/CodeGenOpenCL/relaxed-fpmath.cl`, where despite the presence of 
>> `-cl-unsafe-math-optimizations` the `"unsafe-fp-math"="true"` function 
>> attributes is not generated due to the contraction mode not being fast.
>> My understanding is that `-cl-fast-relaxed-math` should be equivalent to 
>> `-ffast-math`, and `-cl-unsafe-math-optimizations` should be equivalent to 
>> `-funsafe-math-optimizations` from the user perspective.
>>
>> From what I see the `-cl-*` options are simply forwarded as-is to the CC1, 
>> and this seems to be the desired behavior for the compiler driver w.r.t. 
>> OpenCL specific options. From what I see 
>> https://github.com/llvm/llvm-project/blob/main/clang/lib/Frontend/CompilerInvocation.cpp#L3803
>>  implements `-cl-fast-relaxed-math => -ffast-math`, but this solution 
>> doesn't play well if on the same command line you also have 
>> `-ffp-contract=VAL` as the relative order of the options is not taken into 
>> account. I'd expect a similar change for the `-cl-unsafe-math-optimizations` 
>> case.
>>
>> I can either put a `TODO` comment in the 
>> `clang/test/CodeGenOpenCL/relaxed-fpmath.cl` test, and make the changes with 
>> the driver changes for `-funsafe-math-optimizations`, otherwise the change 
>> for the `-cl-unsafe-math-optimizations` options needs to be done in this 
>> patch.
>>
>> Any preference?
>
> That's exactly what I was worried about.
> I think it would be best to create another patch to make the 
> 'funsafe-math-optimization' => FpContract=fast and make sure we have 
> coherence with 'ffast-math' and the cl options, then check in this patch once 
> that's done.

@andrew.w.kaylor , @michele.scandale I created a draft patch 
https://reviews.llvm.org/D137578 that fixes the 2 issues mentioned above. Let 
me know if the entry is visible to you (it's a private entry for now)? Thanks.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D136786/new/

https://reviews.llvm.org/D136786

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D137107: Allow MS extension: support of constexpr with __declspec(dllimport).

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam updated this revision to Diff 473693.

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D137107/new/

https://reviews.llvm.org/D137107

Files:
  clang/lib/Sema/SemaDecl.cpp
  clang/test/CodeGenCXX/PR19955.cpp
  clang/test/CodeGenCXX/dllimport.cpp
  clang/test/SemaCXX/constant-expression-cxx11.cpp
  clang/test/SemaCXX/dllimport-constexpr.cpp


Index: clang/test/SemaCXX/dllimport-constexpr.cpp
===
--- clang/test/SemaCXX/dllimport-constexpr.cpp
+++ clang/test/SemaCXX/dllimport-constexpr.cpp
@@ -60,3 +60,12 @@
   // expected-note@+1 {{requested here}}
   StaticConstexpr::g_fp();
 }
+
+extern int __declspec(dllimport) val;
+// expected-error@+1{{constexpr variable 'val_ref' must be initialized by a 
constant expression}}
+constexpr int& val_ref = val;
+
+void AssignDllImportToConst () {
+  extern int _declspec(dllimport) val;
+  constexpr int& val_ref = val;
+}
Index: clang/test/SemaCXX/constant-expression-cxx11.cpp
===
--- clang/test/SemaCXX/constant-expression-cxx11.cpp
+++ clang/test/SemaCXX/constant-expression-cxx11.cpp
@@ -1594,8 +1594,8 @@
 
   void f(int k) { // expected-note {{here}}
 int arr[k]; // expected-warning {{C99}} expected-note {{function parameter 
'k'}}
-constexpr int n = 1 +
-sizeof(arr) // expected-error {{constant expression}}
+constexpr int n = 1 + // expected-error{{constexpr variable 'n' must be 
initialized by a constant expression}}
+sizeof(arr)
 * 3;
   }
 }
Index: clang/test/CodeGenCXX/dllimport.cpp
===
--- clang/test/CodeGenCXX/dllimport.cpp
+++ clang/test/CodeGenCXX/dllimport.cpp
@@ -769,6 +769,7 @@
   USEVAR(D<42>::y);
   // MSC-DAG: @"?x@?$D@$0CK@@PR19933@@2HA" = external dllimport global i32
   // MSC-DAG: @"?y@?$D@$0CK@@PR19933@@2HA" = external dllimport global i32
+  // MSC-DAG: @"?val@@3HA" = external dllimport global i32
 }
 
 namespace PR21355 {
@@ -1026,3 +1027,11 @@
 void baz() { U u; u.foo(); } // No diagnostic.
 
 }
+
+void assigndllimport () {
+  // MSC-DAG: define dso_local void @"?assigndllimport@@YAXXZ"()
+  // MSC-DAG: %[[VAL_REF:.*]] = alloca ptr
+  // MSC-DAG-NEXT: store ptr @"?val@@3HA", ptr %[[VAL_REF]]
+  extern int _declspec(dllimport) val;
+  constexpr int& val_ref = val;
+}
Index: clang/test/CodeGenCXX/PR19955.cpp
===
--- clang/test/CodeGenCXX/PR19955.cpp
+++ clang/test/CodeGenCXX/PR19955.cpp
@@ -14,9 +14,6 @@
 // CHECK-DAG: @"?funp@@3P6AXXZA" = dso_local global ptr null
 // X64-DAG: @"?funp@@3P6AXXZEA" = dso_local global ptr null
 
-// CHECK-LABEL: @"??__Evarp@@YAXXZ"
-// CHECK-DAG: store ptr @"?var@@3HA", ptr @"?varp@@3PAHA"
-
 // X64-LABEL: @"??__Evarp@@YAXXZ"
 // X64-DAG: store ptr @"?var@@3HA", ptr @"?varp@@3PEAHEA"
 
Index: clang/lib/Sema/SemaDecl.cpp
===
--- clang/lib/Sema/SemaDecl.cpp
+++ clang/lib/Sema/SemaDecl.cpp
@@ -13890,6 +13890,9 @@
   // FIXME: Consider replacing the initializer with a ConstantExpr.
 } else if (var->isConstexpr()) {
   SourceLocation DiagLoc = var->getLocation();
+  if (IsGlobal || (!IsGlobal && Notes.size() != 0))
+Diag(DiagLoc, diag::err_constexpr_var_requires_const_init)
+<< var << Init->getSourceRange();
   // If the note doesn't add any useful information other than a source
   // location, fold it into the primary diagnostic.
   if (Notes.size() == 1 && Notes[0].second.getDiagID() ==
@@ -13897,8 +13900,6 @@
 DiagLoc = Notes[0].first;
 Notes.clear();
   }
-  Diag(DiagLoc, diag::err_constexpr_var_requires_const_init)
-  << var << Init->getSourceRange();
   for (unsigned I = 0, N = Notes.size(); I != N; ++I)
 Diag(Notes[I].first, Notes[I].second);
 } else if (GlobalStorage && var->hasAttr()) {


Index: clang/test/SemaCXX/dllimport-constexpr.cpp
===
--- clang/test/SemaCXX/dllimport-constexpr.cpp
+++ clang/test/SemaCXX/dllimport-constexpr.cpp
@@ -60,3 +60,12 @@
   // expected-note@+1 {{requested here}}
   StaticConstexpr::g_fp();
 }
+
+extern int __declspec(dllimport) val;
+// expected-error@+1{{constexpr variable 'val_ref' must be initialized by a constant expression}}
+constexpr int& val_ref = val;
+
+void AssignDllImportToConst () {
+  extern int _declspec(dllimport) val;
+  constexpr int& val_ref = val;
+}
Index: clang/test/SemaCXX/constant-expression-cxx11.cpp
===
--- clang/test/SemaCXX/constant-expression-cxx11.cpp
+++ clang/test/SemaCXX/constant-expression-cxx11.cpp
@@ -1594,8 +1594,8 @@
 
   void f(int k) { // expected-note {{here}}
 int arr[k]; // expected-warning {{C99}} expected-note {{function parameter 'k'}}
-constexpr 

[PATCH] D136786: Fix `unsafe-fp-math` attribute emission.

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam added a comment.

In D136786#3907235 , 
@michele.scandale wrote:

> In D136786#3903646 , @zahiraam 
> wrote:
>
>> The changes in this patch look good to me. 
>> @michele.scandale please make sure not to drop the driver changes that we 
>> agreed upon in this patch. Thanks.
>
> I started looking at the change needed to have `unsafe-math => 
> fp-contract=fast`.
>
> If I look how `-ffast-math` behave today, I see that in the driver code 
> `-ffast-math` changes the state for `FPContract` 
> (https://github.com/llvm/llvm-project/blob/main/clang/lib/Driver/ToolChains/Clang.cpp#L3032),
>  but then the condition for which `-ffast-math` is forwarded to the CC1 
> (https://github.com/llvm/llvm-project/blob/main/clang/lib/Driver/ToolChains/Clang.cpp#L3149)
>  doesn't consider `FPContract`. This seems related to the fact that GCC does 
> emit `__FAST_MATH__` even if the contraction mode is not fast.
> From a quick look the `FastMath` language options is used mainly to guard 
> some macro definition and a codegen path for complex floating point values, 
> so this seems ok in practice.
>
> It seems intended that the semantic of `-ffast-math` for the CC1 is different 
> than the semantic of `-ffast-math` for the compiler driver. Based on this, 
> I'd expect a similar solution for `-funsafe-math-optimizations`, i.e. 
> `-funsafe-math-optimizations => -ffp-contract=fast` only at the compiler 
> driver level.  Does this sound good?
>
> If so, then the driver change for the `-funsafe-math-optimizations -> 
> -ffp-contract=fast` could be done separately without affecting the code here.
>
>> I talked to @andrew.w.kaylor offline: I was thinking that it might be 
>> necessary to make the two driver changes we talked about, before merging 
>> this patch. But if the tests pass then I think it's okay to implement the 
>> driver changes in an upcoming patch.
>
> In this patch the only suboptimal test change is the change to 
> `clang/test/CodeGenOpenCL/relaxed-fpmath.cl`, where despite the presence of 
> `-cl-unsafe-math-optimizations` the `"unsafe-fp-math"="true"` function 
> attributes is not generated due to the contraction mode not being fast.
> My understanding is that `-cl-fast-relaxed-math` should be equivalent to 
> `-ffast-math`, and `-cl-unsafe-math-optimizations` should be equivalent to 
> `-funsafe-math-optimizations` from the user perspective.
>
> From what I see the `-cl-*` options are simply forwarded as-is to the CC1, 
> and this seems to be the desired behavior for the compiler driver w.r.t. 
> OpenCL specific options. From what I see 
> https://github.com/llvm/llvm-project/blob/main/clang/lib/Frontend/CompilerInvocation.cpp#L3803
>  implements `-cl-fast-relaxed-math => -ffast-math`, but this solution doesn't 
> play well if on the same command line you also have `-ffp-contract=VAL` as 
> the relative order of the options is not taken into account. I'd expect a 
> similar change for the `-cl-unsafe-math-optimizations` case.
>
> I can either put a `TODO` comment in the 
> `clang/test/CodeGenOpenCL/relaxed-fpmath.cl` test, and make the changes with 
> the driver changes for `-funsafe-math-optimizations`, otherwise the change 
> for the `-cl-unsafe-math-optimizations` options needs to be done in this 
> patch.
>
> Any preference?

That's exactly what I was worried about.
I think it would be best to create another patch to make the 
'funsafe-math-optimization' => FpContract=fast and make sure we have coherence 
with 'ffast-math' and the cl options, then check in this patch once that's done.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D136786/new/

https://reviews.llvm.org/D136786

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D137107: Allow MS extension: support of constexpr with __declspec(dllimport).

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam added a comment.

In D137107#3906413 , @mstorsjo wrote:

> In D137107#3905443 , @zahiraam 
> wrote:
>
>> and the same assembly (load __imp_?val) (is that why you made the comment 
>> above?). And the test case runs.
>
> Yes, pretty much - the actual value of the address of `` isn't known at 
> compile time and it cannot be produced in a way to initialize e.g. static 
> memory, which I would believe that one can expect of constexpr. The runtime 
> linker that loads DLLs can't fix it so that the address is available as a 
> statically initialized data, but to use it it does require runtime code to 
> fetch the address.
>
>> Without  constexpr the symbol generated is
>>
>> 0E  UNDEF  notype   External | __imp_?val@@3HA 
>> (__declspec(dllimport) int val)
>>
>> and the assembly generates a ‘load __imp_? Val’. Same than MSVC, but the 
>> test case fails to run.  @rnk Shouldn't this run?
>
> Can you give the full exact repro for this case, without constexpr, which you 
> say fails to run - I tried to follow the instructions but for me it seems to 
> work just fine, without constexpr.

Here is an even smaller test case.
lib.cpp:
__declspec(dllexport) int val=12;

t1.cpp:
int main () {

  extern int _declspec(dllimport) val;
  int& val_ref = val;
  return val;

}
$ clang.exe -LD lib.cpp (this will create a.lib and a.exp)
$ clang.exe t1.cpp -la
$ ./a.exe
This will result in a popup message: "The application was unable to start 
correctly ..."

With MSVC
$ cl /LD lib.cpp (this will create lib.lib and lib.dll)
$ cl t1.cpp /link lib.lib
$ t1.exe
$ echo $?
12
$


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D137107/new/

https://reviews.llvm.org/D137107

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D137107: Allow MS extension: support of constexpr with __declspec(dllimport).

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam added a comment.

In D137107#3897568 , @mstorsjo wrote:

> In D137107#3897326 , @rnk wrote:
>
>> Unless I'm missing something, I think Clang's behavior here is preferable to 
>> MSVC's. MSVC produces code which will not link. Clang turns the linker error 
>> into a compiler error, which is generally easier for the user to understand. 
>> To my knowledge, it is still true that there is no COFF relocation which can 
>> statically initialize a global variable with the address of a dllimported 
>> symbol.
>>
>> For the use case you are considering, how do things work out in practice? Is 
>> there some new import patching facility that I'm not aware of? Is the 
>> variable linked statically instead of dynamically, and then the linker 
>> relaxes the __imp references to direct references?
>
> The testcase that is shown here is peculiar in the sense that `constexpr int& 
> val_ref = val;` is located within `main()`, so it isn't really constexpr (as 
> far as I'd undestand it), but MSVC produces a load from `__imp_val`.

I think I can be convinced that generating a compiler error instead of a link 
error for the first use case is better, but about this use case (I am not sure 
I understand why you say “it isn’t a real constexpr”):

extern int __declspec(dllimport) next(int n);
int main () {

  extern int _declspec(dllimport) val;
  constexpr int& val_ref = val;
  int i = next(val_ref);
  return i;

}

With MSVC with or without constexpr will lead to the same generated symbol

012  UNDEF  notype   External | __imp_?val@@3HA 
(__declspec(dllimport) int val)

and the same assembly (load __imp_?val) (is that why you made the comment 
above?). And the test case runs.

But that’s not the case for clang (without this patch).
With constexpr it’s failing with the error mentioned above.

Without  constexpr the symbol generated is

0E  UNDEF  notype   External | __imp_?val@@3HA 
(__declspec(dllimport) int val)

and the assembly generates a ‘load __imp_? Val’. Same than MSVC, but the test 
case fails to run.  @rnk Shouldn't this run?

>> I am ready to be wrong here: if things have changed and my info is stale, we 
>> should definitely adapt.
>
> I'm not aware of anything that would have changed here...
>
> For the cases where this needs to be really statically initialized, the mingw 
> pseudo relocations do fill that spot (which fakes it by initializing it very 
> early on, from a linker-generated list of spots in the binary that needs 
> patching). For non-constexpr cases in C++, Clang solves it by implicitly 
> generating a static constructor which fetches it from the dllimported 
> variable.




Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D137107/new/

https://reviews.llvm.org/D137107

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D136786: Fix `unsafe-fp-math` attribute emission.

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam added a comment.

The changes in this patch look good to me. 
I talked to @andrew.w.kaylor offline: I was thinking that it might be necessary 
to make the two driver changes we talked about, before merging this patch. But 
if the tests pass then I think it's okay to implement the driver changes in an 
upcoming patch.
@michele.scandale please make sure not to drop the driver changes that we 
agreed upon in this patch. Thanks.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D136786/new/

https://reviews.llvm.org/D136786

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D123630: Remove connection between 'ffast-math' and 'ffp-contract'.

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam added a comment.

In D123630#3899550 , @lenary wrote:

> Reverse ping. This has been accepted, what is the status of landing this?

As far as I can tell this has landed.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D123630/new/

https://reviews.llvm.org/D123630

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D137107: Allow MS extension: support of constexpr with __declspec(dllimport).

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam added a comment.

In D137107#3897326 , @rnk wrote:

> Unless I'm missing something, I think Clang's behavior here is preferable to 
> MSVC's. MSVC produces code which will not link. Clang turns the linker error 
> into a compiler error, which is generally easier for the user to understand. 
> To my knowledge, it is still true that there is no COFF relocation which can 
> statically initialize a global variable with the address of a dllimported 
> symbol.
>
> For the use case you are considering, how do things work out in practice? Is 
> there some new import patching facility that I'm not aware of? Is the 
> variable linked statically instead of dynamically, and then the linker 
> relaxes the __imp references to direct references?

I haven't used any import patch. I just used MSVC 2019 and the test compiles 
and links. Not sure how the variable is linked.
The symbols generated are:
009  UNDEF  notype   External | __imp_?next@@YAHH@Z 
(__declspec(dllimport) int __cdecl next(int))
012  UNDEF  notype   External | __imp_?val@@3HA 
(__declspec(dllimport) int val)
and this is the asm:
mainPROC
$LN3:

  sub rsp, 56 ; 0038H

; Line 5

  mov rax, QWORD PTR __imp_?val@@3HA
  mov QWORD PTR val_ref$[rsp], rax

; Line 6

  mov rax, QWORD PTR val_ref$[rsp]
  mov ecx, DWORD PTR [rax]
  callQWORD PTR __imp_?next@@YAHH@Z
  mov DWORD PTR i$[rsp], eax

; Line 8

  mov eax, DWORD PTR i$[rsp]

; Line 9

  add rsp, 56 ; 0038H
  ret 0

mainENDP


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D137107/new/

https://reviews.llvm.org/D137107

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D137107: Allow MS extension: support of constexpr with __declspec(dllimport).

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam created this revision.
zahiraam added reviewers: majnemer, rnk.
Herald added a project: All.
zahiraam requested review of this revision.
Herald added a project: clang.

Microsoft allows the support of ‘constexpr’ with ‘__declspec(dllimport) starting
from VS2017 15.u update 4. See Constexpr doesn't support __declspec(dllimport)
in VS2017 15.8 - Visual Studio Feedback.

Let’s consider this example.
lib.cpp: 
__declspec(dllexport) int val=12;
__declspec(dllexport)
int next(int n)
{

  return n + 1;

}

app1.cpp: 
#include 
extern int __declspec(dllimport) next(int n);
int main () {

  extern int __declspec(dllimport) val;
  constexpr int& val_ref = val;
  int i = next(val_ref);
  std::cout << "i: " << i << std::endl;
  return i;

}

Compiling this will give the expected output. 
 $ cl /LD lib.cpp
 $ cl /EHsc app1.cpp /link lib.lib
 $ ./app1.exe
 i: 13

The Intel compiler has the same behavior than MSVC.
Clang compiles this test case with this error:
error: constexpr variable 'val_ref' must be initialized by a constant

  expression
  constexpr int& val_ref = val;
 ^ ~~~

1 error generated.

I think this should be fixed. This patch is doing that.

Now let’s look now at this example (dllimport at TU scope level):
app2.cpp: 
#include 
extern int __declspec(dllimport) next(int n);
extern int __declspec(dllimport) val;
constexpr int& val_ref = val;

int main () {

  int i = next(val_ref);
  std::cout << "i: " << i << std::endl;
  return i;

}
Compiling this will result into an unresolved symbol: 
 $ cl /EHsc app2.cpp /link lib.lib
 app2.obj : error LNK2001: unresolved external symbol "int val" (?val@@3HA)
 app2.exe : fatal error LNK1120: 1 unresolved externals

ICL and clang generate the same error.

These are the symols generated for all 3 compilers:
ICL:
003  UNDEF  notype   External | __imp_?next@@YAHH@Z 
(__declspec(dllimport) int __cdecl next(int))
004  UNDEF  notype   External | __imp_?val@@3HA 
(__declspec(dllimport) int val)
00C  SECT4  notype   External | ?val_ref@@3AEAHEA (int & 
val_ref)
00D  UNDEF  notype   External | ?val@@3HA (int val)
MSVC:
00A  UNDEF  notype   External | __imp_?next@@YAHH@Z 
(__declspec(dllimport) int __cdecl next(int))
015  SECT6  notype   Static   | ?val_ref@@3AEAHEA (int & 
val_ref)

The symbols generated by ICL seem to be what's expected. MSVC should be 
generating an "__imp_?val" symbol.

Clang with the change in this patch is generating the expected symbols:
010  UNDEF  notype   External | __imp_?val@@3HA 
(__declspec(dllimport) int val)
011  UNDEF  notype   External | __imp_?next@@YAHH@Z 
(__declspec(dllimport) int __cdecl next(int))
012  SECT5  notype   External | ?val_ref@@3AEAHEA (int & 
val_ref)
013  UNDEF  notype   External | ?val@@3HA (int val)

Fixes issue https://github.com/llvm/llvm-project/issues/53182


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D137107

Files:
  clang/lib/AST/ExprConstant.cpp
  clang/test/CodeGenCXX/PR19955.cpp
  clang/test/CodeGenCXX/dllimport.cpp
  clang/test/SemaCXX/PR19955.cpp
  clang/test/SemaCXX/dllimport-constexpr.cpp


Index: clang/test/SemaCXX/dllimport-constexpr.cpp
===
--- clang/test/SemaCXX/dllimport-constexpr.cpp
+++ clang/test/SemaCXX/dllimport-constexpr.cpp
@@ -40,7 +40,6 @@
 // constexpr initialization doesn't work for dllimport things.
 // expected-error@+1{{must be initialized by a constant expression}}
 constexpr void (*constexpr_import_func)() = _func;
-// expected-error@+1{{must be initialized by a constant expression}}
 constexpr int *constexpr_import_int = _int;
 // expected-error@+1{{must be initialized by a constant expression}}
 constexpr void (Foo::*constexpr_memptr)() = ::imported_method;
Index: clang/test/SemaCXX/PR19955.cpp
===
--- clang/test/SemaCXX/PR19955.cpp
+++ clang/test/SemaCXX/PR19955.cpp
@@ -2,7 +2,7 @@
 // RUN: %clang_cc1 -triple i686-mingw32 -verify -std=c++11 %s
 
 extern int __attribute__((dllimport)) var;
-constexpr int *varp =  // expected-error {{must be initialized by a 
constant expression}}
+constexpr int *varp = 
 
 extern __attribute__((dllimport)) void fun();
 constexpr void (*funp)(void) =  // expected-error {{must be initialized 
by a constant expression}}
Index: clang/test/CodeGenCXX/dllimport.cpp
===
--- clang/test/CodeGenCXX/dllimport.cpp
+++ clang/test/CodeGenCXX/dllimport.cpp
@@ -97,9 +97,9 @@
 };
 USE(inlineStaticLocalsFunc);
 
-// The address of a dllimport global cannot be used in constant initialization.
-// M32-DAG: @"?arr@?1??initializationFunc@@YAPAHXZ@4QBQAHB" = internal global 
[1 x ptr] zeroinitializer
-// GNU-DAG: @_ZZ18initializationFuncvE3arr = internal global [1 x ptr] 

[PATCH] D136786: Fix `unsafe-fp-math` attribute emission.

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam added inline comments.



Comment at: clang/lib/CodeGen/CodeGenFunction.cpp:181
+  FPFeatures.allowFPContractAcrossStatement());
 }
 

Shouldn't then this also check for FPFeatures.getFPContractMode() ?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D136786/new/

https://reviews.llvm.org/D136786

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D136786: Fix `unsafe-fp-math` attribute emission.

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam added a comment.

In D136786#3896708 , 
@michele.scandale wrote:

> In D136786#3896341 , @zahiraam 
> wrote:
>
>>> I'm going to ignore fast-math right now, because I think the current 
>>> handling is mostly OK, and this review is about unsafe-fp-math. The 
>>> unsafe-fp-math case is a little simpler in concept, but I think we've got 
>>> more problems with it.
>>>
>>> Another fundamental principle I'd like to declare here is that 
>>> LangOpts.UnsafeFPMath, TargetOptions.UnsafeFPMath, and the "unsafe-fp-math" 
>>> function attribute should all mean exactly the same thing. The function 
>>> attribute has a different scope, so it might not always have the same value 
>>> as the other two, but it should at least mean the same thing.
>>>
>>> My understanding is this:
>>>
>>>   unsafe-fp-math = exception_behavior(ignore) +
>>>fenv_access(off) +
>>>no_signed_zeros(on) +
>>>allow_reciprocal(on) +
>>>allow_approximate_fns(on) +
>>>allow_reassociation(on) +
>>>fp_contract(fast)
>>>
>>> The first two of those settings are the default behavior. The others can be 
>>> turned on by individual command line options. If all of those semantic 
>>> modes are in the states above, then we are in "unsafe-fp-math" mode. That's 
>>> my proposal.
>>
>> Agree. This is not currently the case.  -funsafe-math-optimizations should 
>> set the FPContract=fast the same way it's done for -ffast-math. I think it 
>> makes sense to fix this in this patch. @michele.scandale WDYT?
>
> (*) I understand that Clang has a different definition of `-ffast-math` 
> compared to the GCC one (i.e. in Clang `-ffast-math` implies 
> `-ffp-contract=fast`), and that this can be considered an indication that 
> there isn't a strong desire to be compatible with GCC. If that's the 
> generally accepted direction, I won't oppose it.

This is not new. It's already done this way in the current clang. So, it looks 
like the decision has been taken already.

> Given that we all agreed that we should be using only low level options 
> inside the compiler, I would keep changes to the compiler driver separate 
> from this IR code generation change, and the two should be completely 
> independent.

Okay.

>>> There are a couple of things we need to talk about here:
>>>
>>> 1. Currently, the Driver/ToolChains/Clang.cpp RenderFloatingPointOptions() 
>>> function is looking for !MathErrno before deciding to pass 
>>> "-funsafe-math-optimizations" to the front end, so LangOpts.UnsafeFPMath 
>>> will not be set unless math-errno support is off. However, the 
>>> RenderFloatingPointOptions() handling of -funsafe-math-optimizations does 
>>> not change the MathErrno setting. Clearly, there's a bug here one way or 
>>> the other. In GCC -funsafe-math-optimizations does not affect the math 
>>> errno handling, so I think that's the correct behavior.
>>
>> Yep!   This can be fixed in an upcoming patch. @michele.scandale Do you want 
>> to do it? If not, I can.
>
> I can prepare a patch for that, and if there is a general consensus about (*) 
> then we can have a single change that fixes the compiler driver code.




Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D136786/new/

https://reviews.llvm.org/D136786

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D136786: Fix `unsafe-fp-math` attribute emission.

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam added a comment.

In D136786#3893485 , @andrew.w.kaylor 
wrote:

> In D136786#3892177 , @zahiraam 
> wrote:
>
 I'm not following entirely, but -funsafe-math-optimizations is just a 
 subset of -ffast-math, so checking only the properties that contribute to 
 -funsafe-math-optimizations should be enough. 
  I think it is way simpler to reason in these terms than enumerating all 
 the possible scenarios.
>>
>> Exactly my point Since -funsafe-math-optimizations is a subset of 
>> -ffast-math, shouldn't it be the "minimal" option to trigger the 
>> unsafe-fp-math attribute for functions? 
>> I agree with the second part of the condition; it should be
>> updated with (LangOpts.getDefaultFPContractMode() ==  
>> LangOptions::FPModeKind::FPM_Fast ||   LangOpts.getDefaultFPContractMode() 
>> == LangOptions::FPModeKind::FPM_FastHonorPragmas) 
>> but I am still hesitant about the change you are proposing for the first 
>> part of the condition.
>> @andrew.w.kaylor Can you please weigh in on this?
>
> I talked to Zahira about this offline, and the current state is even messier 
> than I realized. I think we need to start by making sure we agree on the 
> behavior we want and then figure out how to get there. There are some messy 
> complications in the different ways things are handled in the driver, the 
> front end, and the backend. There are more overlapping settings than I would 
> like, but I guess it's best to look for the best way we can incrementally 
> improve that situation.
>
> As a first principle, I'd like to clarify a "big picture" item that I was 
> trying to get at in my earlier comment. I'd like to be able to reason about 
> this from the starting point of individual semantic modes. There is a set of 
> modes defined in the clang user's manual 
> (https://clang.llvm.org/docs/UsersManual.html#controlling-floating-point-behavior).
>  I think this is reasonably complete:
>
>   exception_behavior
>   fenv_access
>   rounding_mode
>   fp-contract
>   denormal_fp_math
>   denormal_fp_math_32
>   support_math_errno
>   no_honor_nans
>   no_honor_infinities
>   no_signed_zeros
>   allow_reciprocal
>   allow_approximate_fns
>   allow_reassociation
>
> These are the modes from clang's perspective. They get communicated to the 
> back end in different ways. The backend handling of this isn't nearly as 
> consistent as I'd like, but that's a different problem. I think these basic 
> modes can be thought of as language-independent and should be used as the 
> basic building blocks for reasoning about floating point behavior across all 
> LLVM-based compilers.
>
> On top of these modes, we have two concepts "fast-math" and 
> "unsafe-math-optimizations" which are essentially composites of one or more 
> of the above semantic modes. I say "essentially" because up to this point 
> there has been some fuzzy handling of that. I'd like to say they are 
> absolutely composites of the above modes, and I think we can make it so, 
> starting here.
>
> If we agree that fast-math and unsafe-math-optimizations/unsafe-fp-math are 
> composites of some of the other modes, then we can apply a symmetry property 
> that I think will be helpful in the problem we're trying to solve here and 
> will lead to better reasoning about these settings in the future.
>
> I am proposing that passing "-ffast-math" should have *exactly* the same 
> effects as passing all of the individual command line options that are 
> implied by -ffast-math. Likewise, passing "-funsafe-math-optimizations" 
> should have *exactly* the same effects as passing all of the individual 
> options that are implied by -funsafe-math-optimizations. And, of course, any 
> combination of options that turn various states on and off can be strung 
> together and we can just evaluate the final state those options leave us in 
> to see if we are in the "fast-math" state or the "unsafe-fp-math" state.

Strongly agree.

> I'm going to ignore fast-math right now, because I think the current handling 
> is mostly OK, and this review is about unsafe-fp-math. The unsafe-fp-math 
> case is a little simpler in concept, but I think we've got more problems with 
> it.
>
> Another fundamental principle I'd like to declare here is that 
> LangOpts.UnsafeFPMath, TargetOptions.UnsafeFPMath, and the "unsafe-fp-math" 
> function attribute should all mean exactly the same thing. The function 
> attribute has a different scope, so it might not always have the same value 
> as the other two, but it should at least mean the same thing.
>
> My understanding is this:
>
>   unsafe-fp-math = exception_behavior(ignore) +
>fenv_access(off) +
>no_signed_zeros(on) +
>allow_reciprocal(on) +
>allow_approximate_fns(on) +
>allow_reassociation(on) +
>fp_contract(fast)
>
> The 

[PATCH] D136786: Fix `unsafe-fp-math` attribute emission.

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam added a comment.

>> I'm not following entirely, but -funsafe-math-optimizations is just a subset 
>> of -ffast-math, so checking only the properties that contribute to 
>> -funsafe-math-optimizations should be enough. 
>>  I think it is way simpler to reason in these terms than enumerating all the 
>> possible scenarios.

Exactly my point Since -funsafe-math-optimizations is a subset of -ffast-math, 
shouldn't it be the "minimal" option to trigger the unsafe-fp-math attribute 
for functions? 
I agree with the second part of the condition; it should be
updated with (LangOpts.getDefaultFPContractMode() ==  
LangOptions::FPModeKind::FPM_Fast ||   LangOpts.getDefaultFPContractMode() == 
LangOptions::FPModeKind::FPM_FastHonorPragmas) 
but I am still hesitant about the change you are proposing for the first part 
of the condition.
@andrew.w.kaylor Can you please weigh in on this?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D136786/new/

https://reviews.llvm.org/D136786

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D136786: Fix `unsafe-fp-math` attribute emission.

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam added inline comments.



Comment at: clang/lib/CodeGen/CGCall.cpp:1865
   FuncAttrs.addAttribute("approx-func-fp-math", "true");
-if ((LangOpts.FastMath ||
- (!LangOpts.FastMath && LangOpts.AllowFPReassoc &&
-  LangOpts.AllowRecip && !LangOpts.FiniteMathOnly &&
-  LangOpts.NoSignedZero && LangOpts.ApproxFunc)) &&
-LangOpts.getDefaultFPContractMode() != 
LangOptions::FPModeKind::FPM_Off)
+if (LangOpts.UnsafeFPMath &&
+(LangOpts.getDefaultFPContractMode() ==

michele.scandale wrote:
> michele.scandale wrote:
> > I've found quite confusing the `(FastMath || (!FastMath && ... ))`.
> > 
> > Using directly `UnsafeFPMath` seems more compact, however it also causes to 
> > taking into account the value for `MathErrno` -- which it might be not 
> > relevant.
> > 
> > If `MathErrno` shouldn't affect this, then I would rewrite this as:
> > ```
> > if (LangOpts.AllowFPReassoc && LangOpts.AllowRecip &&
> >  LangOpts.NoSignedZero && LangOpts.ApproxFunc &&
> >  (LangOpts.getDefaultFPContractMode() ==
> >  LangOptions::FPModeKind::FPM_Fast ||
> >  LangOpts.getDefaultFPContractMode() ==
> >  LangOptions::FPModeKind::FPM_FastHonorPragmas))
> >   FuncAttrs.addAttribute("unsafe-fp-math", "true");
> > ```
> > so that only the relevant options are considered and there is no need to 
> > think about what is implied by `FastMath`.
> I do wonder if in 
> https://github.com/llvm/llvm-project/blob/main/clang/lib/Driver/ToolChains/Clang.cpp#L3089-L3091
>  is actually correct to have `!MathErrno`. In the GCC documentation of 
> `-funsafe-math-optimizations` I don't see any connection to the 
> `-fmath-errno` or `-fno-math-errno` options.
Interesting! Using on the command line 'funsafe-math-optimization' implies 
'math-errno'. But 'funsafe-math-optimizations' is triggered when this is true:
 !MathErrno && AssociativeMath && ReciprocalMath && !SignedZeros &&  
ApproxFunc && !TrappingMath

See here: 
https://github.com/llvm/llvm-project/blob/main/clang/lib/Driver/ToolChains/Clang.cpp#L3089
 



Comment at: clang/lib/CodeGen/CGCall.cpp:1865
   FuncAttrs.addAttribute("approx-func-fp-math", "true");
-if ((LangOpts.FastMath ||
- (!LangOpts.FastMath && LangOpts.AllowFPReassoc &&
-  LangOpts.AllowRecip && !LangOpts.FiniteMathOnly &&
-  LangOpts.NoSignedZero && LangOpts.ApproxFunc)) &&
-LangOpts.getDefaultFPContractMode() != 
LangOptions::FPModeKind::FPM_Off)
+if (LangOpts.UnsafeFPMath &&
+(LangOpts.getDefaultFPContractMode() ==

zahiraam wrote:
> michele.scandale wrote:
> > michele.scandale wrote:
> > > I've found quite confusing the `(FastMath || (!FastMath && ... ))`.
> > > 
> > > Using directly `UnsafeFPMath` seems more compact, however it also causes 
> > > to taking into account the value for `MathErrno` -- which it might be not 
> > > relevant.
> > > 
> > > If `MathErrno` shouldn't affect this, then I would rewrite this as:
> > > ```
> > > if (LangOpts.AllowFPReassoc && LangOpts.AllowRecip &&
> > >  LangOpts.NoSignedZero && LangOpts.ApproxFunc &&
> > >  (LangOpts.getDefaultFPContractMode() ==
> > >  LangOptions::FPModeKind::FPM_Fast ||
> > >  LangOpts.getDefaultFPContractMode() ==
> > >  LangOptions::FPModeKind::FPM_FastHonorPragmas))
> > >   FuncAttrs.addAttribute("unsafe-fp-math", "true");
> > > ```
> > > so that only the relevant options are considered and there is no need to 
> > > think about what is implied by `FastMath`.
> > I do wonder if in 
> > https://github.com/llvm/llvm-project/blob/main/clang/lib/Driver/ToolChains/Clang.cpp#L3089-L3091
> >  is actually correct to have `!MathErrno`. In the GCC documentation of 
> > `-funsafe-math-optimizations` I don't see any connection to the 
> > `-fmath-errno` or `-fno-math-errno` options.
> Interesting! Using on the command line 'funsafe-math-optimization' implies 
> 'math-errno'. But 'funsafe-math-optimizations' is triggered when this is true:
>  !MathErrno && AssociativeMath && ReciprocalMath && !SignedZeros &&  
> ApproxFunc && !TrappingMath
> 
> See here: 
> https://github.com/llvm/llvm-project/blob/main/clang/lib/Driver/ToolChains/Clang.cpp#L3089
>  
When the ‘funsafe-math-optimizations’ is used on the command line 
LangOpts.UnsafeFP is ‘0’. 
The function attribute ‘funnsafe-fp-math’ is not set. Is that what’s wanted? I 
would have thought that we want the attribute enabled for unsafe mode.

If we call 
SpecialOperations = AllowFPReassoc && NoSignedZero && AllowRecip && ApproxFunc 
&& !RoundingMath.

‘ffast-math’ = !MathErrno && FiniteMathOnly && SpecialOperations
‘funsafe-math-optimizations’ = MathErrno && !FiniteMathOnly && 
SpecialOperations 
(it's true that there is no mention of MathErrno in the GCC doc, but the 
default is fmath-errno so presumably using this option on the command line 
implies MathErrno).


The function attribute 

[PATCH] D135097: Remove redundant option '-menable-unsafe-fp-math'.

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam added inline comments.



Comment at: clang/lib/CodeGen/CGCall.cpp:1865-1869
+if ((LangOpts.FastMath ||
+ !LangOpts.FastMath && LangOpts.AllowFPReassoc && LangOpts.AllowRecip 
&&
+ !LangOpts.FiniteMathOnly && LangOpts.NoSignedZero &&
+ LangOpts.ApproxFunc) &&
+LangOpts.getDefaultFPContractMode() != 
LangOptions::FPModeKind::FPM_Off)

michele.scandale wrote:
> michele.scandale wrote:
> > zahiraam wrote:
> > > michele.scandale wrote:
> > > > If I look at the clang driver code, `-funsafe-math-optimizations` is 
> > > > specified on the CC1 command line if
> > > > ```
> > > > !MathErrno && AssociativeMath && ReciprocalMath && !SignedZeros && 
> > > > ApproxFunc && !TrappingMath
> > > > ```
> > > > is true.
> > > > This means that it shouldn't matter the value of the floating point 
> > > > contraction, or whether infs/nans are honored or not.
> > > > 
> > > > Was there another issue that this specific part of the change addresses?
> > > This is to make sure that if we are using -ffast-math or 
> > > -funsafe-math-optimization along with -ffp-contract=off, fma instructions 
> > > are not generated.  In this case the function shouldn't be marked with 
> > > the unsafe-fp-math attribute.
> > > This is to make sure that if we are using -ffast-math or 
> > > -funsafe-math-optimization along with -ffp-contract=off, fma instructions 
> > > are not generated.  In this case the function shouldn't be marked with 
> > > the unsafe-fp-math attribute.
> > 
> > If I understand correctly this is because the function attribute 
> > `unsafe-fp-math` from backends perspective allow any kind of contraction?
> > If so, shouldn't then this be valid only when the fp-contraction mode is 
> > `fast`, given that `on` means that only in-statement contraction is 
> > allowed, and clang handles that by generating `llvm.fmuladd` to lower 
> > expressions like `a * b + c` in given statement?
> > 
> > What about the `!LangOpts.FiniteMathOnly` part? I'd would think this 
> > shouldn't be checked at all as there are separate function attributes for 
> > infs and nans.
> > This is to make sure that if we are using -ffast-math or 
> > -funsafe-math-optimization along with -ffp-contract=off, fma instructions 
> > are not generated.  In this case the function shouldn't be marked with the 
> > unsafe-fp-math attribute.
> 
> 
> > This is to make sure that if we are using -ffast-math or 
> > -funsafe-math-optimization along with -ffp-contract=off, fma instructions 
> > are not generated.  In this case the function shouldn't be marked with the 
> > unsafe-fp-math attribute.
> 
> If I understand correctly this is because the function attribute 
> `unsafe-fp-math` from backends perspective allow any kind of contraction?
That's correct.

> If so, shouldn't then this be valid only when the fp-contraction mode is 
> `fast`, given that `on` means that only in-statement contraction is allowed, 
> and clang handles that by generating `llvm.fmuladd` to lower expressions like 
> `a * b + c` in given statement?
> 
> What about the `!LangOpts.FiniteMathOnly` part? I'd would think this 
> shouldn't be checked at all as there are separate function attributes for 
> infs and nans.

when ffp-contract=on is used with no safe optimizations along with it, the 
attribute unsafe-fp-math is not set but tryEmitMulAdd will return an FMulAdd. 
Please keep in mind that this logic hasn't really changed. The only thing that 
was done was to explicitly expand the operations of unsafe optimizations in the 
original condition.




Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D135097/new/

https://reviews.llvm.org/D135097

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D135097: Remove redundant option '-menable-unsafe-fp-math'.

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam added inline comments.



Comment at: clang/lib/CodeGen/CGCall.cpp:1865-1869
+if ((LangOpts.FastMath ||
+ !LangOpts.FastMath && LangOpts.AllowFPReassoc && LangOpts.AllowRecip 
&&
+ !LangOpts.FiniteMathOnly && LangOpts.NoSignedZero &&
+ LangOpts.ApproxFunc) &&
+LangOpts.getDefaultFPContractMode() != 
LangOptions::FPModeKind::FPM_Off)

michele.scandale wrote:
> If I look at the clang driver code, `-funsafe-math-optimizations` is 
> specified on the CC1 command line if
> ```
> !MathErrno && AssociativeMath && ReciprocalMath && !SignedZeros && ApproxFunc 
> && !TrappingMath
> ```
> is true.
> This means that it shouldn't matter the value of the floating point 
> contraction, or whether infs/nans are honored or not.
> 
> Was there another issue that this specific part of the change addresses?
This is to make sure that if we are using -ffast-math or 
-funsafe-math-optimization along with -ffp-contract=off, fma instructions are 
not generated.  In this case the function shouldn't be marked with the 
unsafe-fp-math attribute.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D135097/new/

https://reviews.llvm.org/D135097

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D109239: Add support for floating-option `-ffp-eval-method` and for new `pragma clang fp eval-method`

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam added a comment.

In D109239#3878422 , @ArcsinX wrote:

> It seems for x86_32 case (e.g. with -m32 in command line) there is a 
> difference between clang and GCC:
> clang: `__FLT_EVAL_METHOD__` == 0
> GCC: `__FLT_EVAL_METHOD__` == 2
>
> Example:
> https://godbolt.org/z/EbY8rPYGn
>
> I am not sure, is it a correct behavior from clang?

For 32-bit x86 targets, GCC defaults to -mfpmath=387 (no SSE). Passing 
-mfpmath=sse to GCC will use source precision. 
Clang’s 32-bit x86 targets defaults to using SSE instructions and evaluating at 
source precision. Clang doesn’t allow -mfpmath=387 
unless it’s passed along with -mno-sse which is redundant. Using -m32 (or 
-mfpmath=387) in combination with
-mno-sse will give you GCC’s default behavior. See 
https://godbolt.org/z/4d8fqzqEs


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D109239/new/

https://reviews.llvm.org/D109239

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D136176: Implement support for option 'fexcess-precision'.

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam added a comment.

@rjmccall Would you mind looking at this when you have a moment? Thanks.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D136176/new/

https://reviews.llvm.org/D136176

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D136084: Fix LIT CodeGen/Func-attr.c

[Zahira Ammarguellat via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGd0a4741392a3: Fix LIT test func-attr.c added by 
https://reviews.llvm.org/D135097. (authored by zahiraam).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D136084/new/

https://reviews.llvm.org/D136084

Files:
  clang/test/CodeGen/func-attr.c


Index: clang/test/CodeGen/func-attr.c
===
--- clang/test/CodeGen/func-attr.c
+++ clang/test/CodeGen/func-attr.c
@@ -1,12 +1,12 @@
-// RUN: %clang -c -ffast-math -emit-llvm -S -o - %s \
-// RUN: | FileCheck %s
+// RUN: %clang -c -target x86_64 -ffast-math \
+// RUN: -emit-llvm -S -o - %s | FileCheck %s
 
-// RUN: %clang -c -funsafe-math-optimizations -emit-llvm -S -o - %s \
-// RUN: | FileCheck %s
+// RUN: %clang -c -target x86_64 -funsafe-math-optimizations \
+// RUN: -emit-llvm -S -o - %s | FileCheck %s
 
 float foo(float a, float b) {
   return a+b;
 }
 
-// CHECK: define{{.*}} float @foo(float noundef %{{.*}}, float noundef 
%{{.*}}) [[FAST_ATTRS:#[0-9]+]]
+// CHECK: define{{.*}} float @foo(float noundef %{{.*}}, float noundef 
%{{.*}}){{.*}} [[FAST_ATTRS:#[0-9]+]]
 // CHECK: attributes [[FAST_ATTRS]] = { {{.*}} "approx-func-fp-math"="true" 
{{.*}} "no-signed-zeros-fp-math"="true" "no-trapping-math"="true" {{.*}} 
"unsafe-fp-math"="true"


Index: clang/test/CodeGen/func-attr.c
===
--- clang/test/CodeGen/func-attr.c
+++ clang/test/CodeGen/func-attr.c
@@ -1,12 +1,12 @@
-// RUN: %clang -c -ffast-math -emit-llvm -S -o - %s \
-// RUN: | FileCheck %s
+// RUN: %clang -c -target x86_64 -ffast-math \
+// RUN: -emit-llvm -S -o - %s | FileCheck %s
 
-// RUN: %clang -c -funsafe-math-optimizations -emit-llvm -S -o - %s \
-// RUN: | FileCheck %s
+// RUN: %clang -c -target x86_64 -funsafe-math-optimizations \
+// RUN: -emit-llvm -S -o - %s | FileCheck %s
 
 float foo(float a, float b) {
   return a+b;
 }
 
-// CHECK: define{{.*}} float @foo(float noundef %{{.*}}, float noundef %{{.*}}) [[FAST_ATTRS:#[0-9]+]]
+// CHECK: define{{.*}} float @foo(float noundef %{{.*}}, float noundef %{{.*}}){{.*}} [[FAST_ATTRS:#[0-9]+]]
 // CHECK: attributes [[FAST_ATTRS]] = { {{.*}} "approx-func-fp-math"="true" {{.*}} "no-signed-zeros-fp-math"="true" "no-trapping-math"="true" {{.*}} "unsafe-fp-math"="true"
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D136084: Fix LIT CodeGen/Func-attr.c

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam updated this revision to Diff 468236.

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D136084/new/

https://reviews.llvm.org/D136084

Files:
  clang/test/CodeGen/func-attr.c


Index: clang/test/CodeGen/func-attr.c
===
--- clang/test/CodeGen/func-attr.c
+++ clang/test/CodeGen/func-attr.c
@@ -1,12 +1,12 @@
-// RUN: %clang -c -ffast-math -emit-llvm -S -o - %s \
-// RUN: | FileCheck %s
+// RUN: %clang -c -target x86_64 -ffast-math \
+// RUN: -emit-llvm -S -o - %s | FileCheck %s
 
-// RUN: %clang -c -funsafe-math-optimizations -emit-llvm -S -o - %s \
-// RUN: | FileCheck %s
+// RUN: %clang -c -target x86_64 -funsafe-math-optimizations \
+// RUN: -emit-llvm -S -o - %s | FileCheck %s
 
 float foo(float a, float b) {
   return a+b;
 }
 
-// CHECK: define{{.*}} float @foo(float noundef %{{.*}}, float noundef 
%{{.*}}) [[FAST_ATTRS:#[0-9]+]]
+// CHECK: define{{.*}} float @foo(float noundef %{{.*}}, float noundef 
%{{.*}}){{.*}} [[FAST_ATTRS:#[0-9]+]]
 // CHECK: attributes [[FAST_ATTRS]] = { {{.*}} "approx-func-fp-math"="true" 
{{.*}} "no-signed-zeros-fp-math"="true" "no-trapping-math"="true" {{.*}} 
"unsafe-fp-math"="true"


Index: clang/test/CodeGen/func-attr.c
===
--- clang/test/CodeGen/func-attr.c
+++ clang/test/CodeGen/func-attr.c
@@ -1,12 +1,12 @@
-// RUN: %clang -c -ffast-math -emit-llvm -S -o - %s \
-// RUN: | FileCheck %s
+// RUN: %clang -c -target x86_64 -ffast-math \
+// RUN: -emit-llvm -S -o - %s | FileCheck %s
 
-// RUN: %clang -c -funsafe-math-optimizations -emit-llvm -S -o - %s \
-// RUN: | FileCheck %s
+// RUN: %clang -c -target x86_64 -funsafe-math-optimizations \
+// RUN: -emit-llvm -S -o - %s | FileCheck %s
 
 float foo(float a, float b) {
   return a+b;
 }
 
-// CHECK: define{{.*}} float @foo(float noundef %{{.*}}, float noundef %{{.*}}) [[FAST_ATTRS:#[0-9]+]]
+// CHECK: define{{.*}} float @foo(float noundef %{{.*}}, float noundef %{{.*}}){{.*}} [[FAST_ATTRS:#[0-9]+]]
 // CHECK: attributes [[FAST_ATTRS]] = { {{.*}} "approx-func-fp-math"="true" {{.*}} "no-signed-zeros-fp-math"="true" "no-trapping-math"="true" {{.*}} "unsafe-fp-math"="true"
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D136084: Fix LIT CodeGen/Func-attr.c

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam added inline comments.



Comment at: clang/test/CodeGen/func-attr.c:1
-// RUN: %clang -c -ffast-math -emit-llvm -S -o - %s \
-// RUN: | FileCheck %s
+// RUN: %clang -c -O2 -target x86_64 -ffast-math\
+// RUN: -emit-llvm -S -o - %s  | FileCheck %s

erichkeane wrote:
> It isn't really appropriate to add an opt-level to the test, and it doesn't 
> really depend on it.  I don't really understand @saugustine 's request in the 
> other thread: MOST of the clang-codegen tests aren't supposed to have 
> opt-levels added to them, and will fail because of it.
> 
> So I'm unshocked that adding '-O2' to a test would cause it to fail.  Clang 
> tests are generally NOT supposed to be run with an opt-setting.
I did notice that the there is some extra information generated before the 
attribute at the function define when Ox (x>0) is used.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D136084/new/

https://reviews.llvm.org/D136084

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D136084: Fix LIT CodeGen/Func-attr.c

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam added a comment.

@saugustine A, @jrtc27. Thanks for your comments. 
Adding '-target x86_64' is restrictive, but not sure what option to use to 
express that I want target with zero as default address. @aaron.ballman what do 
you think?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D136084/new/

https://reviews.llvm.org/D136084

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D136084: Fix LIT CodeGen/Func-attr.c

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam created this revision.
zahiraam added reviewers: jrtc27, saugustine, aaron.ballman.
Herald added a project: All.
zahiraam requested review of this revision.
Herald added a project: clang.

See details in comment https://reviews.llvm.org/D135097#3859893 and 
https://reviews.llvm.org/D135097#3859917


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D136084

Files:
  clang/test/CodeGen/func-attr.c


Index: clang/test/CodeGen/func-attr.c
===
--- clang/test/CodeGen/func-attr.c
+++ clang/test/CodeGen/func-attr.c
@@ -1,12 +1,12 @@
-// RUN: %clang -c -ffast-math -emit-llvm -S -o - %s \
-// RUN: | FileCheck %s
+// RUN: %clang -c -O2 -target x86_64 -ffast-math\
+// RUN: -emit-llvm -S -o - %s  | FileCheck %s
 
-// RUN: %clang -c -funsafe-math-optimizations -emit-llvm -S -o - %s \
-// RUN: | FileCheck %s
+// RUN: %clang -c -O2 -target x86_64 -funsafe-math-optimizations \
+// RUN: -emit-llvm -S -o - %s | FileCheck %s
 
 float foo(float a, float b) {
   return a+b;
 }
 
-// CHECK: define{{.*}} float @foo(float noundef %{{.*}}, float noundef 
%{{.*}}) [[FAST_ATTRS:#[0-9]+]]
+// CHECK: define{{.*}} float @foo(float noundef %{{.*}}, float noundef 
%{{.*}}) {{.*}} [[FAST_ATTRS:#[0-9]+]]
 // CHECK: attributes [[FAST_ATTRS]] = { {{.*}} "approx-func-fp-math"="true" 
{{.*}} "no-signed-zeros-fp-math"="true" "no-trapping-math"="true" {{.*}} 
"unsafe-fp-math"="true"


Index: clang/test/CodeGen/func-attr.c
===
--- clang/test/CodeGen/func-attr.c
+++ clang/test/CodeGen/func-attr.c
@@ -1,12 +1,12 @@
-// RUN: %clang -c -ffast-math -emit-llvm -S -o - %s \
-// RUN: | FileCheck %s
+// RUN: %clang -c -O2 -target x86_64 -ffast-math\
+// RUN: -emit-llvm -S -o - %s  | FileCheck %s
 
-// RUN: %clang -c -funsafe-math-optimizations -emit-llvm -S -o - %s \
-// RUN: | FileCheck %s
+// RUN: %clang -c -O2 -target x86_64 -funsafe-math-optimizations \
+// RUN: -emit-llvm -S -o - %s | FileCheck %s
 
 float foo(float a, float b) {
   return a+b;
 }
 
-// CHECK: define{{.*}} float @foo(float noundef %{{.*}}, float noundef %{{.*}}) [[FAST_ATTRS:#[0-9]+]]
+// CHECK: define{{.*}} float @foo(float noundef %{{.*}}, float noundef %{{.*}}) {{.*}} [[FAST_ATTRS:#[0-9]+]]
 // CHECK: attributes [[FAST_ATTRS]] = { {{.*}} "approx-func-fp-math"="true" {{.*}} "no-signed-zeros-fp-math"="true" "no-trapping-math"="true" {{.*}} "unsafe-fp-math"="true"
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D135963: Fix build issue due to https://reviews.llvm.org/rG84a9ec2ff1ee97fd7e8ed988f5e7b197aab84a7b

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam added a comment.

In D135963#3858638 , @aaron.ballman 
wrote:

> LGTM -- btw, feel free to land fixes to buildbot breaks without code review.

thanks.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D135963/new/

https://reviews.llvm.org/D135963

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D135963: Fix build issue due to https://reviews.llvm.org/rG84a9ec2ff1ee97fd7e8ed988f5e7b197aab84a7b

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam created this revision.
zahiraam added a reviewer: aaron.ballman.
Herald added a project: All.
zahiraam requested review of this revision.
Herald added a project: clang.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D135963

Files:
  clang/lib/CodeGen/CGCall.cpp


Index: clang/lib/CodeGen/CGCall.cpp
===
--- clang/lib/CodeGen/CGCall.cpp
+++ clang/lib/CodeGen/CGCall.cpp
@@ -1863,9 +1863,9 @@
 if (LangOpts.ApproxFunc)
   FuncAttrs.addAttribute("approx-func-fp-math", "true");
 if ((LangOpts.FastMath ||
- !LangOpts.FastMath && LangOpts.AllowFPReassoc && LangOpts.AllowRecip 
&&
+ (!LangOpts.FastMath && LangOpts.AllowFPReassoc && LangOpts.AllowRecip 
&&
  !LangOpts.FiniteMathOnly && LangOpts.NoSignedZero &&
- LangOpts.ApproxFunc) &&
+ LangOpts.ApproxFunc)) &&
 LangOpts.getDefaultFPContractMode() != 
LangOptions::FPModeKind::FPM_Off)
   FuncAttrs.addAttribute("unsafe-fp-math", "true");
 if (CodeGenOpts.SoftFloat)


Index: clang/lib/CodeGen/CGCall.cpp
===
--- clang/lib/CodeGen/CGCall.cpp
+++ clang/lib/CodeGen/CGCall.cpp
@@ -1863,9 +1863,9 @@
 if (LangOpts.ApproxFunc)
   FuncAttrs.addAttribute("approx-func-fp-math", "true");
 if ((LangOpts.FastMath ||
- !LangOpts.FastMath && LangOpts.AllowFPReassoc && LangOpts.AllowRecip &&
+ (!LangOpts.FastMath && LangOpts.AllowFPReassoc && LangOpts.AllowRecip &&
  !LangOpts.FiniteMathOnly && LangOpts.NoSignedZero &&
- LangOpts.ApproxFunc) &&
+ LangOpts.ApproxFunc)) &&
 LangOpts.getDefaultFPContractMode() != LangOptions::FPModeKind::FPM_Off)
   FuncAttrs.addAttribute("unsafe-fp-math", "true");
 if (CodeGenOpts.SoftFloat)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D135097: Remove redundant option '-menable-unsafe-fp-math'.

[Zahira Ammarguellat via Phabricator via cfe-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
zahiraam marked an inline comment as done.
Closed by commit rG84a9ec2ff1ee: Remove redundant option 
-menable-unsafe-fp-math. (authored by zahiraam).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D135097/new/

https://reviews.llvm.org/D135097

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Driver/Options.td
  clang/lib/CodeGen/CGCall.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/CodeGen/fp-options-to-fast-math-flags.c
  clang/test/CodeGen/func-attr.c
  clang/test/CodeGen/libcalls.c
  clang/test/CodeGenCUDA/propagate-metadata.cu
  clang/test/Driver/cl-options.c
  clang/test/Driver/fast-math.c
  clang/test/Driver/fp-model.c
  clang/test/Parser/fp-floatcontrol-syntax.cpp
  clang/unittests/Frontend/CompilerInvocationTest.cpp

Index: clang/unittests/Frontend/CompilerInvocationTest.cpp
===
--- clang/unittests/Frontend/CompilerInvocationTest.cpp
+++ clang/unittests/Frontend/CompilerInvocationTest.cpp
@@ -705,7 +705,7 @@
 //
 //   * -cl-unsafe-math-optimizations
 // * -cl-mad-enable
-// * -menable-unsafe-fp-math
+// * -funsafe-math-optimizations
 //   * -freciprocal-math
 
 TEST_F(CommandLineTest, ImpliedBoolOptionsNoFlagPresent) {
@@ -723,7 +723,8 @@
   ASSERT_THAT(GeneratedArgs,
   Not(Contains(StrEq("-cl-unsafe-math-optimizations";
   ASSERT_THAT(GeneratedArgs, Not(Contains(StrEq("-cl-mad-enable";
-  ASSERT_THAT(GeneratedArgs, Not(Contains(StrEq("-menable-unsafe-fp-math";
+  ASSERT_THAT(GeneratedArgs,
+  Not(Contains(StrEq("-funsafe-math-optimizations";
   ASSERT_THAT(GeneratedArgs, Not(Contains(StrEq("-freciprocal-math";
 }
 
@@ -745,13 +746,14 @@
   ASSERT_THAT(GeneratedArgs, Contains(StrEq("-cl-unsafe-math-optimizations")));
   // Not generated - implied by the generated root flag.
   ASSERT_THAT(GeneratedArgs, Not(Contains(StrEq("-cl-mad-enable";
-  ASSERT_THAT(GeneratedArgs, Not(Contains(StrEq("-menable-unsafe-fp-math";
+  ASSERT_THAT(GeneratedArgs,
+  Not(Contains(StrEq("-funsafe-math-optimizations";
   ASSERT_THAT(GeneratedArgs, Not(Contains(StrEq("-freciprocal-math";
 }
 
 TEST_F(CommandLineTest, ImpliedBoolOptionsAllFlagsPresent) {
   const char *Args[] = {"-cl-unsafe-math-optimizations", "-cl-mad-enable",
-"-menable-unsafe-fp-math", "-freciprocal-math"};
+"-funsafe-math-optimizations", "-freciprocal-math"};
 
   ASSERT_TRUE(CompilerInvocation::CreateFromArgs(Invocation, Args, *Diags));
   ASSERT_TRUE(Invocation.getLangOpts()->CLUnsafeMath);
@@ -765,12 +767,13 @@
   ASSERT_THAT(GeneratedArgs, Contains(StrEq("-cl-unsafe-math-optimizations")));
   // Not generated - implied by their generated parent.
   ASSERT_THAT(GeneratedArgs, Not(Contains(StrEq("-cl-mad-enable";
-  ASSERT_THAT(GeneratedArgs, Not(Contains(StrEq("-menable-unsafe-fp-math";
+  ASSERT_THAT(GeneratedArgs,
+  Not(Contains(StrEq("-funsafe-math-optimizations";
   ASSERT_THAT(GeneratedArgs, Not(Contains(StrEq("-freciprocal-math";
 }
 
 TEST_F(CommandLineTest, ImpliedBoolOptionsImpliedFlagsPresent) {
-  const char *Args[] = {"-cl-mad-enable", "-menable-unsafe-fp-math",
+  const char *Args[] = {"-cl-mad-enable", "-funsafe-math-optimizations",
 "-freciprocal-math"};
 
   ASSERT_TRUE(CompilerInvocation::CreateFromArgs(Invocation, Args, *Diags));
@@ -785,13 +788,13 @@
   Not(Contains(StrEq("-cl-unsafe-math-optimizations";
   // Generated - explicitly provided.
   ASSERT_THAT(GeneratedArgs, Contains(StrEq("-cl-mad-enable")));
-  ASSERT_THAT(GeneratedArgs, Contains(StrEq("-menable-unsafe-fp-math")));
+  ASSERT_THAT(GeneratedArgs, Contains(StrEq("-funsafe-math-optimizations")));
   // Not generated - implied by its generated parent.
   ASSERT_THAT(GeneratedArgs, Not(Contains(StrEq("-freciprocal-math";
 }
 
 TEST_F(CommandLineTest, PresentAndNotImpliedGenerated) {
-  const char *Args[] = {"-cl-mad-enable", "-menable-unsafe-fp-math"};
+  const char *Args[] = {"-cl-mad-enable", "-funsafe-math-optimizations"};
 
   ASSERT_TRUE(CompilerInvocation::CreateFromArgs(Invocation, Args, *Diags));
 
@@ -799,7 +802,7 @@
 
   // Present options that were not implied are generated.
   ASSERT_THAT(GeneratedArgs, Contains(StrEq("-cl-mad-enable")));
-  ASSERT_THAT(GeneratedArgs, Contains(StrEq("-menable-unsafe-fp-math")));
+  ASSERT_THAT(GeneratedArgs, Contains(StrEq("-funsafe-math-optimizations")));
 }
 
 // Diagnostic option.
Index: clang/test/Parser/fp-floatcontrol-syntax.cpp
===
--- clang/test/Parser/fp-floatcontrol-syntax.cpp
+++ clang/test/Parser/fp-floatcontrol-syntax.cpp
@@ -42,7 +42,7 @@
 // RUN: %clang_cc1 -triple x86_64-linux-gnu 

[PATCH] D135097: Remove redundant option '-menable-unsafe-fp-math'.

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam marked an inline comment as done.
zahiraam added inline comments.



Comment at: clang/docs/ReleaseNotes.rst:410-412
+- The driver option ``-menable-unsafe-fp-math`` has been removed. Passing it, 
will
+result in a hard error. To enable unsafe floating-point optimizations, the 
compiler
+options ``-funsafe-math-optimizations`` and ``-ffast-math`` are used instead.

MaskRay wrote:
> aaron.ballman wrote:
> > zahiraam wrote:
> > > aaron.ballman wrote:
> > > > Because we diagnose unknown driver flags as an error 
> > > > (https://godbolt.org/z/4xjzKh4Ej) and there's no deprecation period, I 
> > > > think we should put this under the potentially breaking changes 
> > > > section. In this case, I'm specifically worried about proprietary 
> > > > projects using the flag for optimization purposes (a lot of numerical 
> > > > analysis code is behind closed doors).
> > > > 
> > > > CC @MaskRay just to make sure there's agreement (we're still trying to 
> > > > figure out what constitutes a breaking change we want to be loud about 
> > > > in terms of driver flags).
> > > > 
> > > > Assuming Fangrui doesn't disagree, once this lands, please post an 
> > > > announcement about it into https://discourse.llvm.org/c/announce/46 
> > > > with the `clang` and `potentially-breaking` tags (an example of such a 
> > > > post is: 
> > > > https://discourse.llvm.org/t/clang-16-notice-of-potentially-breaking-changes/65562/
> > > >  though you wouldn't need all that lead-in text). 
> > > @aaron.ballman would it be worth adding a diagnostic for the option we 
> > > are removing?
> > If we're going to deprecate rather than remove, sure. But I think we're 
> > okay removing, and I think the default error diagnostic behavior will be 
> > sufficient.
> Since -menable-unsafe-fp-math was only accidentally exposed in 2020 and it's 
> clear not used in the wild, placing this under "Potentially Breaking Changes" 
> seems overkill to me (lengthy entries in release notes also discourage 
> readers).
> 
> > The driver option ``-menable-unsafe-fp-math`` has been removed. Passing it, 
> > will result in a hard error. 
> 
> I think `Passing it, will result in a hard error. ` can be removed as the 
> removal clearly indicates that passing it is an error:)
> 
> > the compiler options ``-funsafe-math-optimizations`` and ``-ffast-math`` 
> > are used instead.
> 
> Use xxx or xxx instead.
@MaskRay Thanks! 
I tend to agree about the "Potentially Breaking changes". 


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D135097/new/

https://reviews.llvm.org/D135097

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D135097: Remove redundant option '-menable-unsafe-fp-math'.

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam updated this revision to Diff 467749.

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D135097/new/

https://reviews.llvm.org/D135097

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Driver/Options.td
  clang/lib/CodeGen/CGCall.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/CodeGen/fp-options-to-fast-math-flags.c
  clang/test/CodeGen/func-attr.c
  clang/test/CodeGen/libcalls.c
  clang/test/CodeGenCUDA/propagate-metadata.cu
  clang/test/Driver/cl-options.c
  clang/test/Driver/fast-math.c
  clang/test/Driver/fp-model.c
  clang/test/Parser/fp-floatcontrol-syntax.cpp
  clang/unittests/Frontend/CompilerInvocationTest.cpp

Index: clang/unittests/Frontend/CompilerInvocationTest.cpp
===
--- clang/unittests/Frontend/CompilerInvocationTest.cpp
+++ clang/unittests/Frontend/CompilerInvocationTest.cpp
@@ -705,7 +705,7 @@
 //
 //   * -cl-unsafe-math-optimizations
 // * -cl-mad-enable
-// * -menable-unsafe-fp-math
+// * -funsafe-math-optimizations
 //   * -freciprocal-math
 
 TEST_F(CommandLineTest, ImpliedBoolOptionsNoFlagPresent) {
@@ -723,7 +723,8 @@
   ASSERT_THAT(GeneratedArgs,
   Not(Contains(StrEq("-cl-unsafe-math-optimizations";
   ASSERT_THAT(GeneratedArgs, Not(Contains(StrEq("-cl-mad-enable";
-  ASSERT_THAT(GeneratedArgs, Not(Contains(StrEq("-menable-unsafe-fp-math";
+  ASSERT_THAT(GeneratedArgs,
+  Not(Contains(StrEq("-funsafe-math-optimizations";
   ASSERT_THAT(GeneratedArgs, Not(Contains(StrEq("-freciprocal-math";
 }
 
@@ -745,13 +746,14 @@
   ASSERT_THAT(GeneratedArgs, Contains(StrEq("-cl-unsafe-math-optimizations")));
   // Not generated - implied by the generated root flag.
   ASSERT_THAT(GeneratedArgs, Not(Contains(StrEq("-cl-mad-enable";
-  ASSERT_THAT(GeneratedArgs, Not(Contains(StrEq("-menable-unsafe-fp-math";
+  ASSERT_THAT(GeneratedArgs,
+  Not(Contains(StrEq("-funsafe-math-optimizations";
   ASSERT_THAT(GeneratedArgs, Not(Contains(StrEq("-freciprocal-math";
 }
 
 TEST_F(CommandLineTest, ImpliedBoolOptionsAllFlagsPresent) {
   const char *Args[] = {"-cl-unsafe-math-optimizations", "-cl-mad-enable",
-"-menable-unsafe-fp-math", "-freciprocal-math"};
+"-funsafe-math-optimizations", "-freciprocal-math"};
 
   ASSERT_TRUE(CompilerInvocation::CreateFromArgs(Invocation, Args, *Diags));
   ASSERT_TRUE(Invocation.getLangOpts()->CLUnsafeMath);
@@ -765,12 +767,13 @@
   ASSERT_THAT(GeneratedArgs, Contains(StrEq("-cl-unsafe-math-optimizations")));
   // Not generated - implied by their generated parent.
   ASSERT_THAT(GeneratedArgs, Not(Contains(StrEq("-cl-mad-enable";
-  ASSERT_THAT(GeneratedArgs, Not(Contains(StrEq("-menable-unsafe-fp-math";
+  ASSERT_THAT(GeneratedArgs,
+  Not(Contains(StrEq("-funsafe-math-optimizations";
   ASSERT_THAT(GeneratedArgs, Not(Contains(StrEq("-freciprocal-math";
 }
 
 TEST_F(CommandLineTest, ImpliedBoolOptionsImpliedFlagsPresent) {
-  const char *Args[] = {"-cl-mad-enable", "-menable-unsafe-fp-math",
+  const char *Args[] = {"-cl-mad-enable", "-funsafe-math-optimizations",
 "-freciprocal-math"};
 
   ASSERT_TRUE(CompilerInvocation::CreateFromArgs(Invocation, Args, *Diags));
@@ -785,13 +788,13 @@
   Not(Contains(StrEq("-cl-unsafe-math-optimizations";
   // Generated - explicitly provided.
   ASSERT_THAT(GeneratedArgs, Contains(StrEq("-cl-mad-enable")));
-  ASSERT_THAT(GeneratedArgs, Contains(StrEq("-menable-unsafe-fp-math")));
+  ASSERT_THAT(GeneratedArgs, Contains(StrEq("-funsafe-math-optimizations")));
   // Not generated - implied by its generated parent.
   ASSERT_THAT(GeneratedArgs, Not(Contains(StrEq("-freciprocal-math";
 }
 
 TEST_F(CommandLineTest, PresentAndNotImpliedGenerated) {
-  const char *Args[] = {"-cl-mad-enable", "-menable-unsafe-fp-math"};
+  const char *Args[] = {"-cl-mad-enable", "-funsafe-math-optimizations"};
 
   ASSERT_TRUE(CompilerInvocation::CreateFromArgs(Invocation, Args, *Diags));
 
@@ -799,7 +802,7 @@
 
   // Present options that were not implied are generated.
   ASSERT_THAT(GeneratedArgs, Contains(StrEq("-cl-mad-enable")));
-  ASSERT_THAT(GeneratedArgs, Contains(StrEq("-menable-unsafe-fp-math")));
+  ASSERT_THAT(GeneratedArgs, Contains(StrEq("-funsafe-math-optimizations")));
 }
 
 // Diagnostic option.
Index: clang/test/Parser/fp-floatcontrol-syntax.cpp
===
--- clang/test/Parser/fp-floatcontrol-syntax.cpp
+++ clang/test/Parser/fp-floatcontrol-syntax.cpp
@@ -42,7 +42,7 @@
 // RUN: %clang_cc1 -triple x86_64-linux-gnu -fdenormal-fp-math=preserve-sign,preserve-sign -fsyntax-only %s -DDEFAULT -verify
 // RUN: %clang_cc1 -triple x86_64-linux-gnu -fsyntax-only %s -ffp-contract=fast -DPRECISE -verify
 // RUN: %clang_cc1 -triple x86_64-linux-gnu -fsyntax-only %s -ffp-contract=off 

[PATCH] D135097: Remove redundant option '-menable-unsafe-fp-math'.

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam added inline comments.



Comment at: clang/docs/ReleaseNotes.rst:410-412
+- The driver option ``-menable-unsafe-fp-math`` has been removed. Passing it, 
will
+result in a hard error. To enable unsafe floating-point optimizations, the 
compiler
+options ``-funsafe-math-optimizations`` and ``-ffast-math`` are used instead.

aaron.ballman wrote:
> Because we diagnose unknown driver flags as an error 
> (https://godbolt.org/z/4xjzKh4Ej) and there's no deprecation period, I think 
> we should put this under the potentially breaking changes section. In this 
> case, I'm specifically worried about proprietary projects using the flag for 
> optimization purposes (a lot of numerical analysis code is behind closed 
> doors).
> 
> CC @MaskRay just to make sure there's agreement (we're still trying to figure 
> out what constitutes a breaking change we want to be loud about in terms of 
> driver flags).
> 
> Assuming Fangrui doesn't disagree, once this lands, please post an 
> announcement about it into https://discourse.llvm.org/c/announce/46 with the 
> `clang` and `potentially-breaking` tags (an example of such a post is: 
> https://discourse.llvm.org/t/clang-16-notice-of-potentially-breaking-changes/65562/
>  though you wouldn't need all that lead-in text). 
@aaron.ballman would it be worth adding a diagnostic for the option we are 
removing?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D135097/new/

https://reviews.llvm.org/D135097

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D135097: Remove redundant option '-menable-unsafe-fp-math'.

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam updated this revision to Diff 466474.

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D135097/new/

https://reviews.llvm.org/D135097

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Driver/Options.td
  clang/lib/CodeGen/CGCall.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/CodeGen/fp-options-to-fast-math-flags.c
  clang/test/CodeGen/func-attr.c
  clang/test/CodeGen/libcalls.c
  clang/test/CodeGenCUDA/propagate-metadata.cu
  clang/test/Driver/cl-options.c
  clang/test/Driver/fast-math.c
  clang/test/Driver/fp-model.c
  clang/test/Parser/fp-floatcontrol-syntax.cpp
  clang/unittests/Frontend/CompilerInvocationTest.cpp

Index: clang/unittests/Frontend/CompilerInvocationTest.cpp
===
--- clang/unittests/Frontend/CompilerInvocationTest.cpp
+++ clang/unittests/Frontend/CompilerInvocationTest.cpp
@@ -705,7 +705,7 @@
 //
 //   * -cl-unsafe-math-optimizations
 // * -cl-mad-enable
-// * -menable-unsafe-fp-math
+// * -funsafe-math-optimizations
 //   * -freciprocal-math
 
 TEST_F(CommandLineTest, ImpliedBoolOptionsNoFlagPresent) {
@@ -723,7 +723,8 @@
   ASSERT_THAT(GeneratedArgs,
   Not(Contains(StrEq("-cl-unsafe-math-optimizations";
   ASSERT_THAT(GeneratedArgs, Not(Contains(StrEq("-cl-mad-enable";
-  ASSERT_THAT(GeneratedArgs, Not(Contains(StrEq("-menable-unsafe-fp-math";
+  ASSERT_THAT(GeneratedArgs,
+  Not(Contains(StrEq("-funsafe-math-optimizations";
   ASSERT_THAT(GeneratedArgs, Not(Contains(StrEq("-freciprocal-math";
 }
 
@@ -745,13 +746,14 @@
   ASSERT_THAT(GeneratedArgs, Contains(StrEq("-cl-unsafe-math-optimizations")));
   // Not generated - implied by the generated root flag.
   ASSERT_THAT(GeneratedArgs, Not(Contains(StrEq("-cl-mad-enable";
-  ASSERT_THAT(GeneratedArgs, Not(Contains(StrEq("-menable-unsafe-fp-math";
+  ASSERT_THAT(GeneratedArgs,
+  Not(Contains(StrEq("-funsafe-math-optimizations";
   ASSERT_THAT(GeneratedArgs, Not(Contains(StrEq("-freciprocal-math";
 }
 
 TEST_F(CommandLineTest, ImpliedBoolOptionsAllFlagsPresent) {
   const char *Args[] = {"-cl-unsafe-math-optimizations", "-cl-mad-enable",
-"-menable-unsafe-fp-math", "-freciprocal-math"};
+"-funsafe-math-optimizations", "-freciprocal-math"};
 
   ASSERT_TRUE(CompilerInvocation::CreateFromArgs(Invocation, Args, *Diags));
   ASSERT_TRUE(Invocation.getLangOpts()->CLUnsafeMath);
@@ -765,12 +767,13 @@
   ASSERT_THAT(GeneratedArgs, Contains(StrEq("-cl-unsafe-math-optimizations")));
   // Not generated - implied by their generated parent.
   ASSERT_THAT(GeneratedArgs, Not(Contains(StrEq("-cl-mad-enable";
-  ASSERT_THAT(GeneratedArgs, Not(Contains(StrEq("-menable-unsafe-fp-math";
+  ASSERT_THAT(GeneratedArgs,
+  Not(Contains(StrEq("-funsafe-math-optimizations";
   ASSERT_THAT(GeneratedArgs, Not(Contains(StrEq("-freciprocal-math";
 }
 
 TEST_F(CommandLineTest, ImpliedBoolOptionsImpliedFlagsPresent) {
-  const char *Args[] = {"-cl-mad-enable", "-menable-unsafe-fp-math",
+  const char *Args[] = {"-cl-mad-enable", "-funsafe-math-optimizations",
 "-freciprocal-math"};
 
   ASSERT_TRUE(CompilerInvocation::CreateFromArgs(Invocation, Args, *Diags));
@@ -785,13 +788,13 @@
   Not(Contains(StrEq("-cl-unsafe-math-optimizations";
   // Generated - explicitly provided.
   ASSERT_THAT(GeneratedArgs, Contains(StrEq("-cl-mad-enable")));
-  ASSERT_THAT(GeneratedArgs, Contains(StrEq("-menable-unsafe-fp-math")));
+  ASSERT_THAT(GeneratedArgs, Contains(StrEq("-funsafe-math-optimizations")));
   // Not generated - implied by its generated parent.
   ASSERT_THAT(GeneratedArgs, Not(Contains(StrEq("-freciprocal-math";
 }
 
 TEST_F(CommandLineTest, PresentAndNotImpliedGenerated) {
-  const char *Args[] = {"-cl-mad-enable", "-menable-unsafe-fp-math"};
+  const char *Args[] = {"-cl-mad-enable", "-funsafe-math-optimizations"};
 
   ASSERT_TRUE(CompilerInvocation::CreateFromArgs(Invocation, Args, *Diags));
 
@@ -799,7 +802,7 @@
 
   // Present options that were not implied are generated.
   ASSERT_THAT(GeneratedArgs, Contains(StrEq("-cl-mad-enable")));
-  ASSERT_THAT(GeneratedArgs, Contains(StrEq("-menable-unsafe-fp-math")));
+  ASSERT_THAT(GeneratedArgs, Contains(StrEq("-funsafe-math-optimizations")));
 }
 
 // Diagnostic option.
Index: clang/test/Parser/fp-floatcontrol-syntax.cpp
===
--- clang/test/Parser/fp-floatcontrol-syntax.cpp
+++ clang/test/Parser/fp-floatcontrol-syntax.cpp
@@ -42,7 +42,7 @@
 // RUN: %clang_cc1 -triple x86_64-linux-gnu -fdenormal-fp-math=preserve-sign,preserve-sign -fsyntax-only %s -DDEFAULT -verify
 // RUN: %clang_cc1 -triple x86_64-linux-gnu -fsyntax-only %s -ffp-contract=fast -DPRECISE -verify
 // RUN: %clang_cc1 -triple x86_64-linux-gnu -fsyntax-only %s -ffp-contract=off 

[PATCH] D135097: Remove redundant option '-menable-unsafe-fp-math'.

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam added a comment.

In D135097#3840706 , @aaron.ballman 
wrote:

> I'm also okay with this direction. I took a look to see if people seemed to 
> be using this option in their build scripts (maybe we would need a louder 
> deprecation period), and it seems like most of the uses out there are in 
> forks of Clang. Once I excluded things that looked too clang-like, I spotted: 
> https://sourcegraph.com/search?q=context:global+-file:.*test.*+-file:.*clang.*+-file:Tools.cpp+-menable-unsafe-fp-math=standard
>  -- I don't have the impression we need a deprecation period for this. (Do we 
> consider this to be a potentially breaking change we need to list in the 
> release notes/announcements/clang-vendors?) The changes should have a release 
> note, regardless of what heading we put it under.

@aaron.ballman There is a chapter in the RN called "Removed Compiler Flags". 
Some text should definitely be added there. I let other people chime in for the 
"potentially breaking" in the RN or somewhere else.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D135097/new/

https://reviews.llvm.org/D135097

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D135097: Remove redundant option '-menable-unsafe-fp-math'.

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam updated this revision to Diff 465790.

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D135097/new/

https://reviews.llvm.org/D135097

Files:
  clang/include/clang/Driver/Options.td
  clang/lib/CodeGen/CGCall.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/CodeGen/fp-options-to-fast-math-flags.c
  clang/test/CodeGen/func-attr.c
  clang/test/CodeGen/libcalls.c
  clang/test/CodeGenCUDA/propagate-metadata.cu
  clang/test/Driver/cl-options.c
  clang/test/Driver/fast-math.c
  clang/test/Driver/fp-model.c
  clang/test/Parser/fp-floatcontrol-syntax.cpp
  clang/unittests/Frontend/CompilerInvocationTest.cpp

Index: clang/unittests/Frontend/CompilerInvocationTest.cpp
===
--- clang/unittests/Frontend/CompilerInvocationTest.cpp
+++ clang/unittests/Frontend/CompilerInvocationTest.cpp
@@ -705,7 +705,7 @@
 //
 //   * -cl-unsafe-math-optimizations
 // * -cl-mad-enable
-// * -menable-unsafe-fp-math
+// * -funsafe-math-optimizations
 //   * -freciprocal-math
 
 TEST_F(CommandLineTest, ImpliedBoolOptionsNoFlagPresent) {
@@ -723,7 +723,8 @@
   ASSERT_THAT(GeneratedArgs,
   Not(Contains(StrEq("-cl-unsafe-math-optimizations";
   ASSERT_THAT(GeneratedArgs, Not(Contains(StrEq("-cl-mad-enable";
-  ASSERT_THAT(GeneratedArgs, Not(Contains(StrEq("-menable-unsafe-fp-math";
+  ASSERT_THAT(GeneratedArgs,
+  Not(Contains(StrEq("-funsafe-math-optimizations";
   ASSERT_THAT(GeneratedArgs, Not(Contains(StrEq("-freciprocal-math";
 }
 
@@ -745,13 +746,14 @@
   ASSERT_THAT(GeneratedArgs, Contains(StrEq("-cl-unsafe-math-optimizations")));
   // Not generated - implied by the generated root flag.
   ASSERT_THAT(GeneratedArgs, Not(Contains(StrEq("-cl-mad-enable";
-  ASSERT_THAT(GeneratedArgs, Not(Contains(StrEq("-menable-unsafe-fp-math";
+  ASSERT_THAT(GeneratedArgs,
+  Not(Contains(StrEq("-funsafe-math-optimizations";
   ASSERT_THAT(GeneratedArgs, Not(Contains(StrEq("-freciprocal-math";
 }
 
 TEST_F(CommandLineTest, ImpliedBoolOptionsAllFlagsPresent) {
   const char *Args[] = {"-cl-unsafe-math-optimizations", "-cl-mad-enable",
-"-menable-unsafe-fp-math", "-freciprocal-math"};
+"-funsafe-math-optimizations", "-freciprocal-math"};
 
   ASSERT_TRUE(CompilerInvocation::CreateFromArgs(Invocation, Args, *Diags));
   ASSERT_TRUE(Invocation.getLangOpts()->CLUnsafeMath);
@@ -765,12 +767,13 @@
   ASSERT_THAT(GeneratedArgs, Contains(StrEq("-cl-unsafe-math-optimizations")));
   // Not generated - implied by their generated parent.
   ASSERT_THAT(GeneratedArgs, Not(Contains(StrEq("-cl-mad-enable";
-  ASSERT_THAT(GeneratedArgs, Not(Contains(StrEq("-menable-unsafe-fp-math";
+  ASSERT_THAT(GeneratedArgs,
+  Not(Contains(StrEq("-funsafe-math-optimizations";
   ASSERT_THAT(GeneratedArgs, Not(Contains(StrEq("-freciprocal-math";
 }
 
 TEST_F(CommandLineTest, ImpliedBoolOptionsImpliedFlagsPresent) {
-  const char *Args[] = {"-cl-mad-enable", "-menable-unsafe-fp-math",
+  const char *Args[] = {"-cl-mad-enable", "-funsafe-math-optimizations",
 "-freciprocal-math"};
 
   ASSERT_TRUE(CompilerInvocation::CreateFromArgs(Invocation, Args, *Diags));
@@ -785,13 +788,13 @@
   Not(Contains(StrEq("-cl-unsafe-math-optimizations";
   // Generated - explicitly provided.
   ASSERT_THAT(GeneratedArgs, Contains(StrEq("-cl-mad-enable")));
-  ASSERT_THAT(GeneratedArgs, Contains(StrEq("-menable-unsafe-fp-math")));
+  ASSERT_THAT(GeneratedArgs, Contains(StrEq("-funsafe-math-optimizations")));
   // Not generated - implied by its generated parent.
   ASSERT_THAT(GeneratedArgs, Not(Contains(StrEq("-freciprocal-math";
 }
 
 TEST_F(CommandLineTest, PresentAndNotImpliedGenerated) {
-  const char *Args[] = {"-cl-mad-enable", "-menable-unsafe-fp-math"};
+  const char *Args[] = {"-cl-mad-enable", "-funsafe-math-optimizations"};
 
   ASSERT_TRUE(CompilerInvocation::CreateFromArgs(Invocation, Args, *Diags));
 
@@ -799,7 +802,7 @@
 
   // Present options that were not implied are generated.
   ASSERT_THAT(GeneratedArgs, Contains(StrEq("-cl-mad-enable")));
-  ASSERT_THAT(GeneratedArgs, Contains(StrEq("-menable-unsafe-fp-math")));
+  ASSERT_THAT(GeneratedArgs, Contains(StrEq("-funsafe-math-optimizations")));
 }
 
 // Diagnostic option.
Index: clang/test/Parser/fp-floatcontrol-syntax.cpp
===
--- clang/test/Parser/fp-floatcontrol-syntax.cpp
+++ clang/test/Parser/fp-floatcontrol-syntax.cpp
@@ -42,7 +42,7 @@
 // RUN: %clang_cc1 -triple x86_64-linux-gnu -fdenormal-fp-math=preserve-sign,preserve-sign -fsyntax-only %s -DDEFAULT -verify
 // RUN: %clang_cc1 -triple x86_64-linux-gnu -fsyntax-only %s -ffp-contract=fast -DPRECISE -verify
 // RUN: %clang_cc1 -triple x86_64-linux-gnu -fsyntax-only %s -ffp-contract=off -frounding-math 

[PATCH] D135097: Remove redundant option '-menable-unsafe-fp-math'.

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam updated this revision to Diff 465768.
zahiraam added reviewers: andrew.w.kaylor, aaron.ballman, rjmccall, efriedma, 
fhahn, dexonsmith.
zahiraam changed the visibility from "Custom Policy" to "Public (No Login 
Required)".
Herald added a subscriber: MaskRay.

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D135097/new/

https://reviews.llvm.org/D135097

Files:
  clang/include/clang/Driver/Options.td
  clang/lib/CodeGen/CGCall.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/CodeGen/fp-options-to-fast-math-flags.c
  clang/test/CodeGen/func-attr.c
  clang/test/CodeGen/libcalls.c
  clang/test/CodeGenCUDA/propagate-metadata.cu
  clang/test/Driver/cl-options.c
  clang/test/Driver/fast-math.c
  clang/test/Driver/fp-model.c
  clang/test/Parser/fp-floatcontrol-syntax.cpp
  clang/unittests/Frontend/CompilerInvocationTest.cpp

Index: clang/unittests/Frontend/CompilerInvocationTest.cpp
===
--- clang/unittests/Frontend/CompilerInvocationTest.cpp
+++ clang/unittests/Frontend/CompilerInvocationTest.cpp
@@ -705,7 +705,7 @@
 //
 //   * -cl-unsafe-math-optimizations
 // * -cl-mad-enable
-// * -menable-unsafe-fp-math
+// * -funsafe-math-optimizations
 //   * -freciprocal-math
 
 TEST_F(CommandLineTest, ImpliedBoolOptionsNoFlagPresent) {
@@ -723,7 +723,7 @@
   ASSERT_THAT(GeneratedArgs,
   Not(Contains(StrEq("-cl-unsafe-math-optimizations";
   ASSERT_THAT(GeneratedArgs, Not(Contains(StrEq("-cl-mad-enable";
-  ASSERT_THAT(GeneratedArgs, Not(Contains(StrEq("-menable-unsafe-fp-math";
+  ASSERT_THAT(GeneratedArgs, Not(Contains(StrEq("-funsafe-math-optimizations";
   ASSERT_THAT(GeneratedArgs, Not(Contains(StrEq("-freciprocal-math";
 }
 
@@ -745,13 +745,13 @@
   ASSERT_THAT(GeneratedArgs, Contains(StrEq("-cl-unsafe-math-optimizations")));
   // Not generated - implied by the generated root flag.
   ASSERT_THAT(GeneratedArgs, Not(Contains(StrEq("-cl-mad-enable";
-  ASSERT_THAT(GeneratedArgs, Not(Contains(StrEq("-menable-unsafe-fp-math";
+  ASSERT_THAT(GeneratedArgs, Not(Contains(StrEq("-funsafe-math-optimizations";
   ASSERT_THAT(GeneratedArgs, Not(Contains(StrEq("-freciprocal-math";
 }
 
 TEST_F(CommandLineTest, ImpliedBoolOptionsAllFlagsPresent) {
   const char *Args[] = {"-cl-unsafe-math-optimizations", "-cl-mad-enable",
-"-menable-unsafe-fp-math", "-freciprocal-math"};
+"-funsafe-math-optimizations", "-freciprocal-math"};
 
   ASSERT_TRUE(CompilerInvocation::CreateFromArgs(Invocation, Args, *Diags));
   ASSERT_TRUE(Invocation.getLangOpts()->CLUnsafeMath);
@@ -765,12 +765,12 @@
   ASSERT_THAT(GeneratedArgs, Contains(StrEq("-cl-unsafe-math-optimizations")));
   // Not generated - implied by their generated parent.
   ASSERT_THAT(GeneratedArgs, Not(Contains(StrEq("-cl-mad-enable";
-  ASSERT_THAT(GeneratedArgs, Not(Contains(StrEq("-menable-unsafe-fp-math";
+  ASSERT_THAT(GeneratedArgs, Not(Contains(StrEq("-funsafe-math-optimizations";
   ASSERT_THAT(GeneratedArgs, Not(Contains(StrEq("-freciprocal-math";
 }
 
 TEST_F(CommandLineTest, ImpliedBoolOptionsImpliedFlagsPresent) {
-  const char *Args[] = {"-cl-mad-enable", "-menable-unsafe-fp-math",
+  const char *Args[] = {"-cl-mad-enable", "-funsafe-math-optimizations",
 "-freciprocal-math"};
 
   ASSERT_TRUE(CompilerInvocation::CreateFromArgs(Invocation, Args, *Diags));
@@ -785,13 +785,13 @@
   Not(Contains(StrEq("-cl-unsafe-math-optimizations";
   // Generated - explicitly provided.
   ASSERT_THAT(GeneratedArgs, Contains(StrEq("-cl-mad-enable")));
-  ASSERT_THAT(GeneratedArgs, Contains(StrEq("-menable-unsafe-fp-math")));
+  ASSERT_THAT(GeneratedArgs, Contains(StrEq("-funsafe-math-optimizations")));
   // Not generated - implied by its generated parent.
   ASSERT_THAT(GeneratedArgs, Not(Contains(StrEq("-freciprocal-math";
 }
 
 TEST_F(CommandLineTest, PresentAndNotImpliedGenerated) {
-  const char *Args[] = {"-cl-mad-enable", "-menable-unsafe-fp-math"};
+  const char *Args[] = {"-cl-mad-enable", "-funsafe-math-optimizations"};
 
   ASSERT_TRUE(CompilerInvocation::CreateFromArgs(Invocation, Args, *Diags));
 
@@ -799,7 +799,7 @@
 
   // Present options that were not implied are generated.
   ASSERT_THAT(GeneratedArgs, Contains(StrEq("-cl-mad-enable")));
-  ASSERT_THAT(GeneratedArgs, Contains(StrEq("-menable-unsafe-fp-math")));
+  ASSERT_THAT(GeneratedArgs, Contains(StrEq("-funsafe-math-optimizations")));
 }
 
 // Diagnostic option.
Index: clang/test/Parser/fp-floatcontrol-syntax.cpp
===
--- clang/test/Parser/fp-floatcontrol-syntax.cpp
+++ clang/test/Parser/fp-floatcontrol-syntax.cpp
@@ -42,7 +42,7 @@
 // RUN: %clang_cc1 -triple x86_64-linux-gnu -fdenormal-fp-math=preserve-sign,preserve-sign -fsyntax-only %s -DDEFAULT -verify
 // RUN: %clang_cc1 -triple x86_64-linux-gnu 

[PATCH] D123630: Remove connection between 'ffast-math' and 'ffp-contract'.

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam updated this revision to Diff 460470.
zahiraam marked 3 inline comments as done.

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D123630/new/

https://reviews.llvm.org/D123630

Files:
  clang/docs/UsersManual.rst
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/CodeGen/ffp-contract-option.c
  clang/test/Driver/fp-contract.c

Index: clang/test/Driver/fp-contract.c
===
--- /dev/null
+++ clang/test/Driver/fp-contract.c
@@ -0,0 +1,114 @@
+// Test that -ffp-contract is set to the right value when combined with
+// the options -ffast-math and -fno-fast-math.
+
+// RUN: %clang -### -ffast-math -c %s 2>&1  \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+// CHECK-FPC-FAST: "-ffp-contract=fast"
+
+// RUN: %clang -### -fno-fast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-ON %s
+
+// RUN: %clang -### -ffast-math -ffp-contract=on -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-ON %s
+// CHECK-FPC-ON:   "-ffp-contract=on"
+
+// RUN: %clang -### -ffast-math -ffp-contract=off -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-OFF %s
+// CHECK-FPC-OFF:  "-ffp-contract=off"
+
+// RUN: %clang -### -ffast-math -ffp-contract=fast -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -ffp-contract=fast -ffast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+// RUN: %clang -### -ffp-contract=on -ffast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+// RUN: %clang -### -ffp-contract=off -ffast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -ffp-contract=fast -fno-fast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+// RUN: %clang -### -ffp-contract=on -fno-fast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-ON %s
+// RUN: %clang -### -ffp-contract=off -fno-fast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-OFF %s
+
+
+// RUN: %clang -### -ffast-math -ffp-contract=fast -ffp-contract=on -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-ON %s
+
+// RUN: %clang -### -ffast-math -ffp-contract=on -ffp-contract=off -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-OFF %s
+
+// RUN: %clang -### -ffast-math -ffp-contract=on -ffp-contract=fast -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -ffast-math -ffp-contract=off -ffp-contract=on -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-ON %s
+
+// RUN: %clang -### -ffast-math -ffp-contract=off -ffp-contract=fast \
+// RUN: -c %s 2>&1 | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -ffast-math -ffp-contract=on -fno-fast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-ON %s
+
+// RUN: %clang -### -ffast-math -ffp-contract=off -fno-fast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-OFF %s
+
+// RUN: %clang -### -ffast-math -ffp-contract=fast -fno-fast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -ffast-math -fno-fast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-ON %s
+
+// RUN: %clang -### -fno-fast-math -ffast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -fno-fast-math -ffp-contract=on -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-ON %s
+
+// RUN: %clang -### -fno-fast-math -ffp-contract=off -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-OFF %s
+
+// RUN: %clang -### -fno-fast-math -ffp-contract=fast -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -ffp-contract=fast -fno-fast-math -ffp-contract=on \
+// RUN: -c %s 2>&1 | FileCheck --check-prefix=CHECK-FPC-ON %s
+
+// RUN: %clang -### -ffp-contract=fast -fno-fast-math -ffp-contract=off \
+// RUN: -c %s 2>&1 | FileCheck --check-prefix=CHECK-FPC-OFF %s
+
+// RUN: %clang -### -ffp-contract=off -fno-fast-math -ffp-contract=fast \
+// RUN: -c %s 2>&1 | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -ffp-contract=off -fno-fast-math -ffp-contract=on \
+// RUN: -c %s 2>&1 | FileCheck --check-prefix=CHECK-FPC-ON %s
+
+// RUN: %clang -### -ffp-contract=on -ffast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -ffp-contract=off -ffast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -ffp-contract=fast -ffast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -ffp-contract=on -ffast-math -fno-fast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-ON %s
+
+// RUN: %clang -### -ffp-contract=off -ffast-math -fno-fast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-OFF %s
+
+// RUN: 

[PATCH] D123630: Remove connection between 'ffast-math' and 'ffp-contract'.

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam updated this revision to Diff 460389.

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D123630/new/

https://reviews.llvm.org/D123630

Files:
  clang/docs/UsersManual.rst
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/CodeGen/ffp-contract-option.c
  clang/test/Driver/fp-contract.c

Index: clang/test/Driver/fp-contract.c
===
--- /dev/null
+++ clang/test/Driver/fp-contract.c
@@ -0,0 +1,114 @@
+// Test that -ffp-contract is set to the right value when combined with
+// the options -ffast-math and -fno-fast-math.
+
+// RUN: %clang -### -ffast-math -c %s 2>&1  \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+// CHECK-FPC-FAST: "-ffp-contract=fast"
+
+// RUN: %clang -### -fno-fast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-ON %s
+
+// RUN: %clang -### -ffast-math -ffp-contract=on -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-ON %s
+// CHECK-FPC-ON:   "-ffp-contract=on"
+
+// RUN: %clang -### -ffast-math -ffp-contract=off -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-OFF %s
+// CHECK-FPC-OFF:  "-ffp-contract=off"
+
+// RUN: %clang -### -ffast-math -ffp-contract=fast -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -ffp-contract=fast -ffast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+// RUN: %clang -### -ffp-contract=on -ffast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+// RUN: %clang -### -ffp-contract=off -ffast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -ffp-contract=fast -fno-fast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+// RUN: %clang -### -ffp-contract=on -fno-fast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-ON %s
+// RUN: %clang -### -ffp-contract=off -fno-fast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-OFF %s
+
+
+// RUN: %clang -### -ffast-math -ffp-contract=fast -ffp-contract=on -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-ON %s
+
+// RUN: %clang -### -ffast-math -ffp-contract=on -ffp-contract=off -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-OFF %s
+
+// RUN: %clang -### -ffast-math -ffp-contract=on -ffp-contract=fast -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -ffast-math -ffp-contract=off -ffp-contract=on -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-ON %s
+
+// RUN: %clang -### -ffast-math -ffp-contract=off -ffp-contract=fast \
+// RUN: -c %s 2>&1 | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -ffast-math -ffp-contract=on -fno-fast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-ON %s
+
+// RUN: %clang -### -ffast-math -ffp-contract=off -fno-fast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-OFF %s
+
+// RUN: %clang -### -ffast-math -ffp-contract=fast -fno-fast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -ffast-math -fno-fast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-ON %s
+
+// RUN: %clang -### -fno-fast-math -ffast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -fno-fast-math -ffp-contract=on -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-ON %s
+
+// RUN: %clang -### -fno-fast-math -ffp-contract=off -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-OFF %s
+
+// RUN: %clang -### -fno-fast-math -ffp-contract=fast -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -ffp-contract=fast -fno-fast-math -ffp-contract=on \
+// RUN: -c %s 2>&1 | FileCheck --check-prefix=CHECK-FPC-ON %s
+
+// RUN: %clang -### -ffp-contract=fast -fno-fast-math -ffp-contract=off \
+// RUN: -c %s 2>&1 | FileCheck --check-prefix=CHECK-FPC-OFF %s
+
+// RUN: %clang -### -ffp-contract=off -fno-fast-math -ffp-contract=fast \
+// RUN: -c %s 2>&1 | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -ffp-contract=off -fno-fast-math -ffp-contract=on \
+// RUN: -c %s 2>&1 | FileCheck --check-prefix=CHECK-FPC-ON %s
+
+// RUN: %clang -### -ffp-contract=on -ffast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -ffp-contract=off -ffast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -ffp-contract=fast -ffast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -ffp-contract=on -ffast-math -fno-fast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-ON %s
+
+// RUN: %clang -### -ffp-contract=off -ffast-math -fno-fast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-OFF %s
+
+// RUN: %clang -### -ffp-contract=fast -ffast-math 

[PATCH] D123630: Remove connection between 'ffast-math' and 'ffp-contract'.

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam updated this revision to Diff 460178.

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D123630/new/

https://reviews.llvm.org/D123630

Files:
  clang/docs/UsersManual.rst
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/CodeGen/ffp-contract-option.c
  clang/test/Driver/fp-contract.c

Index: clang/test/Driver/fp-contract.c
===
--- /dev/null
+++ clang/test/Driver/fp-contract.c
@@ -0,0 +1,114 @@
+// Test that -ffp-contract is set to the right value when combined with
+// the options -ffast-math and -fno-fast-math.
+
+// RUN: %clang -### -ffast-math -c %s 2>&1  \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+// CHECK-FPC-FAST: "-ffp-contract=fast"
+
+// RUN: %clang -### -fno-fast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-ON %s
+
+// RUN: %clang -### -ffast-math -ffp-contract=on -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-ON %s
+// CHECK-FPC-ON:   "-ffp-contract=on"
+
+// RUN: %clang -### -ffast-math -ffp-contract=off -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-OFF %s
+// CHECK-FPC-OFF:  "-ffp-contract=off"
+
+// RUN: %clang -### -ffast-math -ffp-contract=fast -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -ffp-contract=fast -ffast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+// RUN: %clang -### -ffp-contract=on -ffast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+// RUN: %clang -### -ffp-contract=off -ffast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -ffp-contract=fast -fno-fast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+// RUN: %clang -### -ffp-contract=on -fno-fast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-ON %s
+// RUN: %clang -### -ffp-contract=off -fno-fast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-OFF %s
+
+
+// RUN: %clang -### -ffast-math -ffp-contract=fast -ffp-contract=on -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-ON %s
+
+// RUN: %clang -### -ffast-math -ffp-contract=on -ffp-contract=off -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-OFF %s
+
+// RUN: %clang -### -ffast-math -ffp-contract=on -ffp-contract=fast -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -ffast-math -ffp-contract=off -ffp-contract=on -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-ON %s
+
+// RUN: %clang -### -ffast-math -ffp-contract=off -ffp-contract=fast \
+// RUN: -c %s 2>&1 | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -ffast-math -ffp-contract=on -fno-fast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-ON %s
+
+// RUN: %clang -### -ffast-math -ffp-contract=off -fno-fast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-OFF %s
+
+// RUN: %clang -### -ffast-math -ffp-contract=fast -fno-fast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -ffast-math -fno-fast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-ON %s
+
+// RUN: %clang -### -fno-fast-math -ffast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -fno-fast-math -ffp-contract=on -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-ON %s
+
+// RUN: %clang -### -fno-fast-math -ffp-contract=off -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-OFF %s
+
+// RUN: %clang -### -fno-fast-math -ffp-contract=fast -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -ffp-contract=fast -fno-fast-math -ffp-contract=on \
+// RUN: -c %s 2>&1 | FileCheck --check-prefix=CHECK-FPC-ON %s
+
+// RUN: %clang -### -ffp-contract=fast -fno-fast-math -ffp-contract=off \
+// RUN: -c %s 2>&1 | FileCheck --check-prefix=CHECK-FPC-OFF %s
+
+// RUN: %clang -### -ffp-contract=off -fno-fast-math -ffp-contract=fast \
+// RUN: -c %s 2>&1 | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -ffp-contract=off -fno-fast-math -ffp-contract=on \
+// RUN: -c %s 2>&1 | FileCheck --check-prefix=CHECK-FPC-ON %s
+
+// RUN: %clang -### -ffp-contract=on -ffast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -ffp-contract=off -ffast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -ffp-contract=fast -ffast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -ffp-contract=on -ffast-math -fno-fast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-ON %s
+
+// RUN: %clang -### -ffp-contract=off -ffast-math -fno-fast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-OFF %s
+
+// RUN: %clang -### -ffp-contract=fast -ffast-math 

[PATCH] D123630: Remove connection between 'ffast-math' and 'ffp-contract'.

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam added inline comments.



Comment at: clang/docs/UsersManual.rst:1453-1455
+   Note: ``DenormalFPMath`` and ``DenormalFP32Math`` are set by default to IEEE
+   (no flush) for ``-fno-fast-math``, ``-fno-unsafe-math-optimizations``, and
+   any setting of ``fp-model``. Clang does enable flush-to-zero when

jcranmer-intel wrote:
> You can replace this text with saying that `-fno-fast-math` implies 
> `-fdenormal-fp-math=ieee`. No need to directly mention `DenormalFPMath`; 
> instead relate it to the other command line flags that are documented.
Not sure that's the change you are proposing?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D123630/new/

https://reviews.llvm.org/D123630

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D123630: Remove connection between 'ffast-math' and 'ffp-contract'.

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam updated this revision to Diff 459893.
zahiraam marked 2 inline comments as done.

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D123630/new/

https://reviews.llvm.org/D123630

Files:
  clang/docs/UsersManual.rst
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/CodeGen/ffp-contract-option.c
  clang/test/Driver/fp-contract.c

Index: clang/test/Driver/fp-contract.c
===
--- /dev/null
+++ clang/test/Driver/fp-contract.c
@@ -0,0 +1,114 @@
+// Test that -ffp-contract is set to the right value when combined with
+// the options -ffast-math and -fno-fast-math.
+
+// RUN: %clang -### -ffast-math -c %s 2>&1  \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+// CHECK-FPC-FAST: "-ffp-contract=fast"
+
+// RUN: %clang -### -fno-fast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-ON %s
+
+// RUN: %clang -### -ffast-math -ffp-contract=on -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-ON %s
+// CHECK-FPC-ON:   "-ffp-contract=on"
+
+// RUN: %clang -### -ffast-math -ffp-contract=off -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-OFF %s
+// CHECK-FPC-OFF:  "-ffp-contract=off"
+
+// RUN: %clang -### -ffast-math -ffp-contract=fast -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -ffp-contract=fast -ffast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+// RUN: %clang -### -ffp-contract=on -ffast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+// RUN: %clang -### -ffp-contract=off -ffast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -ffp-contract=fast -fno-fast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+// RUN: %clang -### -ffp-contract=on -fno-fast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-ON %s
+// RUN: %clang -### -ffp-contract=off -fno-fast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-OFF %s
+
+
+// RUN: %clang -### -ffast-math -ffp-contract=fast -ffp-contract=on -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-ON %s
+
+// RUN: %clang -### -ffast-math -ffp-contract=on -ffp-contract=off -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-OFF %s
+
+// RUN: %clang -### -ffast-math -ffp-contract=on -ffp-contract=fast -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -ffast-math -ffp-contract=off -ffp-contract=on -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-ON %s
+
+// RUN: %clang -### -ffast-math -ffp-contract=off -ffp-contract=fast \
+// RUN: -c %s 2>&1 | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -ffast-math -ffp-contract=on -fno-fast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-ON %s
+
+// RUN: %clang -### -ffast-math -ffp-contract=off -fno-fast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-OFF %s
+
+// RUN: %clang -### -ffast-math -ffp-contract=fast -fno-fast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -ffast-math -fno-fast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-ON %s
+
+// RUN: %clang -### -fno-fast-math -ffast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -fno-fast-math -ffp-contract=on -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-ON %s
+
+// RUN: %clang -### -fno-fast-math -ffp-contract=off -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-OFF %s
+
+// RUN: %clang -### -fno-fast-math -ffp-contract=fast -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -ffp-contract=fast -fno-fast-math -ffp-contract=on \
+// RUN: -c %s 2>&1 | FileCheck --check-prefix=CHECK-FPC-ON %s
+
+// RUN: %clang -### -ffp-contract=fast -fno-fast-math -ffp-contract=off \
+// RUN: -c %s 2>&1 | FileCheck --check-prefix=CHECK-FPC-OFF %s
+
+// RUN: %clang -### -ffp-contract=off -fno-fast-math -ffp-contract=fast \
+// RUN: -c %s 2>&1 | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -ffp-contract=off -fno-fast-math -ffp-contract=on \
+// RUN: -c %s 2>&1 | FileCheck --check-prefix=CHECK-FPC-ON %s
+
+// RUN: %clang -### -ffp-contract=on -ffast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -ffp-contract=off -ffast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -ffp-contract=fast -ffast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -ffp-contract=on -ffast-math -fno-fast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-ON %s
+
+// RUN: %clang -### -ffp-contract=off -ffast-math -fno-fast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-OFF %s
+
+// RUN: 

[PATCH] D123630: Remove connection between 'ffast-math' and 'ffp-contract'.

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam updated this revision to Diff 459028.
zahiraam marked an inline comment as done.

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D123630/new/

https://reviews.llvm.org/D123630

Files:
  clang/docs/UsersManual.rst
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/CodeGen/ffp-contract-option.c
  clang/test/Driver/fp-contract.c

Index: clang/test/Driver/fp-contract.c
===
--- /dev/null
+++ clang/test/Driver/fp-contract.c
@@ -0,0 +1,114 @@
+// Test that -ffp-contract is set to the right value when combined with
+// the options -ffast-math and -fno-fast-math.
+
+// RUN: %clang -### -ffast-math -c %s 2>&1  \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+// CHECK-FPC-FAST: "-ffp-contract=fast"
+
+// RUN: %clang -### -fno-fast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-ON %s
+
+// RUN: %clang -### -ffast-math -ffp-contract=on -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-ON %s
+// CHECK-FPC-ON:   "-ffp-contract=on"
+
+// RUN: %clang -### -ffast-math -ffp-contract=off -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-OFF %s
+// CHECK-FPC-OFF:  "-ffp-contract=off"
+
+// RUN: %clang -### -ffast-math -ffp-contract=fast -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -ffp-contract=fast -ffast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+// RUN: %clang -### -ffp-contract=on -ffast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+// RUN: %clang -### -ffp-contract=off -ffast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -ffp-contract=fast -fno-fast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+// RUN: %clang -### -ffp-contract=on -fno-fast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-ON %s
+// RUN: %clang -### -ffp-contract=off -fno-fast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-OFF %s
+
+
+// RUN: %clang -### -ffast-math -ffp-contract=fast -ffp-contract=on -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-ON %s
+
+// RUN: %clang -### -ffast-math -ffp-contract=on -ffp-contract=off -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-OFF %s
+
+// RUN: %clang -### -ffast-math -ffp-contract=on -ffp-contract=fast -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -ffast-math -ffp-contract=off -ffp-contract=on -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-ON %s
+
+// RUN: %clang -### -ffast-math -ffp-contract=off -ffp-contract=fast \
+// RUN: -c %s 2>&1 | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -ffast-math -ffp-contract=on -fno-fast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-ON %s
+
+// RUN: %clang -### -ffast-math -ffp-contract=off -fno-fast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-OFF %s
+
+// RUN: %clang -### -ffast-math -ffp-contract=fast -fno-fast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -ffast-math -fno-fast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-ON %s
+
+// RUN: %clang -### -fno-fast-math -ffast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -fno-fast-math -ffp-contract=on -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-ON %s
+
+// RUN: %clang -### -fno-fast-math -ffp-contract=off -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-OFF %s
+
+// RUN: %clang -### -fno-fast-math -ffp-contract=fast -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -ffp-contract=fast -fno-fast-math -ffp-contract=on \
+// RUN: -c %s 2>&1 | FileCheck --check-prefix=CHECK-FPC-ON %s
+
+// RUN: %clang -### -ffp-contract=fast -fno-fast-math -ffp-contract=off \
+// RUN: -c %s 2>&1 | FileCheck --check-prefix=CHECK-FPC-OFF %s
+
+// RUN: %clang -### -ffp-contract=off -fno-fast-math -ffp-contract=fast \
+// RUN: -c %s 2>&1 | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -ffp-contract=off -fno-fast-math -ffp-contract=on \
+// RUN: -c %s 2>&1 | FileCheck --check-prefix=CHECK-FPC-ON %s
+
+// RUN: %clang -### -ffp-contract=on -ffast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -ffp-contract=off -ffast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -ffp-contract=fast -ffast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -ffp-contract=on -ffast-math -fno-fast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-ON %s
+
+// RUN: %clang -### -ffp-contract=off -ffast-math -fno-fast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-OFF %s
+
+// RUN: 

[PATCH] D123630: Remove connection between 'ffast-math' and 'ffp-contract'.

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam added a comment.

Thanks @aaron.ballman!


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D123630/new/

https://reviews.llvm.org/D123630

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D123630: Remove connection between 'ffast-math' and 'ffp-contract'.

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam updated this revision to Diff 458506.
zahiraam marked 4 inline comments as done.

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D123630/new/

https://reviews.llvm.org/D123630

Files:
  clang/docs/UsersManual.rst
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/CodeGen/ffp-contract-option.c
  clang/test/Driver/fp-contract.c

Index: clang/test/Driver/fp-contract.c
===
--- /dev/null
+++ clang/test/Driver/fp-contract.c
@@ -0,0 +1,114 @@
+// Test that -ffp-contract is set to the right value when combined with
+// the options -ffast-math and -fno-fast-math.
+
+// RUN: %clang -### -ffast-math -c %s 2>&1  \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+// CHECK-FPC-FAST: "-ffp-contract=fast"
+
+// RUN: %clang -### -fno-fast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-ON %s
+
+// RUN: %clang -### -ffast-math -ffp-contract=on -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-ON %s
+// CHECK-FPC-ON:   "-ffp-contract=on"
+
+// RUN: %clang -### -ffast-math -ffp-contract=off -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-OFF %s
+// CHECK-FPC-OFF:  "-ffp-contract=off"
+
+// RUN: %clang -### -ffast-math -ffp-contract=fast -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -ffp-contract=fast -ffast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+// RUN: %clang -### -ffp-contract=on -ffast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+// RUN: %clang -### -ffp-contract=off -ffast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -ffp-contract=fast -fno-fast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+// RUN: %clang -### -ffp-contract=on -fno-fast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-ON %s
+// RUN: %clang -### -ffp-contract=off -fno-fast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-OFF %s
+
+
+// RUN: %clang -### -ffast-math -ffp-contract=fast -ffp-contract=on -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-ON %s
+
+// RUN: %clang -### -ffast-math -ffp-contract=on -ffp-contract=off -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-OFF %s
+
+// RUN: %clang -### -ffast-math -ffp-contract=on -ffp-contract=fast -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -ffast-math -ffp-contract=off -ffp-contract=on -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-ON %s
+
+// RUN: %clang -### -ffast-math -ffp-contract=off -ffp-contract=fast \
+// RUN: -c %s 2>&1 | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -ffast-math -ffp-contract=on -fno-fast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-ON %s
+
+// RUN: %clang -### -ffast-math -ffp-contract=off -fno-fast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-OFF %s
+
+// RUN: %clang -### -ffast-math -ffp-contract=fast -fno-fast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -ffast-math -fno-fast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-ON %s
+
+// RUN: %clang -### -fno-fast-math -ffast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -fno-fast-math -ffp-contract=on -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-ON %s
+
+// RUN: %clang -### -fno-fast-math -ffp-contract=off -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-OFF %s
+
+// RUN: %clang -### -fno-fast-math -ffp-contract=fast -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -ffp-contract=fast -fno-fast-math -ffp-contract=on \
+// RUN: -c %s 2>&1 | FileCheck --check-prefix=CHECK-FPC-ON %s
+
+// RUN: %clang -### -ffp-contract=fast -fno-fast-math -ffp-contract=off \
+// RUN: -c %s 2>&1 | FileCheck --check-prefix=CHECK-FPC-OFF %s
+
+// RUN: %clang -### -ffp-contract=off -fno-fast-math -ffp-contract=fast \
+// RUN: -c %s 2>&1 | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -ffp-contract=off -fno-fast-math -ffp-contract=on \
+// RUN: -c %s 2>&1 | FileCheck --check-prefix=CHECK-FPC-ON %s
+
+// RUN: %clang -### -ffp-contract=on -ffast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -ffp-contract=off -ffast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -ffp-contract=fast -ffast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -ffp-contract=on -ffast-math -fno-fast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-ON %s
+
+// RUN: %clang -### -ffp-contract=off -ffast-math -fno-fast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-OFF %s
+
+// RUN: 

[PATCH] D123630: Remove connection between 'ffast-math' and 'ffp-contract'.

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam added a comment.

@fhahn @aaron.ballman would you mind taking time for a review for this patch? 
Thanks.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D123630/new/

https://reviews.llvm.org/D123630

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D123630: Remove connection between 'ffast-math' and 'ffp-contract'.

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam updated this revision to Diff 457358.

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D123630/new/

https://reviews.llvm.org/D123630

Files:
  clang/docs/UsersManual.rst
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/CodeGen/ffp-contract-option.c
  clang/test/Driver/fp-contract.c

Index: clang/test/Driver/fp-contract.c
===
--- /dev/null
+++ clang/test/Driver/fp-contract.c
@@ -0,0 +1,114 @@
+// Test that -ffp-contract is set to the right value when combined with
+// the options -ffast-math and -fno-fast-math.
+
+// RUN: %clang -### -ffast-math -c %s 2>&1  \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+// CHECK-FPC-FAST: "-ffp-contract=fast"
+
+// RUN: %clang -### -fno-fast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-ON %s
+
+// RUN: %clang -### -ffast-math -ffp-contract=on -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-ON %s
+// CHECK-FPC-ON:   "-ffp-contract=on"
+
+// RUN: %clang -### -ffast-math -ffp-contract=off -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-OFF %s
+// CHECK-FPC-OFF:  "-ffp-contract=off"
+
+// RUN: %clang -### -ffast-math -ffp-contract=fast -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -ffp-contract=fast -ffast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+// RUN: %clang -### -ffp-contract=on -ffast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+// RUN: %clang -### -ffp-contract=off -ffast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -ffp-contract=fast -fno-fast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+// RUN: %clang -### -ffp-contract=on -fno-fast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-ON %s
+// RUN: %clang -### -ffp-contract=off -fno-fast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-OFF %s
+
+
+// RUN: %clang -### -ffast-math -ffp-contract=fast -ffp-contract=on -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-ON %s
+
+// RUN: %clang -### -ffast-math -ffp-contract=on -ffp-contract=off -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-OFF %s
+
+// RUN: %clang -### -ffast-math -ffp-contract=on -ffp-contract=fast -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -ffast-math -ffp-contract=off -ffp-contract=on -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-ON %s
+
+// RUN: %clang -### -ffast-math -ffp-contract=off -ffp-contract=fast \
+// RUN: -c %s 2>&1 | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -ffast-math -ffp-contract=on -fno-fast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-ON %s
+
+// RUN: %clang -### -ffast-math -ffp-contract=off -fno-fast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-OFF %s
+
+// RUN: %clang -### -ffast-math -ffp-contract=fast -fno-fast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -ffast-math -fno-fast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-ON %s
+
+// RUN: %clang -### -fno-fast-math -ffast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -fno-fast-math -ffp-contract=on -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-ON %s
+
+// RUN: %clang -### -fno-fast-math -ffp-contract=off -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-OFF %s
+
+// RUN: %clang -### -fno-fast-math -ffp-contract=fast -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -ffp-contract=fast -fno-fast-math -ffp-contract=on \
+// RUN: -c %s 2>&1 | FileCheck --check-prefix=CHECK-FPC-ON %s
+
+// RUN: %clang -### -ffp-contract=fast -fno-fast-math -ffp-contract=off \
+// RUN: -c %s 2>&1 | FileCheck --check-prefix=CHECK-FPC-OFF %s
+
+// RUN: %clang -### -ffp-contract=off -fno-fast-math -ffp-contract=fast \
+// RUN: -c %s 2>&1 | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -ffp-contract=off -fno-fast-math -ffp-contract=on \
+// RUN: -c %s 2>&1 | FileCheck --check-prefix=CHECK-FPC-ON %s
+
+// RUN: %clang -### -ffp-contract=on -ffast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -ffp-contract=off -ffast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -ffp-contract=fast -ffast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -ffp-contract=on -ffast-math -fno-fast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-ON %s
+
+// RUN: %clang -### -ffp-contract=off -ffast-math -fno-fast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-OFF %s
+
+// RUN: %clang -### -ffp-contract=fast -ffast-math 

[PATCH] D123630: [WIP] Remove connection between 'ffast-math' and 'ffp-contract'.

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam updated this revision to Diff 456337.

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D123630/new/

https://reviews.llvm.org/D123630

Files:
  clang/docs/UsersManual.rst
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/CodeGen/ffp-contract-option.c
  clang/test/Driver/fp-contract.c

Index: clang/test/Driver/fp-contract.c
===
--- /dev/null
+++ clang/test/Driver/fp-contract.c
@@ -0,0 +1,114 @@
+// Test that -ffp-contract is set to the right value when combined with
+// the options -ffast-math and -fno-fast-math.
+
+// RUN: %clang -### -ffast-math -c %s 2>&1  \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+// CHECK-FPC-FAST: "-ffp-contract=fast"
+
+// RUN: %clang -### -fno-fast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-ON %s
+
+// RUN: %clang -### -ffast-math -ffp-contract=on -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-ON %s
+// CHECK-FPC-ON:   "-ffp-contract=on"
+
+// RUN: %clang -### -ffast-math -ffp-contract=off -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-OFF %s
+// CHECK-FPC-OFF:  "-ffp-contract=off"
+
+// RUN: %clang -### -ffast-math -ffp-contract=fast -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -ffp-contract=fast -ffast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+// RUN: %clang -### -ffp-contract=on -ffast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+// RUN: %clang -### -ffp-contract=off -ffast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -ffp-contract=fast -fno-fast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+// RUN: %clang -### -ffp-contract=on -fno-fast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-ON %s
+// RUN: %clang -### -ffp-contract=off -fno-fast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-OFF %s
+
+
+// RUN: %clang -### -ffast-math -ffp-contract=fast -ffp-contract=on -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-ON %s
+
+// RUN: %clang -### -ffast-math -ffp-contract=on -ffp-contract=off -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-OFF %s
+
+// RUN: %clang -### -ffast-math -ffp-contract=on -ffp-contract=fast -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -ffast-math -ffp-contract=off -ffp-contract=on -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-ON %s
+
+// RUN: %clang -### -ffast-math -ffp-contract=off -ffp-contract=fast \
+// RUN: -c %s 2>&1 | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -ffast-math -ffp-contract=on -fno-fast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-ON %s
+
+// RUN: %clang -### -ffast-math -ffp-contract=off -fno-fast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-OFF %s
+
+// RUN: %clang -### -ffast-math -ffp-contract=fast -fno-fast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -ffast-math -fno-fast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-ON %s
+
+// RUN: %clang -### -fno-fast-math -ffast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -fno-fast-math -ffp-contract=on -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-ON %s
+
+// RUN: %clang -### -fno-fast-math -ffp-contract=off -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-OFF %s
+
+// RUN: %clang -### -fno-fast-math -ffp-contract=fast -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -ffp-contract=fast -fno-fast-math -ffp-contract=on \
+// RUN: -c %s 2>&1 | FileCheck --check-prefix=CHECK-FPC-ON %s
+
+// RUN: %clang -### -ffp-contract=fast -fno-fast-math -ffp-contract=off \
+// RUN: -c %s 2>&1 | FileCheck --check-prefix=CHECK-FPC-OFF %s
+
+// RUN: %clang -### -ffp-contract=off -fno-fast-math -ffp-contract=fast \
+// RUN: -c %s 2>&1 | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -ffp-contract=off -fno-fast-math -ffp-contract=on \
+// RUN: -c %s 2>&1 | FileCheck --check-prefix=CHECK-FPC-ON %s
+
+// RUN: %clang -### -ffp-contract=on -ffast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -ffp-contract=off -ffast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -ffp-contract=fast -ffast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-FAST %s
+
+// RUN: %clang -### -ffp-contract=on -ffast-math -fno-fast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-ON %s
+
+// RUN: %clang -### -ffp-contract=off -ffast-math -fno-fast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FPC-OFF %s
+
+// RUN: %clang -### -ffp-contract=fast -ffast-math 

[PATCH] D113107: Support of expression granularity for _Float16.

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam added a subscriber: bkramer.
zahiraam added a comment.

Thanks @bkramer


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D113107/new/

https://reviews.llvm.org/D113107

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D113107: Support of expression granularity for _Float16.

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam added a comment.

In D113107#3747095 , @rjmccall wrote:

> Thanks, LGTM

Thanks for all the reviews. There is still more work to be done :) 
I will push it tomorrow as it's the end of day for me and I am afraid there 
will be some fails that I wouldn't be able to attend to right away.
Thank you!


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D113107/new/

https://reviews.llvm.org/D113107

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D113107: Support of expression granularity for _Float16.

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam added inline comments.



Comment at: clang/lib/CodeGen/CGExprComplex.cpp:615
+  ComplexPairTy result = VisitMinus(E, promotionTy);
+  return result;
+}

rjmccall wrote:
> This is not unpromoting if the original `PromotionType` is null.
The idea for this change is that we will be coming to this function only if we 
are returning a "-operand". If we are in the middle of an expression (such as 
-f *a +b) we would be directly going to VisitMinus from 
ScalarExprEmitter::EmitPromod, from the switch branch of UnaryMinus and the 
promotiontype wouldn't be null.



CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D113107/new/

https://reviews.llvm.org/D113107

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D113107: Support of expression granularity for _Float16.

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam added a comment.

In D113107#3743318 , @rjmccall wrote:

> Somehow we've taken a huge step back on unpromotion, and I'm worried you're 
> now doing the exact thing I didn't want us doing and forcing all the 
> downstream clients to handle the possibility of a promoted result.

Okay may be trying to do the optimization that @pengfei  was mentioning is too 
soon to do? Let me backup here and let for the Unary operators do the 
promote/unpromote back to back and see if that's better.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D113107/new/

https://reviews.llvm.org/D113107

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D113107: Support of expression granularity for _Float16.

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam added inline comments.



Comment at: clang/test/CodeGen/X86/Float16-arithmetic.c:207
+// CHECK-NEXT:[[EXT:%.*]] = fpext half [[TMP0]] to float
+// CHECK-NEXT:store float [[EXT]], ptr [[RETVAL]], align 2
+// CHECK-NEXT:[[TMP1:%.*]] = load half, ptr [[RETVAL]], align 2

zahiraam wrote:
> pengfei wrote:
> > Not sure if we need a fptrunc and store the half value. The following tests 
> > have the same problem.
> I think that's what we want?
> // CHECK-LABEL: @RealOp(
> // CHECK-NEXT:  entry:
> // CHECK-NEXT:[[A_ADDR:%.*]] = alloca half, align 2
> // CHECK-NEXT:store half [[A:%.*]], ptr [[A_ADDR]], align 2
> // CHECK-NEXT:[[TMP0:%.*]] = load half, ptr [[A_ADDR]], align 2
> // CHECK-NEXT:[[EXT:%.*]] = fpext half [[TMP0]] to float
> // CHECK-NEXT:[[UNPROMOTION:%.*]] = fptrunc float [[EXT]] to half
> // CHECK-NEXT:ret half [[UNPROMOTION]]
> 
> Do you agree? If this is correct, I will make the change the other operators.
But I feel like we should be returning a float no?  In which case it will be 
more tricky (need to calculate the Address with the promoted elementype)? 
@rmjccall?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D113107/new/

https://reviews.llvm.org/D113107

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D113107: Support of expression granularity for _Float16.

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam marked an inline comment as done.
zahiraam added inline comments.



Comment at: clang/test/CodeGen/X86/Float16-arithmetic.c:207
+// CHECK-NEXT:[[EXT:%.*]] = fpext half [[TMP0]] to float
+// CHECK-NEXT:store float [[EXT]], ptr [[RETVAL]], align 2
+// CHECK-NEXT:[[TMP1:%.*]] = load half, ptr [[RETVAL]], align 2

pengfei wrote:
> Not sure if we need a fptrunc and store the half value. The following tests 
> have the same problem.
I think that's what we want?
// CHECK-LABEL: @RealOp(
// CHECK-NEXT:  entry:
// CHECK-NEXT:[[A_ADDR:%.*]] = alloca half, align 2
// CHECK-NEXT:store half [[A:%.*]], ptr [[A_ADDR]], align 2
// CHECK-NEXT:[[TMP0:%.*]] = load half, ptr [[A_ADDR]], align 2
// CHECK-NEXT:[[EXT:%.*]] = fpext half [[TMP0]] to float
// CHECK-NEXT:[[UNPROMOTION:%.*]] = fptrunc float [[EXT]] to half
// CHECK-NEXT:ret half [[UNPROMOTION]]

Do you agree? If this is correct, I will make the change the other operators.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D113107/new/

https://reviews.llvm.org/D113107

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D113107: Support of expression granularity for _Float16.

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam added a comment.

In D113107#3736325 , @rjmccall wrote:

> In D113107#3736312 , @zahiraam 
> wrote:
>
>> This is a reduced test case from the codegen/complex-strictfp.c
>>
>> _Complex double g1, g2;
>> double D;
>>
>> void foo(void) {
>>
>>   g1 = g1 + D;
>>
>> }
>>
>> The issue is that we are calling in VisitBinAssign the function  
>> EmitUnpromotion (since promotionTy is null). This creates 2 constrained 
>> (-ffp-exception-behavior=maytrap used) fptrunc instructions. The verifier 
>> for Intrinsic::experimental_constrained_fptrunc fails at this check:
>> https://github.com/intel/llvm/blob/sycl/llvm/lib/IR/Verifier.cpp#L5885
>> Is the call for EmitUnpromotion at the right place? Or should VisitBinAssign 
>> be treated the same way than the operator of HANDLEBINOP? Since in this case 
>> we are in the unpromoted path, we don't really need to add those fptrunc? 
>> Any thoughts?
>
> If `VisitBinAssign` isn't opting to promoted emission (by calling 
> `EmitPromoted...`), it shouldn't have to call `EmitUnpromotion`; it should be 
> able to rely on getting appropriate values for the type of its operands.  
> That's what I mean by a strong postcondition.  So yeah, if you added a call 
> to `EmitUnpromotion` there as a workaround at some point, you should take it 
> out.  If that breaks tests, it's because some emitter is leaking promoted 
> values out of the normal emission path, and we need to fix that emitter.

Fixed codegen issue and LIT test issue mentioned by @rjmccall.
I need second pair of eyes to check the resulting IR, @pengfei  can you please 
help with that?
Do we want to add the promoted path for VistiBinAssign in this patch or can we 
add it in a subsequent patch? 
Thanks.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D113107/new/

https://reviews.llvm.org/D113107

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D113107: Support of expression granularity for _Float16.

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam added a comment.

This is a reduced test case from the codegen/complex-strictfp.c

_Complex double g1, g2;
double D;

void foo(void) {

  g1 = g1 + D;

}

The issue is that we are calling in VisitBinAssign the function  
EmitUnpromotion (since promotionTy is null). This creates 2 constrained 
(-ffp-exception-behavior=maytrap used) fptrunc instructions. The verifier for 
Intrinsic::experimental_constrained_fptrunc fails at this check:
https://github.com/intel/llvm/blob/sycl/llvm/lib/IR/Verifier.cpp#L5885
Is the call for EmitUnpromotion at the right place? Or should VisitBinAssign be 
treated the same way than the operator of HANDLEBINOP? Since in this case we 
are in the unpromoted path, we don't really need to add those fptrunc? Any 
thoughts?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D113107/new/

https://reviews.llvm.org/D113107

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D113107: Support of expression granularity for _Float16.

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam marked 3 inline comments as done.
zahiraam added a comment.






Comment at: clang/test/CodeGen/X86/Float16-complex.c:1184
+// X86-NEXT:store float [[NEG_I]], ptr [[RETVAL_IMAGP]], align 2
+// X86-NEXT:[[TMP0:%.*]] = load <2 x half>, ptr [[RETVAL]], align 2
+// X86-NEXT:ret <2 x half> [[TMP0]]

rjmccall wrote:
> This code pattern is definitely wrong, and it's a sign that the expression 
> evaluator returned the wrong type.  This is coercing a `_Complex float` into 
> a `_Complex _Float16` through memory, which is essentially reinterpreting the 
> first float as a pair of `_Float16`s.  You should go through your tests and 
> make sure you don't see other instances of this.
I think the issue here is that in ComplexExprEmitter::EmitStoreOfComplex, we 
are computing the Ptr from lvalue which elementype is halfty instead of float. 
I think the code there needs to change when there is a getPromotionType. We 
need to compute a Ptr with float as elementype .
The Val argument returned by the complex emitter has the right type (Float). 



CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D113107/new/

https://reviews.llvm.org/D113107

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D113107: Support of expression granularity for _Float16.

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam added inline comments.



Comment at: clang/lib/CodeGen/CGExprComplex.cpp:613
+result = EmitUnpromotion(promotionTy, E->getSubExpr()->getType(), result);
+  return result;
+}

rjmccall wrote:
> You should unpromote only if we're not in a promoted context, which is to 
> say, only if the `PromotionType` that was passed in is null.
oh! right. The promotionTy is not even used in the function. Thanks.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D113107/new/

https://reviews.llvm.org/D113107

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D113107: Support of expression granularity for _Float16.

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam added inline comments.



Comment at: clang/lib/CodeGen/CGExprComplex.cpp:609
+  ComplexPairTy Op;
+  PromotionType = getPromotionType(E->getSubExpr()->getType());
+  if (!PromotionType.isNull())

rjmccall wrote:
> This is overwriting the argument, so the code below doesn't understand 
> whether it's supposed to be emitting a promoted result or not.  You can test 
> this with something like:
> 
> ```
> cf16 = -cf16;
> ```
> 
> Here the context does not want a promoted result, but you will produce one 
> anyway.
> 
> Because this operator does its own arithmetic, like the binary operators, it 
> needs to follow the same basic logic:
> - remember whether you're supposed to emit a promoted result
> - if not, check whether you should do the arithmetic promoted anyway
> - if you did the arithmetic promoted, but you're not supposed to emit a 
> promoted result, unpromote the result

So something like this:

#define HANDLEUNOP(OP) \
  Value *VisitUnary##OP(const UnaryOperator *E,\
QualType PromotionType = QualType()) {  
 \
QualType promotionTy = getPromotionType(E->getSubExpr()->getType());   \
llvvm::Value *result = **Visit##OP**(E, promotionTy);   
  \
   result = EmitUnpromotion(promotionTy, E, result);
  }
  HANDLEUNOP(Minus)
 HANDLEUNOP(Plus)
 HANDLEUNOP(Imag)
 HANDLEUNOP(Reg)
#undef HANDLEUNOP

Where Visit##* are the bodies taken from the current VisitUnary*?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D113107/new/

https://reviews.llvm.org/D113107

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D113107: Support of expression granularity for _Float16.

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam added a comment.

With this last patch, the behaviors of CodeGen/volatile-1.c and 
CodeGenCXX/volatile-1.cpp have changed ( change with __imag). I have uploaded 
the changes but still trying to figure out what exactly changed and why. Thanks.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D113107/new/

https://reviews.llvm.org/D113107

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D113107: Support of expression granularity for _Float16.

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam added inline comments.



Comment at: clang/lib/CodeGen/CGExprScalar.cpp:3140
+  return CGF.Builder.CreateFPExt(result, ConvertType(E->getType()));
+  }
+  return result;

rjmccall wrote:
> zahiraam wrote:
> > rjmccall wrote:
> > > Please extract this block out as:
> > > 
> > > ```
> > > llvm::Value *EmitPromotedValue(llvm::Value *result, QualType 
> > > PromotionType);
> > > ```
> > These changes you are proposing is when the argument of the unary __imag / 
> > __real is of type _Complex Float16. I would think that this new method 
> > EmitPromotedValue would be replacing the equivalent code in 
> > ComplexEmitter::EmitPromoted instead,  not in the scalar emitter, right?
> I probably mixed up which emitter I commented on.  The upshot is that I would 
> like there to be `EmitPromotedValue` and `EmitUnpromotedValue` helper 
> functions on both emitters (which of course would take/return an 
> `llvm::Value*` on the scalar emitter and a `CGComplexPair` on the complex 
> emitter), just so that we have all the value promotion/unpromotion logic for 
> each emitter in one place.
Let's see if what I have done is satisfactory! It's not quite "symmetrical" for 
scalar and complex. Let me know. Thanks.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D113107/new/

https://reviews.llvm.org/D113107

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D113107: Support of expression granularity for _Float16.

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam added a comment.

I think I introduced a bug when replacing the VisitUnaryMinus/Plus/Imag/Real 
with VisitMinus/Plus/Imag/Real. Now this simple test case is failing in the 
non-promotion path (with the +avx512fp16).

_Float16 _Complex MinusOp_c_c(_Float16 c) {

  return -c;

}

error: cannot compile this scalar expression yet

  return -c;
 ^~

1 error generated.

The way I implemented it is that I have added the HANDLE_UNOP macro but I think 
that's wrong. I think I need to keep the VisitUnary* methods and fork out of 
them in the promotion path!  Same for both Scalar and Complex Exprs. Your 
thoughts? 
Thanks.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D113107/new/

https://reviews.llvm.org/D113107

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D113107: Support of expression granularity for _Float16.

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam marked 2 inline comments as done.
zahiraam added inline comments.



Comment at: clang/lib/CodeGen/CGExprScalar.cpp:3140
+  return CGF.Builder.CreateFPExt(result, ConvertType(E->getType()));
+  }
+  return result;

rjmccall wrote:
> Please extract this block out as:
> 
> ```
> llvm::Value *EmitPromotedValue(llvm::Value *result, QualType PromotionType);
> ```
These changes you are proposing is when the argument of the unary __imag / 
__real is of type _Complex Float16. I would think that this new method 
EmitPromotedValue would be replacing the equivalent code in 
ComplexEmitter::EmitPromoted instead,  not in the scalar emitter, right?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D113107/new/

https://reviews.llvm.org/D113107

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D113107: Support of expression granularity for _Float16.

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam added inline comments.



Comment at: clang/lib/CodeGen/CGExprComplex.cpp:950
+ComplexExprEmitter::EmitPromotedComplexOperand(const Expr *E,
+   QualType PromotionType) {
+  if (E->getType()->isAnyComplexType()) {

rjmccall wrote:
> Maybe call this the `OverallPromotionType` to make it clear that it's not 
> necessarily the right promotion type for the operand (as in fact it isn't in 
> the scalar case).
Changed it, but not sure it makes it clearer.



Comment at: clang/lib/CodeGen/CGExprScalar.cpp:3112
+result = CGF.Builder.CreateFPExt(result, ConvertType(E->getType()));
+  return result;
+}

rjmccall wrote:
> The first version of the fallback path (the one in the `else`) is correct.  
> Like with the complex emitter, though, you've got a bug where fall through 
> from the earlier `switch` ends up in the second path; test case is something 
> like `f16 + (true, f16)`.
> 
> The best fix is to just not try to use `else` for your fallback path.  The 
> earlier blocks will return if they recognize cases that they can specially 
> handle; everything should fall out, and you handle everything that reaches 
> that point with the fallback path.
> 
> This code should check for `UnaryOperator` like it does for `BinaryOperator` 
> and delegate to your `_Real` / `_Imag` implementations above.  You should 
> probably also handle unary `+` and `-` so that using those does not cause 
> intermediate truncations.
OK. Fixed the fallback part. But I can't find a test case that would make me 
land into the switch for UnaryOperator . The code I added is not exercised. 
Would you mind suggesting a test case? Not sure about the f16 + (true, f16) 
above?



CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D113107/new/

https://reviews.llvm.org/D113107

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D113107: Support of expression granularity for _Float16.

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam added a comment.

@pengfei , @rjmccall  Thanks for the reviews. Sorry the updated patch took so 
long, I was on my sabbatical and returned back this week.
I think I have responded to all the raised issues. Let me know if there is more 
to be done on this patch.
Again thanks for the reviews.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D113107/new/

https://reviews.llvm.org/D113107

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D113107: Support of expression granularity for _Float16.

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam added inline comments.



Comment at: clang/test/CodeGen/X86/Float16-arithmetic.c:5-14
+  // CHECK-LABEL: @add1
+  // CHECK: [[A:%.*]] = alloca half
+  // CHECK-NEXT: [[B:%.*]] = alloca half
+  // CHECK: [[A_LOAD:%.*]] = load half, ptr [[A]]
+  // CHECK-NEXT: [[A_EXT:%.*]] = fpext half [[A_LOAD]] to float
+  // CHECK-NEXT: [[B_LOAD:%.*]] = load half, ptr [[B]]
+  // CHECK-NEXT: [[B_EXT:%.*]] = fpext half [[B_LOAD]] to float

pengfei wrote:
> Are these code generated manually? It can be updated by command 
> `llvm/utils/update_cc_test_checks.py 
> clang/test/CodeGen/X86/Float16-arithmetic.c`.
@pengfei Thanks. I didn't know about the script.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D113107/new/

https://reviews.llvm.org/D113107

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D113107: Support of expression granularity for _Float16.

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam updated this revision to Diff 451261.
zahiraam marked 7 inline comments as done.

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D113107/new/

https://reviews.llvm.org/D113107

Files:
  clang/docs/LanguageExtensions.rst
  clang/include/clang/Basic/TargetInfo.h
  clang/lib/Basic/Targets/X86.cpp
  clang/lib/Basic/Targets/X86.h
  clang/lib/CodeGen/CGExprComplex.cpp
  clang/lib/CodeGen/CGExprScalar.cpp
  clang/lib/CodeGen/CodeGenFunction.h
  clang/test/CodeGen/X86/Float16-arithmetic.c
  clang/test/CodeGen/X86/Float16-complex.c
  clang/test/Sema/Float16.c
  clang/test/SemaCXX/Float16.cpp

Index: clang/test/SemaCXX/Float16.cpp
===
--- clang/test/SemaCXX/Float16.cpp
+++ clang/test/SemaCXX/Float16.cpp
@@ -1,20 +1,10 @@
-// RUN: %clang_cc1 -fsyntax-only -verify -triple i686-linux-pc %s
-// RUN: %clang_cc1 -fsyntax-only -verify -triple i686-linux-pc -target-feature +sse2 %s -DHAVE
-// RUN: %clang_cc1 -fsyntax-only -verify -triple x86_64-linux-pc %s -DHAVE
-// RUN: %clang_cc1 -fsyntax-only -verify -triple spir-unknown-unknown %s -DHAVE
-// RUN: %clang_cc1 -fsyntax-only -verify -triple armv7a-linux-gnu %s -DHAVE
-// RUN: %clang_cc1 -fsyntax-only -verify -triple aarch64-linux-gnu %s -DHAVE
+// RUN: %clang_cc1 -fsyntax-only -verify -triple x86_64-linux-pc %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple spir-unknown-unknown %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple armv7a-linux-gnu %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple aarch64-linux-gnu %s
 
-#ifdef HAVE
 // expected-no-diagnostics
-#endif // HAVE
 
-#ifndef HAVE
-// expected-error@+2{{_Float16 is not supported on this target}}
-#endif // !HAVE
 _Float16 f;
 
-#ifndef HAVE
-// expected-error@+2{{invalid suffix 'F16' on floating constant}}
-#endif // !HAVE
 const auto g = 1.1F16;
Index: clang/test/Sema/Float16.c
===
--- clang/test/Sema/Float16.c
+++ clang/test/Sema/Float16.c
@@ -1,19 +1,15 @@
-// RUN: %clang_cc1 -fsyntax-only -verify -triple i686-linux-pc %s
-// RUN: %clang_cc1 -fsyntax-only -verify -triple i686-linux-pc -target-feature +sse2 %s -DHAVE
-// RUN: %clang_cc1 -fsyntax-only -verify -triple x86_64-linux-pc %s -DHAVE
-// RUN: %clang_cc1 -fsyntax-only -verify -triple spir-unknown-unknown %s -DHAVE
-// RUN: %clang_cc1 -fsyntax-only -verify -triple armv7a-linux-gnu %s -DHAVE
-// RUN: %clang_cc1 -fsyntax-only -verify -triple aarch64-linux-gnu %s -DHAVE
+// RUN: %clang_cc1 -fsyntax-only -verify -triple x86_64-linux-pc %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple x86_64-linux-pc -target-feature +avx512fp16 %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple spir-unknown-unknown %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple armv7a-linux-gnu %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple aarch64-linux-gnu %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple x86_64-linux-pc -target-feature +avx512fp16 %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple spir-unknown-unknown %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple armv7a-linux-gnu %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple aarch64-linux-gnu %s
 
-#ifndef HAVE
-// expected-error@+2{{_Float16 is not supported on this target}}
-#endif // HAVE
-_Float16 f;
-
-#ifdef HAVE
 _Complex _Float16 a;
 void builtin_complex(void) {
   _Float16 a = 0;
   (void)__builtin_complex(a, a); // expected-error {{'_Complex _Float16' is invalid}}
 }
-#endif
Index: clang/test/CodeGen/X86/Float16-complex.c
===
--- clang/test/CodeGen/X86/Float16-complex.c
+++ clang/test/CodeGen/X86/Float16-complex.c
@@ -1,134 +1,995 @@
-// RUN: %clang_cc1 %s -O0 -emit-llvm -triple x86_64-unknown-unknown -target-feature +avx512fp16 -o - | FileCheck %s --check-prefix=X86
-// RUN: %clang_cc1 %s -O0 -emit-llvm -triple x86_64-unknown-unknown -o - | FileCheck %s --check-prefix=X86
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
+// RUN: %clang_cc1 %s -O0 -emit-llvm -triple x86_64-unknown-unknown -target-feature +avx512fp16 -o - | FileCheck %s --check-prefixes=AVX
+// RUN: %clang_cc1 %s -O0 -emit-llvm -triple x86_64-unknown-unknown -o - | FileCheck %s --check-prefixes=X86
 
+// AVX-LABEL: @add_half_rr(
+// AVX-NEXT:  entry:
+// AVX-NEXT:[[RETVAL:%.*]] = alloca { half, half }, align 2
+// AVX-NEXT:[[A_ADDR:%.*]] = alloca half, align 2
+// AVX-NEXT:[[B_ADDR:%.*]] = alloca half, align 2
+// AVX-NEXT:store half [[A:%.*]], ptr [[A_ADDR]], align 2
+// AVX-NEXT:store half [[B:%.*]], ptr [[B_ADDR]], align 2
+// AVX-NEXT:[[TMP0:%.*]] = load half, ptr [[A_ADDR]], align 2
+// AVX-NEXT:[[TMP1:%.*]] = load half, ptr [[B_ADDR]], align 2
+// AVX-NEXT:[[ADD:%.*]] = fadd half [[TMP0]], [[TMP1]]
+// AVX-NEXT:[[RETVAL_REALP:%.*]] = getelementptr inbounds { half, half }, ptr [[RETVAL]], i32 0, i32 0
+// AVX-NEXT:[[RETVAL_IMAGP:%.*]] = 

[PATCH] D113107: Support of expression granularity for _Float16.

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam added a comment.

Refactored the code as requested and fixed the compound operator promotion for 
scalar.
The operators that are left to complete are compound operators for complex type 
and ternary operator for scalar and complex types.
Then we need to add the option -fexcess-precision. I am not sure for now where 
and what values the _FLT_EVAL_METHOD should have when excess  precision is 
enabled/disabled.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D113107/new/

https://reviews.llvm.org/D113107

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D113107: Support of expression granularity for _Float16.

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam updated this revision to Diff 441702.
zahiraam marked 7 inline comments as done.

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D113107/new/

https://reviews.llvm.org/D113107

Files:
  clang/docs/LanguageExtensions.rst
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/TargetInfo.h
  clang/lib/Basic/Targets/X86.cpp
  clang/lib/Basic/Targets/X86.h
  clang/lib/CodeGen/CGExprComplex.cpp
  clang/lib/CodeGen/CGExprScalar.cpp
  clang/lib/CodeGen/CodeGenFunction.h
  clang/test/CodeGen/X86/Float16-arithmetic.c
  clang/test/CodeGen/X86/Float16-complex.c
  clang/test/Sema/Float16.c
  clang/test/SemaCXX/Float16.cpp

Index: clang/test/SemaCXX/Float16.cpp
===
--- clang/test/SemaCXX/Float16.cpp
+++ clang/test/SemaCXX/Float16.cpp
@@ -1,20 +1,10 @@
-// RUN: %clang_cc1 -fsyntax-only -verify -triple i686-linux-pc %s
-// RUN: %clang_cc1 -fsyntax-only -verify -triple i686-linux-pc -target-feature +sse2 %s -DHAVE
-// RUN: %clang_cc1 -fsyntax-only -verify -triple x86_64-linux-pc %s -DHAVE
-// RUN: %clang_cc1 -fsyntax-only -verify -triple spir-unknown-unknown %s -DHAVE
-// RUN: %clang_cc1 -fsyntax-only -verify -triple armv7a-linux-gnu %s -DHAVE
-// RUN: %clang_cc1 -fsyntax-only -verify -triple aarch64-linux-gnu %s -DHAVE
+// RUN: %clang_cc1 -fsyntax-only -verify -triple x86_64-linux-pc %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple spir-unknown-unknown %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple armv7a-linux-gnu %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple aarch64-linux-gnu %s
 
-#ifdef HAVE
 // expected-no-diagnostics
-#endif // HAVE
 
-#ifndef HAVE
-// expected-error@+2{{_Float16 is not supported on this target}}
-#endif // !HAVE
 _Float16 f;
 
-#ifndef HAVE
-// expected-error@+2{{invalid suffix 'F16' on floating constant}}
-#endif // !HAVE
 const auto g = 1.1F16;
Index: clang/test/Sema/Float16.c
===
--- clang/test/Sema/Float16.c
+++ clang/test/Sema/Float16.c
@@ -1,19 +1,15 @@
-// RUN: %clang_cc1 -fsyntax-only -verify -triple i686-linux-pc %s
-// RUN: %clang_cc1 -fsyntax-only -verify -triple i686-linux-pc -target-feature +sse2 %s -DHAVE
-// RUN: %clang_cc1 -fsyntax-only -verify -triple x86_64-linux-pc %s -DHAVE
-// RUN: %clang_cc1 -fsyntax-only -verify -triple spir-unknown-unknown %s -DHAVE
-// RUN: %clang_cc1 -fsyntax-only -verify -triple armv7a-linux-gnu %s -DHAVE
-// RUN: %clang_cc1 -fsyntax-only -verify -triple aarch64-linux-gnu %s -DHAVE
+// RUN: %clang_cc1 -fsyntax-only -verify -triple x86_64-linux-pc %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple x86_64-linux-pc -target-feature +avx512fp16 %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple spir-unknown-unknown %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple armv7a-linux-gnu %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple aarch64-linux-gnu %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple x86_64-linux-pc -target-feature +avx512fp16 %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple spir-unknown-unknown %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple armv7a-linux-gnu %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple aarch64-linux-gnu %s
 
-#ifndef HAVE
-// expected-error@+2{{_Float16 is not supported on this target}}
-#endif // HAVE
-_Float16 f;
-
-#ifdef HAVE
 _Complex _Float16 a;
 void builtin_complex(void) {
   _Float16 a = 0;
   (void)__builtin_complex(a, a); // expected-error {{'_Complex _Float16' is invalid}}
 }
-#endif
Index: clang/test/CodeGen/X86/Float16-complex.c
===
--- clang/test/CodeGen/X86/Float16-complex.c
+++ clang/test/CodeGen/X86/Float16-complex.c
@@ -1,134 +1,422 @@
-// RUN: %clang_cc1 %s -O0 -emit-llvm -triple x86_64-unknown-unknown -target-feature +avx512fp16 -o - | FileCheck %s --check-prefix=X86
-// RUN: %clang_cc1 %s -O0 -emit-llvm -triple x86_64-unknown-unknown -o - | FileCheck %s --check-prefix=X86
+// RUN: %clang_cc1 %s -O0 -emit-llvm -triple x86_64-unknown-unknown -target-feature +avx512fp16 -o - | FileCheck %s --check-prefixes=CHECK,AVX
+// RUN: %clang_cc1 %s -O0 -emit-llvm -triple x86_64-unknown-unknown -o - | FileCheck %s --check-prefixes=CHECK,X86
 
 _Float16 _Complex add_half_rr(_Float16 a, _Float16 b) {
-  // X86-LABEL: @add_half_rr(
-  // X86: fadd
-  // X86-NOT: fadd
-  // X86: ret
+  // CHECK-LABEL: @add_half_rr(
+  // CHECK: [[A:%.*]] = alloca half
+  // CHECK-NEXT: [[B:%.*]] = alloca half
+  // CHECK: [[A_LOAD:%.*]] = load half, ptr [[A]]
+
+  // AVX-NEXT: [[B_LOAD:%.*]] = load half, ptr [[B]]
+  // AVX-NEXT: [[AB_ADD:%.*]] = fadd half [[A_LOAD]], [[B_LOAD]]
+  // AVX: store half [[AB_ADD]], {{.*}}
+
+  // X86-NEXT: [[A_EXT:%.*]] = fpext half [[A_LOAD]] to float
+  // X86-NEXT: [[B_LOAD:%.*]] = load half, ptr [[B]]
+  // X86-NEXT: [[B_EXT:%.*]] = fpext half [[B_LOAD]] to float
+  // X86-NEXT: [[AB_ADD:%.*]] = fadd float [[A_EXT]], [[B_EXT]]
+  // X86-NEXT: 

[PATCH] D113107: Support of expression granularity for _Float16.

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam updated this revision to Diff 441169.

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D113107/new/

https://reviews.llvm.org/D113107

Files:
  clang/docs/LanguageExtensions.rst
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/TargetInfo.h
  clang/lib/Basic/Targets/X86.cpp
  clang/lib/Basic/Targets/X86.h
  clang/lib/CodeGen/CGExprComplex.cpp
  clang/lib/CodeGen/CGExprScalar.cpp
  clang/lib/CodeGen/CodeGenFunction.h
  clang/test/CodeGen/X86/Float16-arithmetic.c
  clang/test/CodeGen/X86/Float16-complex.c
  clang/test/Sema/Float16.c
  clang/test/SemaCXX/Float16.cpp

Index: clang/test/SemaCXX/Float16.cpp
===
--- clang/test/SemaCXX/Float16.cpp
+++ clang/test/SemaCXX/Float16.cpp
@@ -1,20 +1,10 @@
-// RUN: %clang_cc1 -fsyntax-only -verify -triple i686-linux-pc %s
-// RUN: %clang_cc1 -fsyntax-only -verify -triple i686-linux-pc -target-feature +sse2 %s -DHAVE
-// RUN: %clang_cc1 -fsyntax-only -verify -triple x86_64-linux-pc %s -DHAVE
-// RUN: %clang_cc1 -fsyntax-only -verify -triple spir-unknown-unknown %s -DHAVE
-// RUN: %clang_cc1 -fsyntax-only -verify -triple armv7a-linux-gnu %s -DHAVE
-// RUN: %clang_cc1 -fsyntax-only -verify -triple aarch64-linux-gnu %s -DHAVE
+// RUN: %clang_cc1 -fsyntax-only -verify -triple x86_64-linux-pc %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple spir-unknown-unknown %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple armv7a-linux-gnu %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple aarch64-linux-gnu %s
 
-#ifdef HAVE
 // expected-no-diagnostics
-#endif // HAVE
 
-#ifndef HAVE
-// expected-error@+2{{_Float16 is not supported on this target}}
-#endif // !HAVE
 _Float16 f;
 
-#ifndef HAVE
-// expected-error@+2{{invalid suffix 'F16' on floating constant}}
-#endif // !HAVE
 const auto g = 1.1F16;
Index: clang/test/Sema/Float16.c
===
--- clang/test/Sema/Float16.c
+++ clang/test/Sema/Float16.c
@@ -1,19 +1,15 @@
-// RUN: %clang_cc1 -fsyntax-only -verify -triple i686-linux-pc %s
-// RUN: %clang_cc1 -fsyntax-only -verify -triple i686-linux-pc -target-feature +sse2 %s -DHAVE
-// RUN: %clang_cc1 -fsyntax-only -verify -triple x86_64-linux-pc %s -DHAVE
-// RUN: %clang_cc1 -fsyntax-only -verify -triple spir-unknown-unknown %s -DHAVE
-// RUN: %clang_cc1 -fsyntax-only -verify -triple armv7a-linux-gnu %s -DHAVE
-// RUN: %clang_cc1 -fsyntax-only -verify -triple aarch64-linux-gnu %s -DHAVE
+// RUN: %clang_cc1 -fsyntax-only -verify -triple x86_64-linux-pc %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple x86_64-linux-pc -target-feature +avx512fp16 %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple spir-unknown-unknown %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple armv7a-linux-gnu %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple aarch64-linux-gnu %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple x86_64-linux-pc -target-feature +avx512fp16 %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple spir-unknown-unknown %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple armv7a-linux-gnu %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple aarch64-linux-gnu %s
 
-#ifndef HAVE
-// expected-error@+2{{_Float16 is not supported on this target}}
-#endif // HAVE
-_Float16 f;
-
-#ifdef HAVE
 _Complex _Float16 a;
 void builtin_complex(void) {
   _Float16 a = 0;
   (void)__builtin_complex(a, a); // expected-error {{'_Complex _Float16' is invalid}}
 }
-#endif
Index: clang/test/CodeGen/X86/Float16-complex.c
===
--- clang/test/CodeGen/X86/Float16-complex.c
+++ clang/test/CodeGen/X86/Float16-complex.c
@@ -1,134 +1,407 @@
-// RUN: %clang_cc1 %s -O0 -emit-llvm -triple x86_64-unknown-unknown -target-feature +avx512fp16 -o - | FileCheck %s --check-prefix=X86
-// RUN: %clang_cc1 %s -O0 -emit-llvm -triple x86_64-unknown-unknown -o - | FileCheck %s --check-prefix=X86
+// RUN: %clang_cc1 %s -O0 -emit-llvm -triple x86_64-unknown-unknown -target-feature +avx512fp16 -o - | FileCheck %s --check-prefixes=CHECK,AVX
+// RUN: %clang_cc1 %s -O0 -emit-llvm -triple x86_64-unknown-unknown -o - | FileCheck %s --check-prefixes=CHECK,X86
 
 _Float16 _Complex add_half_rr(_Float16 a, _Float16 b) {
-  // X86-LABEL: @add_half_rr(
-  // X86: fadd
-  // X86-NOT: fadd
-  // X86: ret
+  // CHECK-LABEL: @add_half_rr(
+  // CHECK: [[A:%.*]] = alloca half
+  // CHECK-NEXT: [[B:%.*]] = alloca half
+  // CHECK: [[A_LOAD:%.*]] = load half, ptr [[A]]
+
+  // AVX-NEXT: [[B_LOAD:%.*]] = load half, ptr [[B]]
+  // AVX-NEXT: [[AB_ADD:%.*]] = fadd half [[A_LOAD]], [[B_LOAD]]
+  // AVX: store half [[AB_ADD]], {{.*}}
+
+  // X86-NEXT: [[A_EXT:%.*]] = fpext half [[A_LOAD]] to float
+  // X86-NEXT: [[B_LOAD:%.*]] = load half, ptr [[B]]
+  // X86-NEXT: [[B_EXT:%.*]] = fpext half [[B_LOAD]] to float
+  // X86-NEXT: [[AB_ADD:%.*]] = fadd float [[A_EXT]], [[B_EXT]]
+  // X86-NEXT: [[AB_ADD_TRUNC:%.*]] = fptrunc float [[AB_ADD]] to half

[PATCH] D113107: Support of expression granularity for _Float16.

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam added a comment.

Fixed LIT tests. Fixed EmitPromoted for the Complex emitter (not 100% sure 
about it?). Added compound operator scalar emulation.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D113107/new/

https://reviews.llvm.org/D113107

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D113107: Support of expression granularity for _Float16.

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam updated this revision to Diff 441167.
zahiraam marked 2 inline comments as done.

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D113107/new/

https://reviews.llvm.org/D113107

Files:
  clang/docs/LanguageExtensions.rst
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/TargetInfo.h
  clang/lib/Basic/Targets/X86.cpp
  clang/lib/Basic/Targets/X86.h
  clang/lib/CodeGen/CGExprComplex.cpp
  clang/lib/CodeGen/CGExprScalar.cpp
  clang/lib/CodeGen/CodeGenFunction.h
  clang/test/CodeGen/X86/Float16-arithmetic.c
  clang/test/CodeGen/X86/Float16-complex.c
  clang/test/Sema/Float16.c
  clang/test/SemaCXX/Float16.cpp

Index: clang/test/SemaCXX/Float16.cpp
===
--- clang/test/SemaCXX/Float16.cpp
+++ clang/test/SemaCXX/Float16.cpp
@@ -1,20 +1,10 @@
-// RUN: %clang_cc1 -fsyntax-only -verify -triple i686-linux-pc %s
-// RUN: %clang_cc1 -fsyntax-only -verify -triple i686-linux-pc -target-feature +sse2 %s -DHAVE
-// RUN: %clang_cc1 -fsyntax-only -verify -triple x86_64-linux-pc %s -DHAVE
-// RUN: %clang_cc1 -fsyntax-only -verify -triple spir-unknown-unknown %s -DHAVE
-// RUN: %clang_cc1 -fsyntax-only -verify -triple armv7a-linux-gnu %s -DHAVE
-// RUN: %clang_cc1 -fsyntax-only -verify -triple aarch64-linux-gnu %s -DHAVE
+// RUN: %clang_cc1 -fsyntax-only -verify -triple x86_64-linux-pc %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple spir-unknown-unknown %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple armv7a-linux-gnu %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple aarch64-linux-gnu %s
 
-#ifdef HAVE
 // expected-no-diagnostics
-#endif // HAVE
 
-#ifndef HAVE
-// expected-error@+2{{_Float16 is not supported on this target}}
-#endif // !HAVE
 _Float16 f;
 
-#ifndef HAVE
-// expected-error@+2{{invalid suffix 'F16' on floating constant}}
-#endif // !HAVE
 const auto g = 1.1F16;
Index: clang/test/Sema/Float16.c
===
--- clang/test/Sema/Float16.c
+++ clang/test/Sema/Float16.c
@@ -1,19 +1,23 @@
+<<< HEAD
 // RUN: %clang_cc1 -fsyntax-only -verify -triple i686-linux-pc %s
 // RUN: %clang_cc1 -fsyntax-only -verify -triple i686-linux-pc -target-feature +sse2 %s -DHAVE
 // RUN: %clang_cc1 -fsyntax-only -verify -triple x86_64-linux-pc %s -DHAVE
 // RUN: %clang_cc1 -fsyntax-only -verify -triple spir-unknown-unknown %s -DHAVE
 // RUN: %clang_cc1 -fsyntax-only -verify -triple armv7a-linux-gnu %s -DHAVE
 // RUN: %clang_cc1 -fsyntax-only -verify -triple aarch64-linux-gnu %s -DHAVE
+===
+// RUN: %clang_cc1 -fsyntax-only -verify -triple x86_64-linux-pc %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple x86_64-linux-pc -target-feature +avx512fp16 %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple spir-unknown-unknown %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple armv7a-linux-gnu %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple aarch64-linux-gnu %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple x86_64-linux-pc -target-feature +avx512fp16 %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple spir-unknown-unknown %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple armv7a-linux-gnu %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple aarch64-linux-gnu %s
 
-#ifndef HAVE
-// expected-error@+2{{_Float16 is not supported on this target}}
-#endif // HAVE
-_Float16 f;
-
-#ifdef HAVE
 _Complex _Float16 a;
 void builtin_complex(void) {
   _Float16 a = 0;
   (void)__builtin_complex(a, a); // expected-error {{'_Complex _Float16' is invalid}}
 }
-#endif
Index: clang/test/CodeGen/X86/Float16-complex.c
===
--- clang/test/CodeGen/X86/Float16-complex.c
+++ clang/test/CodeGen/X86/Float16-complex.c
@@ -1,134 +1,407 @@
-// RUN: %clang_cc1 %s -O0 -emit-llvm -triple x86_64-unknown-unknown -target-feature +avx512fp16 -o - | FileCheck %s --check-prefix=X86
-// RUN: %clang_cc1 %s -O0 -emit-llvm -triple x86_64-unknown-unknown -o - | FileCheck %s --check-prefix=X86
+// RUN: %clang_cc1 %s -O0 -emit-llvm -triple x86_64-unknown-unknown -target-feature +avx512fp16 -o - | FileCheck %s --check-prefixes=CHECK,AVX
+// RUN: %clang_cc1 %s -O0 -emit-llvm -triple x86_64-unknown-unknown -o - | FileCheck %s --check-prefixes=CHECK,X86
 
 _Float16 _Complex add_half_rr(_Float16 a, _Float16 b) {
-  // X86-LABEL: @add_half_rr(
-  // X86: fadd
-  // X86-NOT: fadd
-  // X86: ret
+  // CHECK-LABEL: @add_half_rr(
+  // CHECK: [[A:%.*]] = alloca half
+  // CHECK-NEXT: [[B:%.*]] = alloca half
+  // CHECK: [[A_LOAD:%.*]] = load half, ptr [[A]]
+
+  // AVX-NEXT: [[B_LOAD:%.*]] = load half, ptr [[B]]
+  // AVX-NEXT: [[AB_ADD:%.*]] = fadd half [[A_LOAD]], [[B_LOAD]]
+  // AVX: store half [[AB_ADD]], {{.*}}
+
+  // X86-NEXT: [[A_EXT:%.*]] = fpext half [[A_LOAD]] to float
+  // X86-NEXT: [[B_LOAD:%.*]] = load half, ptr [[B]]
+  // X86-NEXT: [[B_EXT:%.*]] = fpext half [[B_LOAD]] to float
+  // X86-NEXT: [[AB_ADD:%.*]] = fadd float [[A_EXT]], [[B_EXT]]
+  // 

[PATCH] D113107: Support of expression granularity for _Float16.

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam added a comment.

In D113107#3615372 , @zahiraam wrote:

> In D113107#3606106 , @rjmccall 
> wrote:
>
>> In D113107#3606094 , @zahiraam 
>> wrote:
>>
>>> In D113107#3605797 , @rjmccall 
>>> wrote:
>>>
 I think on balance the right thing to do is probably to add an alternative 
 to `-fexcess-precision`, like `-fexcess-precision=none`.  We can default 
 to `-fexcess-precision=standard` and treat `-fexcess-precision=fast` as an 
 alias for `standard` for now.
>>>
>>> In 
>>> https://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/Optimize-Options.html#index-ffloat-store-900
>>>  ,  it looks like when compiling C, the default is 
>>> -fexcess-precision=standard which would align with this implementation and 
>>> our default too. So I think we could use the same name for the option. 
>>> -fexcess-precision=none corresponds to the current behavior.
>>> -fexcess-precision=standard = -fexcess-precision=fast corresponds to this 
>>> implementation.
>>> Agreed?
>>
>> Since you're not landing this option right now anyway, do you mind broaching 
>> this with the GCC folks, just to be good neighbors?  You can just say that 
>> (1) Clang is looking for a way to request operation-by-operation lowering, 
>> (2) it feels like `-fexcess-precision` is the right option to add that to, 
>> (3) we don't want to tread on toes by adding an alternative to "their" 
>> option without talking to them first, and (4) what do they think about 
>> "none"?
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106117

In GCC using no -fexcess-precision is the same than using 
-fexcess-precision=standard. The patch we are proposing here is implementing 
this part.  So for  a + b + c, we are generating (_Float16) [((float a) + 
(float b)) + (float c)]
In GCC using -fexcess-precision=16 is generating yet another flavor of the 
operation-by-operation emulation. For the same addition than above, gcc is 
generating (_Float16) [(float) (_Float16) ((float a) + (float b)) + (float c)]. 
That's different than our current implementation.
See https://godbolt.org/z/aM8fzTsj1
Am I understanding correctly? @pengfei you are interested in the 
-fexcess-precision=16 part of this right? @rjmccall what do yo think?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D113107/new/

https://reviews.llvm.org/D113107

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D128814: [Clang][Preprocessor] Fix inconsistent `FLT_EVAL_METHOD` when compiling vs preprocessing

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam added a comment.

Took the time to test the change on a few "crooked" tests I had used for the 
original patch. It works! LGTM.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D128814/new/

https://reviews.llvm.org/D128814

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D113107: Support of expression granularity for _Float16.

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam marked an inline comment as done.
zahiraam added a comment.

In D113107#3606106 , @rjmccall wrote:

> In D113107#3606094 , @zahiraam 
> wrote:
>
>> In D113107#3605797 , @rjmccall 
>> wrote:
>>
>>> I think on balance the right thing to do is probably to add an alternative 
>>> to `-fexcess-precision`, like `-fexcess-precision=none`.  We can default to 
>>> `-fexcess-precision=standard` and treat `-fexcess-precision=fast` as an 
>>> alias for `standard` for now.
>>
>> In 
>> https://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/Optimize-Options.html#index-ffloat-store-900
>>  ,  it looks like when compiling C, the default is 
>> -fexcess-precision=standard which would align with this implementation and 
>> our default too. So I think we could use the same name for the option. 
>> -fexcess-precision=none corresponds to the current behavior.
>> -fexcess-precision=standard = -fexcess-precision=fast corresponds to this 
>> implementation.
>> Agreed?
>
> Since you're not landing this option right now anyway, do you mind broaching 
> this with the GCC folks, just to be good neighbors?  You can just say that 
> (1) Clang is looking for a way to request operation-by-operation lowering, 
> (2) it feels like `-fexcess-precision` is the right option to add that to, 
> (3) we don't want to tread on toes by adding an alternative to "their" option 
> without talking to them first, and (4) what do they think about "none"?

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106117


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D113107/new/

https://reviews.llvm.org/D113107

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D128571: [X86] Support `_Float16` on SSE2 and up

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam accepted this revision.
zahiraam added a comment.

LGTM.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D128571/new/

https://reviews.llvm.org/D128571

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D113107: Support of expression granularity for _Float16.

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam added a comment.

For this test case:
_Float16 add_half_cr(_Float16 a, _Float16 b) {

  return a > b ? a : b;

}

are we expecting the phi node to be

cond.true:

  %2 = load float , ptr 
  ...

cond.false:

  %3 = load float, ptr
  ...

%cond = phi float {{.*}} {{.*}}

?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D113107/new/

https://reviews.llvm.org/D113107

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D113107: Support of expression granularity for _Float16.

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam added a comment.

In D113107#3605797 , @rjmccall wrote:

> I think on balance the right thing to do is probably to add an alternative to 
> `-fexcess-precision`, like `-fexcess-precision=none`.  We can default to 
> `-fexcess-precision=standard` and treat `-fexcess-precision=fast` as an alias 
> for `standard` for now.

In 
https://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/Optimize-Options.html#index-ffloat-store-900
 ,  it looks like when compiling C, the default is -fexcess-precision=standard 
which would align with this implementation and our default too. So I think we 
could use the same name for the option. 
-fexcess-precision=none corresponds to the current behavior.
-fexcess-precision=standard = -fexcess-precision=fast corresponds to this 
implementation.
Agreed?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D113107/new/

https://reviews.llvm.org/D113107

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D113107: Support of expression granularity for _Float16.

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam added inline comments.



Comment at: clang/docs/LanguageExtensions.rst:746
 * SPIR
-* X86 (Only available under feature AVX512-FP16)
+* X86 (Enabled with feature SSE2 and up)
 

rjmccall wrote:
> Note that I'm not trying to propose this specific name for the option; I'm 
> just saying that, if we provide a way to control this, it should be 
> documented here as the central place we document Clang's `_Float16` support.
@rjmccall I have added the text except the last line.  I will add it later with 
the option. 


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D113107/new/

https://reviews.llvm.org/D113107

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D113107: Support of expression granularity for _Float16.

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam updated this revision to Diff 439502.
zahiraam marked 2 inline comments as done.

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D113107/new/

https://reviews.llvm.org/D113107

Files:
  clang/docs/LanguageExtensions.rst
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/TargetInfo.h
  clang/lib/Basic/Targets/X86.cpp
  clang/lib/Basic/Targets/X86.h
  clang/lib/CodeGen/CGExprComplex.cpp
  clang/lib/CodeGen/CGExprScalar.cpp
  clang/lib/CodeGen/CodeGenFunction.h
  clang/test/CodeGen/X86/Float16-arithmetic.c
  clang/test/CodeGen/X86/Float16-complex.c
  clang/test/CodeGen/X86/avx512fp16-complex.c
  clang/test/Sema/Float16.c
  clang/test/Sema/conversion-target-dep.c
  clang/test/SemaCXX/Float16.cpp

Index: clang/test/SemaCXX/Float16.cpp
===
--- clang/test/SemaCXX/Float16.cpp
+++ clang/test/SemaCXX/Float16.cpp
@@ -1,18 +1,10 @@
 // RUN: %clang_cc1 -fsyntax-only -verify -triple x86_64-linux-pc %s
-// RUN: %clang_cc1 -fsyntax-only -verify -triple spir-unknown-unknown %s -DHAVE
-// RUN: %clang_cc1 -fsyntax-only -verify -triple armv7a-linux-gnu %s -DHAVE
-// RUN: %clang_cc1 -fsyntax-only -verify -triple aarch64-linux-gnu %s -DHAVE
+// RUN: %clang_cc1 -fsyntax-only -verify -triple spir-unknown-unknown %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple armv7a-linux-gnu %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple aarch64-linux-gnu %s
 
-#ifdef HAVE
 // expected-no-diagnostics
-#endif // HAVE
 
-#ifndef HAVE
-// expected-error@+2{{_Float16 is not supported on this target}}
-#endif // !HAVE
 _Float16 f;
 
-#ifndef HAVE
-// expected-error@+2{{invalid suffix 'F16' on floating constant}}
-#endif // !HAVE
 const auto g = 1.1F16;
Index: clang/test/Sema/conversion-target-dep.c
===
--- clang/test/Sema/conversion-target-dep.c
+++ clang/test/Sema/conversion-target-dep.c
@@ -6,7 +6,7 @@
 
 long double ld;
 double d;
-_Float16 f16; // x86-error {{_Float16 is not supported on this target}}
+_Float16 f16;
 
 int main(void) {
   ld = d; // x86-warning {{implicit conversion increases floating-point precision: 'double' to 'long double'}}
Index: clang/test/Sema/Float16.c
===
--- clang/test/Sema/Float16.c
+++ clang/test/Sema/Float16.c
@@ -1,18 +1,11 @@
 // RUN: %clang_cc1 -fsyntax-only -verify -triple x86_64-linux-pc %s
-// RUN: %clang_cc1 -fsyntax-only -verify -triple x86_64-linux-pc -target-feature +avx512fp16 %s -DHAVE
-// RUN: %clang_cc1 -fsyntax-only -verify -triple spir-unknown-unknown %s -DHAVE
-// RUN: %clang_cc1 -fsyntax-only -verify -triple armv7a-linux-gnu %s -DHAVE
-// RUN: %clang_cc1 -fsyntax-only -verify -triple aarch64-linux-gnu %s -DHAVE
+// RUN: %clang_cc1 -fsyntax-only -verify -triple x86_64-linux-pc -target-feature +avx512fp16 %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple spir-unknown-unknown %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple armv7a-linux-gnu %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple aarch64-linux-gnu %s
 
-#ifndef HAVE
-// expected-error@+2{{_Float16 is not supported on this target}}
-#endif // HAVE
-_Float16 f;
-
-#ifdef HAVE
 _Complex _Float16 a;
 void builtin_complex(void) {
   _Float16 a = 0;
   (void)__builtin_complex(a, a); // expected-error {{'_Complex _Float16' is invalid}}
 }
-#endif
Index: clang/test/CodeGen/X86/Float16-complex.c
===
--- clang/test/CodeGen/X86/Float16-complex.c
+++ clang/test/CodeGen/X86/Float16-complex.c
@@ -1,4 +1,5 @@
 // RUN: %clang_cc1 %s -O0 -emit-llvm -triple x86_64-unknown-unknown -target-feature +avx512fp16 -o - | FileCheck %s --check-prefix=X86
+// RUN: %clang_cc1 %s -O0 -emit-llvm -triple x86_64-unknown-unknown -o - | FileCheck %s --check-prefixes=X86-PROM
 
 _Float16 _Complex add_half_rr(_Float16 a, _Float16 b) {
   // X86-LABEL: @add_half_rr(
@@ -85,7 +86,29 @@
   return a * b;
 }
 _Float16 _Complex mul_half_cc(_Float16 _Complex a, _Float16 _Complex b) {
-  // X86-LABEL: @mul_half_cc(
+  // CHECK: @mul_half_cc(
+
+  // X86-PROM: fpext half {{.*}} to float
+  // X86-PROM: fpext half {{.*}} to float
+  // X86-PROM: fpext half {{.*}} to float
+  // X86-PROM: fpext half {{.*}} to float
+  // X86-PROM: %[[AC:[^ ]+]] = fmul float
+  // X86-PROM: %[[BD:[^ ]+]] = fmul float
+  // X86-PROM: %[[AD:[^ ]+]] = fmul float
+  // X86-PROM: %[[BC:[^ ]+]] = fmul float
+  // X86-PROM: %[[RR:[^ ]+]] = fsub float
+  // X86-PROM: %[[RI:[^ ]+]] = fadd float
+  // X86-PROM: fcmp uno float %[[RR]]
+  // X86-PROM: fcmp uno float %[[RI]]
+  // X86-PROM: call <2 x float> @__mulsc3(
+  // X86-PROM: fptrunc float {{.*}} to half
+  // X86-PROM: fptrunc float {{.*}} to half
+  // X86-PROM: %[[RETR:[^ ]+]] = getelementptr inbounds { half, half }
+  // X86-PROM: %[[RETI:[^ ]+]] = getelementptr inbounds { half, half }
+  // X86-PROM: store half {{.*}}, ptr %[[RETR]]
+  // X86-PROM: store half 

[PATCH] D113107: Support of expression granularity for _Float16.

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam updated this revision to Diff 439385.

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D113107/new/

https://reviews.llvm.org/D113107

Files:
  clang/docs/LanguageExtensions.rst
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/TargetInfo.h
  clang/lib/Basic/Targets/X86.cpp
  clang/lib/Basic/Targets/X86.h
  clang/lib/CodeGen/CGExprComplex.cpp
  clang/lib/CodeGen/CGExprScalar.cpp
  clang/lib/CodeGen/CodeGenFunction.h
  clang/test/CodeGen/X86/Float16-arithmetic.c
  clang/test/CodeGen/X86/Float16-complex.c
  clang/test/CodeGen/X86/avx512fp16-complex.c
  clang/test/Sema/Float16.c
  clang/test/Sema/conversion-target-dep.c
  clang/test/SemaCXX/Float16.cpp

Index: clang/test/SemaCXX/Float16.cpp
===
--- clang/test/SemaCXX/Float16.cpp
+++ clang/test/SemaCXX/Float16.cpp
@@ -1,18 +1,10 @@
 // RUN: %clang_cc1 -fsyntax-only -verify -triple x86_64-linux-pc %s
-// RUN: %clang_cc1 -fsyntax-only -verify -triple spir-unknown-unknown %s -DHAVE
-// RUN: %clang_cc1 -fsyntax-only -verify -triple armv7a-linux-gnu %s -DHAVE
-// RUN: %clang_cc1 -fsyntax-only -verify -triple aarch64-linux-gnu %s -DHAVE
+// RUN: %clang_cc1 -fsyntax-only -verify -triple spir-unknown-unknown %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple armv7a-linux-gnu %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple aarch64-linux-gnu %s
 
-#ifdef HAVE
 // expected-no-diagnostics
-#endif // HAVE
 
-#ifndef HAVE
-// expected-error@+2{{_Float16 is not supported on this target}}
-#endif // !HAVE
 _Float16 f;
 
-#ifndef HAVE
-// expected-error@+2{{invalid suffix 'F16' on floating constant}}
-#endif // !HAVE
 const auto g = 1.1F16;
Index: clang/test/Sema/conversion-target-dep.c
===
--- clang/test/Sema/conversion-target-dep.c
+++ clang/test/Sema/conversion-target-dep.c
@@ -6,7 +6,7 @@
 
 long double ld;
 double d;
-_Float16 f16; // x86-error {{_Float16 is not supported on this target}}
+_Float16 f16;
 
 int main(void) {
   ld = d; // x86-warning {{implicit conversion increases floating-point precision: 'double' to 'long double'}}
Index: clang/test/Sema/Float16.c
===
--- clang/test/Sema/Float16.c
+++ clang/test/Sema/Float16.c
@@ -1,18 +1,12 @@
 // RUN: %clang_cc1 -fsyntax-only -verify -triple x86_64-linux-pc %s
-// RUN: %clang_cc1 -fsyntax-only -verify -triple x86_64-linux-pc -target-feature +avx512fp16 %s -DHAVE
-// RUN: %clang_cc1 -fsyntax-only -verify -triple spir-unknown-unknown %s -DHAVE
-// RUN: %clang_cc1 -fsyntax-only -verify -triple armv7a-linux-gnu %s -DHAVE
-// RUN: %clang_cc1 -fsyntax-only -verify -triple aarch64-linux-gnu %s -DHAVE
+// RUN: %clang_cc1 -fsyntax-only -verify -triple x86_64-linux-pc -target-feature +avx512fp16 %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple spir-unknown-unknown %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple armv7a-linux-gnu %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple aarch64-linux-gnu %s
 
-#ifndef HAVE
-// expected-error@+2{{_Float16 is not supported on this target}}
-#endif // HAVE
-_Float16 f;
-
-#ifdef HAVE
 _Complex _Float16 a;
 void builtin_complex(void) {
   _Float16 a = 0;
   (void)__builtin_complex(a, a); // expected-error {{'_Complex _Float16' is invalid}}
 }
-#endif
+
Index: clang/test/CodeGen/X86/Float16-complex.c
===
--- clang/test/CodeGen/X86/Float16-complex.c
+++ clang/test/CodeGen/X86/Float16-complex.c
@@ -1,4 +1,5 @@
 // RUN: %clang_cc1 %s -O0 -emit-llvm -triple x86_64-unknown-unknown -target-feature +avx512fp16 -o - | FileCheck %s --check-prefix=X86
+// RUN: %clang_cc1 %s -O0 -emit-llvm -triple x86_64-unknown-unknown -o - | FileCheck %s --check-prefixes=X86-PROM
 
 _Float16 _Complex add_half_rr(_Float16 a, _Float16 b) {
   // X86-LABEL: @add_half_rr(
@@ -85,7 +86,29 @@
   return a * b;
 }
 _Float16 _Complex mul_half_cc(_Float16 _Complex a, _Float16 _Complex b) {
-  // X86-LABEL: @mul_half_cc(
+  // CHECK: @mul_half_cc(
+
+  // X86-PROM: fpext half {{.*}} to float
+  // X86-PROM: fpext half {{.*}} to float
+  // X86-PROM: fpext half {{.*}} to float
+  // X86-PROM: fpext half {{.*}} to float
+  // X86-PROM: %[[AC:[^ ]+]] = fmul float
+  // X86-PROM: %[[BD:[^ ]+]] = fmul float
+  // X86-PROM: %[[AD:[^ ]+]] = fmul float
+  // X86-PROM: %[[BC:[^ ]+]] = fmul float
+  // X86-PROM: %[[RR:[^ ]+]] = fsub float
+  // X86-PROM: %[[RI:[^ ]+]] = fadd float
+  // X86-PROM: fcmp uno float %[[RR]]
+  // X86-PROM: fcmp uno float %[[RI]]
+  // X86-PROM: call <2 x float> @__mulsc3(
+  // X86-PROM: fptrunc float {{.*}} to half
+  // X86-PROM: fptrunc float {{.*}} to half
+  // X86-PROM: %[[RETR:[^ ]+]] = getelementptr inbounds { half, half }
+  // X86-PROM: %[[RETI:[^ ]+]] = getelementptr inbounds { half, half }
+  // X86-PROM: store half {{.*}}, ptr %[[RETR]]
+  // X86-PROM: store half {{.*}}, ptr %[[RETI]]
+  // X86-PROM: load 

[PATCH] D113107: Support of expression granularity for _Float16.

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam added a comment.

In D113107#3604048 , @pengfei wrote:

> @zahiraam, community requires to enable the `_Float16` support in FE, see 
> https://discourse.llvm.org/t/how-to-build-compiler-rt-for-new-x86-half-float-abi/63366
> Is there any blocking issue to land it soon? Otherwise, we can split the 
> changes in `X86.cpp`, `LanguageExtensions.rst`, `ReleaseNotes.rst` and some 
> tests from this patch and land them first.

I will wait for @JohnMCall


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D113107/new/

https://reviews.llvm.org/D113107

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D113107: Support of expression granularity for _Float16.

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam added a comment.

In D113107#3603761 , @pengfei wrote:

>> Supporting the lowering in the backend is sensible in order to support 
>> -fexcess-precision=16, because I agree that the most reasonable IR output in 
>> that configuration is to simply generate half operations. But under 
>> -fexcess-precision=32, I do not want the frontend to be in the business of 
>> recognizing cases where promoted emission is unnecessary, because that is 
>> just a lot of extra complexity for something that's already fairly 
>> special-case logic; among other things, it will tend to hide bugs.
>
> Fair enough. I agree we should choose the easy way to go. Thanks for the 
> explanation!
>
>> So I think we should hold off on adding this option until we know what 
>> behavior we actually want to expose via it.
>
> I don't have strong opinion on the specific `-fexcess-precision` option, but 
> we do need an option to stop the promotion in the FE. Some user requires the 
> emulation to gets the identical result as running on real HW. How about we 
> make `EmitFloat16WithExcessPrecision` an Clang option and set it true by 
> default and false for feature `avx512fp16`?

That's fine be me.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D113107/new/

https://reviews.llvm.org/D113107

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D113107: Support of expression granularity for _Float16.

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam updated this revision to Diff 439130.

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D113107/new/

https://reviews.llvm.org/D113107

Files:
  clang/docs/LanguageExtensions.rst
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/TargetInfo.h
  clang/lib/Basic/Targets/X86.cpp
  clang/lib/Basic/Targets/X86.h
  clang/lib/CodeGen/CGExprComplex.cpp
  clang/lib/CodeGen/CGExprScalar.cpp
  clang/lib/CodeGen/CodeGenFunction.h
  clang/test/CodeGen/X86/Float16-arithmetic.c
  clang/test/CodeGen/X86/Float16-complex.c
  clang/test/CodeGen/X86/avx512fp16-complex.c
  clang/test/Sema/Float16.c
  clang/test/Sema/conversion-target-dep.c
  clang/test/SemaCXX/Float16.cpp

Index: clang/test/SemaCXX/Float16.cpp
===
--- clang/test/SemaCXX/Float16.cpp
+++ clang/test/SemaCXX/Float16.cpp
@@ -1,18 +1,10 @@
 // RUN: %clang_cc1 -fsyntax-only -verify -triple x86_64-linux-pc %s
-// RUN: %clang_cc1 -fsyntax-only -verify -triple spir-unknown-unknown %s -DHAVE
-// RUN: %clang_cc1 -fsyntax-only -verify -triple armv7a-linux-gnu %s -DHAVE
-// RUN: %clang_cc1 -fsyntax-only -verify -triple aarch64-linux-gnu %s -DHAVE
+// RUN: %clang_cc1 -fsyntax-only -verify -triple spir-unknown-unknown %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple armv7a-linux-gnu %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple aarch64-linux-gnu %s
 
-#ifdef HAVE
 // expected-no-diagnostics
-#endif // HAVE
 
-#ifndef HAVE
-// expected-error@+2{{_Float16 is not supported on this target}}
-#endif // !HAVE
 _Float16 f;
 
-#ifndef HAVE
-// expected-error@+2{{invalid suffix 'F16' on floating constant}}
-#endif // !HAVE
 const auto g = 1.1F16;
Index: clang/test/Sema/conversion-target-dep.c
===
--- clang/test/Sema/conversion-target-dep.c
+++ clang/test/Sema/conversion-target-dep.c
@@ -6,7 +6,7 @@
 
 long double ld;
 double d;
-_Float16 f16; // x86-error {{_Float16 is not supported on this target}}
+_Float16 f16;
 
 int main(void) {
   ld = d; // x86-warning {{implicit conversion increases floating-point precision: 'double' to 'long double'}}
Index: clang/test/Sema/Float16.c
===
--- clang/test/Sema/Float16.c
+++ clang/test/Sema/Float16.c
@@ -1,18 +1,12 @@
 // RUN: %clang_cc1 -fsyntax-only -verify -triple x86_64-linux-pc %s
-// RUN: %clang_cc1 -fsyntax-only -verify -triple x86_64-linux-pc -target-feature +avx512fp16 %s -DHAVE
-// RUN: %clang_cc1 -fsyntax-only -verify -triple spir-unknown-unknown %s -DHAVE
-// RUN: %clang_cc1 -fsyntax-only -verify -triple armv7a-linux-gnu %s -DHAVE
-// RUN: %clang_cc1 -fsyntax-only -verify -triple aarch64-linux-gnu %s -DHAVE
+// RUN: %clang_cc1 -fsyntax-only -verify -triple x86_64-linux-pc -target-feature +avx512fp16 %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple spir-unknown-unknown %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple armv7a-linux-gnu %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple aarch64-linux-gnu %s
 
-#ifndef HAVE
-// expected-error@+2{{_Float16 is not supported on this target}}
-#endif // HAVE
-_Float16 f;
-
-#ifdef HAVE
 _Complex _Float16 a;
 void builtin_complex(void) {
   _Float16 a = 0;
   (void)__builtin_complex(a, a); // expected-error {{'_Complex _Float16' is invalid}}
 }
-#endif
+
Index: clang/test/CodeGen/X86/Float16-complex.c
===
--- clang/test/CodeGen/X86/Float16-complex.c
+++ clang/test/CodeGen/X86/Float16-complex.c
@@ -1,4 +1,5 @@
 // RUN: %clang_cc1 %s -O0 -emit-llvm -triple x86_64-unknown-unknown -target-feature +avx512fp16 -o - | FileCheck %s --check-prefix=X86
+// RUN: %clang_cc1 %s -O0 -emit-llvm -triple x86_64-unknown-unknown -o - | FileCheck %s --check-prefixes=X86-PROM
 
 _Float16 _Complex add_half_rr(_Float16 a, _Float16 b) {
   // X86-LABEL: @add_half_rr(
@@ -85,7 +86,29 @@
   return a * b;
 }
 _Float16 _Complex mul_half_cc(_Float16 _Complex a, _Float16 _Complex b) {
-  // X86-LABEL: @mul_half_cc(
+  // CHECK: @mul_half_cc(
+
+  // X86-PROM: fpext half {{.*}} to float
+  // X86-PROM: fpext half {{.*}} to float
+  // X86-PROM: fpext half {{.*}} to float
+  // X86-PROM: fpext half {{.*}} to float
+  // X86-PROM: %[[AC:[^ ]+]] = fmul float
+  // X86-PROM: %[[BD:[^ ]+]] = fmul float
+  // X86-PROM: %[[AD:[^ ]+]] = fmul float
+  // X86-PROM: %[[BC:[^ ]+]] = fmul float
+  // X86-PROM: %[[RR:[^ ]+]] = fsub float
+  // X86-PROM: %[[RI:[^ ]+]] = fadd float
+  // X86-PROM: fcmp uno float %[[RR]]
+  // X86-PROM: fcmp uno float %[[RI]]
+  // X86-PROM: call <2 x float> @__mulsc3(
+  // X86-PROM: fptrunc float {{.*}} to half
+  // X86-PROM: fptrunc float {{.*}} to half
+  // X86-PROM: %[[RETR:[^ ]+]] = getelementptr inbounds { half, half }
+  // X86-PROM: %[[RETI:[^ ]+]] = getelementptr inbounds { half, half }
+  // X86-PROM: store half {{.*}}, ptr %[[RETR]]
+  // X86-PROM: store half {{.*}}, ptr %[[RETI]]
+  // X86-PROM: load 

[PATCH] D113107: Support of expression granularity for _Float16.

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam updated this revision to Diff 439128.

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D113107/new/

https://reviews.llvm.org/D113107

Files:
  clang/docs/LanguageExtensions.rst
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/TargetInfo.h
  clang/lib/Basic/Targets/X86.cpp
  clang/lib/Basic/Targets/X86.h
  clang/lib/CodeGen/CGExprComplex.cpp
  clang/lib/CodeGen/CGExprScalar.cpp
  clang/lib/CodeGen/CodeGenFunction.h
  clang/test/CodeGen/X86/Float16-arithmetic.c
  clang/test/CodeGen/X86/Float16-complex.c
  clang/test/CodeGen/X86/avx512fp16-complex.c
  clang/test/Sema/Float16.c
  clang/test/Sema/conversion-target-dep.c
  clang/test/SemaCXX/Float16.cpp

Index: clang/test/SemaCXX/Float16.cpp
===
--- clang/test/SemaCXX/Float16.cpp
+++ clang/test/SemaCXX/Float16.cpp
@@ -1,18 +1,10 @@
 // RUN: %clang_cc1 -fsyntax-only -verify -triple x86_64-linux-pc %s
-// RUN: %clang_cc1 -fsyntax-only -verify -triple spir-unknown-unknown %s -DHAVE
-// RUN: %clang_cc1 -fsyntax-only -verify -triple armv7a-linux-gnu %s -DHAVE
-// RUN: %clang_cc1 -fsyntax-only -verify -triple aarch64-linux-gnu %s -DHAVE
+// RUN: %clang_cc1 -fsyntax-only -verify -triple spir-unknown-unknown %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple armv7a-linux-gnu %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple aarch64-linux-gnu %s
 
-#ifdef HAVE
 // expected-no-diagnostics
-#endif // HAVE
 
-#ifndef HAVE
-// expected-error@+2{{_Float16 is not supported on this target}}
-#endif // !HAVE
 _Float16 f;
 
-#ifndef HAVE
-// expected-error@+2{{invalid suffix 'F16' on floating constant}}
-#endif // !HAVE
 const auto g = 1.1F16;
Index: clang/test/Sema/conversion-target-dep.c
===
--- clang/test/Sema/conversion-target-dep.c
+++ clang/test/Sema/conversion-target-dep.c
@@ -6,7 +6,7 @@
 
 long double ld;
 double d;
-_Float16 f16; // x86-error {{_Float16 is not supported on this target}}
+_Float16 f16;
 
 int main(void) {
   ld = d; // x86-warning {{implicit conversion increases floating-point precision: 'double' to 'long double'}}
Index: clang/test/Sema/Float16.c
===
--- clang/test/Sema/Float16.c
+++ clang/test/Sema/Float16.c
@@ -1,18 +1,12 @@
 // RUN: %clang_cc1 -fsyntax-only -verify -triple x86_64-linux-pc %s
-// RUN: %clang_cc1 -fsyntax-only -verify -triple x86_64-linux-pc -target-feature +avx512fp16 %s -DHAVE
-// RUN: %clang_cc1 -fsyntax-only -verify -triple spir-unknown-unknown %s -DHAVE
-// RUN: %clang_cc1 -fsyntax-only -verify -triple armv7a-linux-gnu %s -DHAVE
-// RUN: %clang_cc1 -fsyntax-only -verify -triple aarch64-linux-gnu %s -DHAVE
+// RUN: %clang_cc1 -fsyntax-only -verify -triple x86_64-linux-pc -target-feature +avx512fp16 %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple spir-unknown-unknown %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple armv7a-linux-gnu %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple aarch64-linux-gnu %s
 
-#ifndef HAVE
-// expected-error@+2{{_Float16 is not supported on this target}}
-#endif // HAVE
-_Float16 f;
-
-#ifdef HAVE
 _Complex _Float16 a;
 void builtin_complex(void) {
   _Float16 a = 0;
   (void)__builtin_complex(a, a); // expected-error {{'_Complex _Float16' is invalid}}
 }
-#endif
+
Index: clang/test/CodeGen/X86/Float16-complex.c
===
--- clang/test/CodeGen/X86/Float16-complex.c
+++ clang/test/CodeGen/X86/Float16-complex.c
@@ -1,4 +1,5 @@
 // RUN: %clang_cc1 %s -O0 -emit-llvm -triple x86_64-unknown-unknown -target-feature +avx512fp16 -o - | FileCheck %s --check-prefix=X86
+// RUN: %clang_cc1 %s -O0 -emit-llvm -triple x86_64-unknown-unknown -o - | FileCheck %s --check-prefixes=X86-PROM
 
 _Float16 _Complex add_half_rr(_Float16 a, _Float16 b) {
   // X86-LABEL: @add_half_rr(
@@ -85,7 +86,29 @@
   return a * b;
 }
 _Float16 _Complex mul_half_cc(_Float16 _Complex a, _Float16 _Complex b) {
-  // X86-LABEL: @mul_half_cc(
+  // CHECK: @mul_half_cc(
+
+  // X86-PROM: fpext half {{.*}} to float
+  // X86-PROM: fpext half {{.*}} to float
+  // X86-PROM: fpext half {{.*}} to float
+  // X86-PROM: fpext half {{.*}} to float
+  // X86-PROM: %[[AC:[^ ]+]] = fmul float
+  // X86-PROM: %[[BD:[^ ]+]] = fmul float
+  // X86-PROM: %[[AD:[^ ]+]] = fmul float
+  // X86-PROM: %[[BC:[^ ]+]] = fmul float
+  // X86-PROM: %[[RR:[^ ]+]] = fsub float
+  // X86-PROM: %[[RI:[^ ]+]] = fadd float
+  // X86-PROM: fcmp uno float %[[RR]]
+  // X86-PROM: fcmp uno float %[[RI]]
+  // X86-PROM: call <2 x float> @__mulsc3(
+  // X86-PROM: fptrunc float {{.*}} to half
+  // X86-PROM: fptrunc float {{.*}} to half
+  // X86-PROM: %[[RETR:[^ ]+]] = getelementptr inbounds { half, half }
+  // X86-PROM: %[[RETI:[^ ]+]] = getelementptr inbounds { half, half }
+  // X86-PROM: store half {{.*}}, ptr %[[RETR]]
+  // X86-PROM: store half {{.*}}, ptr %[[RETI]]
+  // X86-PROM: load 

[PATCH] D113107: Support of expression granularity for _Float16.

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam updated this revision to Diff 439113.

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D113107/new/

https://reviews.llvm.org/D113107

Files:
  clang/docs/LanguageExtensions.rst
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/TargetInfo.h
  clang/lib/Basic/Targets/X86.cpp
  clang/lib/Basic/Targets/X86.h
  clang/lib/CodeGen/CGExprComplex.cpp
  clang/lib/CodeGen/CGExprScalar.cpp
  clang/lib/CodeGen/CodeGenFunction.h
  clang/test/CodeGen/X86/Float16-arithmetic.c
  clang/test/CodeGen/X86/Float16-complex.c
  clang/test/CodeGen/X86/avx512fp16-complex.c
  clang/test/Sema/Float16.c
  clang/test/Sema/conversion-target-dep.c
  clang/test/SemaCXX/Float16.cpp

Index: clang/test/SemaCXX/Float16.cpp
===
--- clang/test/SemaCXX/Float16.cpp
+++ clang/test/SemaCXX/Float16.cpp
@@ -1,18 +1,10 @@
 // RUN: %clang_cc1 -fsyntax-only -verify -triple x86_64-linux-pc %s
-// RUN: %clang_cc1 -fsyntax-only -verify -triple spir-unknown-unknown %s -DHAVE
-// RUN: %clang_cc1 -fsyntax-only -verify -triple armv7a-linux-gnu %s -DHAVE
-// RUN: %clang_cc1 -fsyntax-only -verify -triple aarch64-linux-gnu %s -DHAVE
+// RUN: %clang_cc1 -fsyntax-only -verify -triple spir-unknown-unknown %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple armv7a-linux-gnu %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple aarch64-linux-gnu %s
 
-#ifdef HAVE
 // expected-no-diagnostics
-#endif // HAVE
 
-#ifndef HAVE
-// expected-error@+2{{_Float16 is not supported on this target}}
-#endif // !HAVE
 _Float16 f;
 
-#ifndef HAVE
-// expected-error@+2{{invalid suffix 'F16' on floating constant}}
-#endif // !HAVE
 const auto g = 1.1F16;
Index: clang/test/Sema/conversion-target-dep.c
===
--- clang/test/Sema/conversion-target-dep.c
+++ clang/test/Sema/conversion-target-dep.c
@@ -6,7 +6,7 @@
 
 long double ld;
 double d;
-_Float16 f16; // x86-error {{_Float16 is not supported on this target}}
+_Float16 f16;
 
 int main(void) {
   ld = d; // x86-warning {{implicit conversion increases floating-point precision: 'double' to 'long double'}}
Index: clang/test/Sema/Float16.c
===
--- clang/test/Sema/Float16.c
+++ clang/test/Sema/Float16.c
@@ -1,18 +1,12 @@
 // RUN: %clang_cc1 -fsyntax-only -verify -triple x86_64-linux-pc %s
-// RUN: %clang_cc1 -fsyntax-only -verify -triple x86_64-linux-pc -target-feature +avx512fp16 %s -DHAVE
-// RUN: %clang_cc1 -fsyntax-only -verify -triple spir-unknown-unknown %s -DHAVE
-// RUN: %clang_cc1 -fsyntax-only -verify -triple armv7a-linux-gnu %s -DHAVE
-// RUN: %clang_cc1 -fsyntax-only -verify -triple aarch64-linux-gnu %s -DHAVE
+// RUN: %clang_cc1 -fsyntax-only -verify -triple x86_64-linux-pc -target-feature +avx512fp16 %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple spir-unknown-unknown %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple armv7a-linux-gnu %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple aarch64-linux-gnu %s
 
-#ifndef HAVE
-// expected-error@+2{{_Float16 is not supported on this target}}
-#endif // HAVE
-_Float16 f;
-
-#ifdef HAVE
 _Complex _Float16 a;
 void builtin_complex(void) {
   _Float16 a = 0;
   (void)__builtin_complex(a, a); // expected-error {{'_Complex _Float16' is invalid}}
 }
-#endif
+
Index: clang/test/CodeGen/X86/Float16-complex.c
===
--- clang/test/CodeGen/X86/Float16-complex.c
+++ clang/test/CodeGen/X86/Float16-complex.c
@@ -1,4 +1,5 @@
 // RUN: %clang_cc1 %s -O0 -emit-llvm -triple x86_64-unknown-unknown -target-feature +avx512fp16 -o - | FileCheck %s --check-prefix=X86
+// RUN: %clang_cc1 %s -O0 -emit-llvm -triple x86_64-unknown-unknown -o - | FileCheck %s --check-prefixes=X86-PROM
 
 _Float16 _Complex add_half_rr(_Float16 a, _Float16 b) {
   // X86-LABEL: @add_half_rr(
@@ -85,7 +86,29 @@
   return a * b;
 }
 _Float16 _Complex mul_half_cc(_Float16 _Complex a, _Float16 _Complex b) {
-  // X86-LABEL: @mul_half_cc(
+  // CHECK: @mul_half_cc(
+
+  // X86-PROM: fpext half {{.*}} to float
+  // X86-PROM: fpext half {{.*}} to float
+  // X86-PROM: fpext half {{.*}} to float
+  // X86-PROM: fpext half {{.*}} to float
+  // X86-PROM: %[[AC:[^ ]+]] = fmul float
+  // X86-PROM: %[[BD:[^ ]+]] = fmul float
+  // X86-PROM: %[[AD:[^ ]+]] = fmul float
+  // X86-PROM: %[[BC:[^ ]+]] = fmul float
+  // X86-PROM: %[[RR:[^ ]+]] = fsub float
+  // X86-PROM: %[[RI:[^ ]+]] = fadd float
+  // X86-PROM: fcmp uno float %[[RR]]
+  // X86-PROM: fcmp uno float %[[RI]]
+  // X86-PROM: call <2 x float> @__mulsc3(
+  // X86-PROM: fptrunc float {{.*}} to half
+  // X86-PROM: fptrunc float {{.*}} to half
+  // X86-PROM: %[[RETR:[^ ]+]] = getelementptr inbounds { half, half }
+  // X86-PROM: %[[RETI:[^ ]+]] = getelementptr inbounds { half, half }
+  // X86-PROM: store half {{.*}}, ptr %[[RETR]]
+  // X86-PROM: store half {{.*}}, ptr %[[RETI]]
+  // X86-PROM: load 

[PATCH] D113107: Support of expression granularity for _Float16.

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam updated this revision to Diff 439110.

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D113107/new/

https://reviews.llvm.org/D113107

Files:
  clang/docs/LanguageExtensions.rst
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/TargetInfo.h
  clang/lib/Basic/Targets/X86.cpp
  clang/lib/Basic/Targets/X86.h
  clang/lib/CodeGen/CGExprComplex.cpp
  clang/lib/CodeGen/CGExprScalar.cpp
  clang/lib/CodeGen/CodeGenFunction.h
  clang/test/CodeGen/X86/Float16-arithmetic.c
  clang/test/CodeGen/X86/Float16-complex.c
  clang/test/CodeGen/X86/avx512fp16-complex.c
  clang/test/Sema/Float16.c
  clang/test/Sema/conversion-target-dep.c
  clang/test/SemaCXX/Float16.cpp

Index: clang/test/SemaCXX/Float16.cpp
===
--- clang/test/SemaCXX/Float16.cpp
+++ clang/test/SemaCXX/Float16.cpp
@@ -1,18 +1,10 @@
 // RUN: %clang_cc1 -fsyntax-only -verify -triple x86_64-linux-pc %s
-// RUN: %clang_cc1 -fsyntax-only -verify -triple spir-unknown-unknown %s -DHAVE
-// RUN: %clang_cc1 -fsyntax-only -verify -triple armv7a-linux-gnu %s -DHAVE
-// RUN: %clang_cc1 -fsyntax-only -verify -triple aarch64-linux-gnu %s -DHAVE
+// RUN: %clang_cc1 -fsyntax-only -verify -triple spir-unknown-unknown %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple armv7a-linux-gnu %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple aarch64-linux-gnu %s
 
-#ifdef HAVE
 // expected-no-diagnostics
-#endif // HAVE
 
-#ifndef HAVE
-// expected-error@+2{{_Float16 is not supported on this target}}
-#endif // !HAVE
 _Float16 f;
 
-#ifndef HAVE
-// expected-error@+2{{invalid suffix 'F16' on floating constant}}
-#endif // !HAVE
 const auto g = 1.1F16;
Index: clang/test/Sema/conversion-target-dep.c
===
--- clang/test/Sema/conversion-target-dep.c
+++ clang/test/Sema/conversion-target-dep.c
@@ -6,7 +6,7 @@
 
 long double ld;
 double d;
-_Float16 f16; // x86-error {{_Float16 is not supported on this target}}
+_Float16 f16;
 
 int main(void) {
   ld = d; // x86-warning {{implicit conversion increases floating-point precision: 'double' to 'long double'}}
Index: clang/test/Sema/Float16.c
===
--- clang/test/Sema/Float16.c
+++ clang/test/Sema/Float16.c
@@ -1,18 +1,12 @@
 // RUN: %clang_cc1 -fsyntax-only -verify -triple x86_64-linux-pc %s
-// RUN: %clang_cc1 -fsyntax-only -verify -triple x86_64-linux-pc -target-feature +avx512fp16 %s -DHAVE
-// RUN: %clang_cc1 -fsyntax-only -verify -triple spir-unknown-unknown %s -DHAVE
-// RUN: %clang_cc1 -fsyntax-only -verify -triple armv7a-linux-gnu %s -DHAVE
-// RUN: %clang_cc1 -fsyntax-only -verify -triple aarch64-linux-gnu %s -DHAVE
+// RUN: %clang_cc1 -fsyntax-only -verify -triple x86_64-linux-pc -target-feature +avx512fp16 %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple spir-unknown-unknown %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple armv7a-linux-gnu %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple aarch64-linux-gnu %s
 
-#ifndef HAVE
-// expected-error@+2{{_Float16 is not supported on this target}}
-#endif // HAVE
-_Float16 f;
-
-#ifdef HAVE
 _Complex _Float16 a;
 void builtin_complex(void) {
   _Float16 a = 0;
   (void)__builtin_complex(a, a); // expected-error {{'_Complex _Float16' is invalid}}
 }
-#endif
+
Index: clang/test/CodeGen/X86/Float16-complex.c
===
--- clang/test/CodeGen/X86/Float16-complex.c
+++ clang/test/CodeGen/X86/Float16-complex.c
@@ -1,4 +1,5 @@
 // RUN: %clang_cc1 %s -O0 -emit-llvm -triple x86_64-unknown-unknown -target-feature +avx512fp16 -o - | FileCheck %s --check-prefix=X86
+// RUN: %clang_cc1 %s -O0 -emit-llvm -triple x86_64-unknown-unknown -o - | FileCheck %s --check-prefixes=X86-PROM
 
 _Float16 _Complex add_half_rr(_Float16 a, _Float16 b) {
   // X86-LABEL: @add_half_rr(
@@ -85,7 +86,29 @@
   return a * b;
 }
 _Float16 _Complex mul_half_cc(_Float16 _Complex a, _Float16 _Complex b) {
-  // X86-LABEL: @mul_half_cc(
+  // CHECK: @mul_half_cc(
+
+  // X86-PROM: fpext half {{.*}} to float
+  // X86-PROM: fpext half {{.*}} to float
+  // X86-PROM: fpext half {{.*}} to float
+  // X86-PROM: fpext half {{.*}} to float
+  // X86-PROM: %[[AC:[^ ]+]] = fmul float
+  // X86-PROM: %[[BD:[^ ]+]] = fmul float
+  // X86-PROM: %[[AD:[^ ]+]] = fmul float
+  // X86-PROM: %[[BC:[^ ]+]] = fmul float
+  // X86-PROM: %[[RR:[^ ]+]] = fsub float
+  // X86-PROM: %[[RI:[^ ]+]] = fadd float
+  // X86-PROM: fcmp uno float %[[RR]]
+  // X86-PROM: fcmp uno float %[[RI]]
+  // X86-PROM: call <2 x float> @__mulsc3(
+  // X86-PROM: fptrunc float {{.*}} to half
+  // X86-PROM: fptrunc float {{.*}} to half
+  // X86-PROM: %[[RETR:[^ ]+]] = getelementptr inbounds { half, half }
+  // X86-PROM: %[[RETI:[^ ]+]] = getelementptr inbounds { half, half }
+  // X86-PROM: store half {{.*}}, ptr %[[RETR]]
+  // X86-PROM: store half {{.*}}, ptr %[[RETI]]
+  // X86-PROM: load 

[PATCH] D113107: Support of expression granularity for _Float16.

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam added a comment.

In D113107#3601873 , @rjmccall wrote:

> Supporting the lowering in the backend is sensible in order to support 
> `-fexcess-precision=16`, because I agree that the most reasonable IR output 
> in that configuration is to simply generate `half` operations.  But under 
> `-fexcess-precision=32`, I do not want the frontend to be in the business of 
> recognizing cases where promoted emission is unnecessary, because that is 
> just a lot of extra complexity for something that's already fairly 
> special-case logic; among other things, it will tend to hide bugs.
>
>> I don't understand, how can we check the missed cases if the promotion was 
>> done in FE?
>
> You simply test that you do not see any unpromoted operations coming out of 
> the frontend.  Any operation emitted on `half` (except conversions to and 
> from other types) is probably a missed opportunity to be doing promoted 
> emission.  For example, if we saw that `x += y + z` performed a `half` 
> operation for the final addition, it would suggest that we had a bug in the 
> emission of `+=`, not just because we were emitting a `half` operation but 
> because we were likely failing to propagate promoted emission into the RHS of 
> the operator, i.e. that we were introducing an unnecessary truncation there.
>
> Of course, knowing that we aren't doing operations on `half` doesn't mean we 
> aren't doing unnecessary truncations explicitly, so we still need to be 
> testing such cases.  But it's an easy way to see bugs when simply scanning 
> the IR generated for a program.

Incidentally this little example here is not working with this patch. I will 
add code to fix it. It is now generating an fadd half.
Do we want to add an -fexcess-precision option?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D113107/new/

https://reviews.llvm.org/D113107

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D113107: Support of expression granularity for _Float16.

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam added inline comments.



Comment at: clang/lib/CodeGen/CGExprComplex.cpp:896
+
+ComplexPairTy ComplexExprEmitter::EmitPromoted(const Expr *E) {
+  if (auto *BinOp = dyn_cast(E->IgnoreParens())) {

pengfei wrote:
> zahiraam wrote:
> > pengfei wrote:
> > > rjmccall wrote:
> > > > pengfei wrote:
> > > > > rjmccall wrote:
> > > > > > zahiraam wrote:
> > > > > > > rjmccall wrote:
> > > > > > > > `EmitPromoted` should take the promotion type.
> > > > > > > > 
> > > > > > > > You are missing the logic in this file which handles 
> > > > > > > > *unpromoted* emission (where you have a binary operator but the 
> > > > > > > > context wants an unpromoted value) by recognizing that you need 
> > > > > > > > to do a promoted operation and then truncate.
> > > > > > > Sorry but not sure what you mean here. A case where we don't want 
> > > > > > > any promotion would be:
> > > > > > > 
> > > > > > > float _Complex add(float _Complex a, float _Complex b) {
> > > > > > >   return a + b;
> > > > > > > }
> > > > > > > 
> > > > > > > In this case, getPromotionType would return the null type and 
> > > > > > > EmitBinOps would just go through the  "older" control path where 
> > > > > > > there is no promotion.
> > > > > > > Unless I misunderstood your comment?
> > > > > > > 
> > > > > > > 
> > > > > > I'm talking about the unpromoted emission path for an operation 
> > > > > > that we want to *internally* promote.  So like your example but 
> > > > > > using `_Float16` — we want to emit the binary `+` as a `float` 
> > > > > > operation, but the context needs an unpromoted value because it's 
> > > > > > going to be returned.
> > > > > > 
> > > > > > The promoted emission path (the various `EmitPromoted` methods) 
> > > > > > represents a request by the caller to produce a result that doesn't 
> > > > > > match the formal type of the expression.  The normal emission path 
> > > > > > `Visit` etc.) represents a request by the caller to produce a 
> > > > > > result normally, i.e. one that matches the formal type.  In 
> > > > > > general, we always start in the latter because arbitrary contexts 
> > > > > > always expect a value of the formal type; it's only these recursive 
> > > > > > calls within promoted emitters that contextually want a promoted 
> > > > > > value.
> > > > > > 
> > > > > > In your current patch, you're entering the promoted path by 
> > > > > > special-casing one context that frequently terminates promoted 
> > > > > > emission: `EmitComplexExprIntoLValue`, which is used for things 
> > > > > > like assignment.  That's not the right way to handle it, though.  
> > > > > > Instead, you should do like I asked you to do with the scalar 
> > > > > > emitter, which is to recognize in the normal emission path for a 
> > > > > > promotable operation (like binary `+`) that you need to promote the 
> > > > > > operation and then unpromote the result.  Then things like 
> > > > > > `EmitComplexExprIntoLValue` will continue to simply enter the 
> > > > > > normal path because that's the kind of value they need, and the 
> > > > > > promotion logic will do the right thing from there to ensure we 
> > > > > > don't emit a `_Float16` operation in LLVM IR.
> > > > > > 
> > > > > > Incidentally, I thought of another context that you ought to do 
> > > > > > promotion for: when we're converting a promotable value to a larger 
> > > > > > floating-point type, we should presumably convert the promoted 
> > > > > > value directly rather than truncating it to the unpromoted type 
> > > > > > before the conversion.
> > > > > I'm not familiar with the FE details, but I understand the background 
> > > > > is just to promote expressions that have more than one operation. So 
> > > > > I agree with @zahiraam, and
> > > > > > to ensure we don't emit a _Float16 operation in LLVM IR
> > > > > is not what we expected here.
> > > > > 
> > > > > `_Float16` is a ABI type for which a target supported has to lower 
> > > > > any `_Float16` operations in LLVM IR. See what we have done on X86 
> > > > > backend by D107082.
> > > > > 
> > > > > That said, a single `a + b` can be and should be emitted as `%c = 
> > > > > fadd half %a, %b`.
> > > > Well, you can provide operation-by-operation lowering support if you 
> > > > want to, but what's going to come out of Clang IRGen in this mode is 
> > > > not going to rely on it.  It's far easier to just emit these operations 
> > > > differently, always using `float`, than to try to recognize the special 
> > > > cases where all the inputs are naturally `half` and so you might as 
> > > > well emit a `half` operation.
> > > > 
> > > > And I think the postcondition that `half` operations don't come out of 
> > > > IRGen is a generally useful property even if you've already written 
> > > > this lowering code.  Among other things, it makes it easy to test that 
> > > > you haven't missed a case where you should be doing promoted emission.
> > > We define 

[PATCH] D113107: Support of expression granularity for _Float16.

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam updated this revision to Diff 439020.
zahiraam marked 2 inline comments as done.

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D113107/new/

https://reviews.llvm.org/D113107

Files:
  clang/docs/LanguageExtensions.rst
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/TargetInfo.h
  clang/lib/Basic/Targets/X86.cpp
  clang/lib/Basic/Targets/X86.h
  clang/lib/CodeGen/CGExprComplex.cpp
  clang/lib/CodeGen/CGExprScalar.cpp
  clang/lib/CodeGen/CodeGenFunction.h
  clang/test/CodeGen/X86/Float16-arithmetic.c
  clang/test/CodeGen/X86/Float16-complex.c
  clang/test/CodeGen/X86/avx512fp16-complex.c
  clang/test/Sema/Float16.c
  clang/test/Sema/conversion-target-dep.c
  clang/test/SemaCXX/Float16.cpp

Index: clang/test/SemaCXX/Float16.cpp
===
--- clang/test/SemaCXX/Float16.cpp
+++ clang/test/SemaCXX/Float16.cpp
@@ -1,18 +1,10 @@
 // RUN: %clang_cc1 -fsyntax-only -verify -triple x86_64-linux-pc %s
-// RUN: %clang_cc1 -fsyntax-only -verify -triple spir-unknown-unknown %s -DHAVE
-// RUN: %clang_cc1 -fsyntax-only -verify -triple armv7a-linux-gnu %s -DHAVE
-// RUN: %clang_cc1 -fsyntax-only -verify -triple aarch64-linux-gnu %s -DHAVE
+// RUN: %clang_cc1 -fsyntax-only -verify -triple spir-unknown-unknown %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple armv7a-linux-gnu %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple aarch64-linux-gnu %s
 
-#ifdef HAVE
 // expected-no-diagnostics
-#endif // HAVE
 
-#ifndef HAVE
-// expected-error@+2{{_Float16 is not supported on this target}}
-#endif // !HAVE
 _Float16 f;
 
-#ifndef HAVE
-// expected-error@+2{{invalid suffix 'F16' on floating constant}}
-#endif // !HAVE
 const auto g = 1.1F16;
Index: clang/test/Sema/conversion-target-dep.c
===
--- clang/test/Sema/conversion-target-dep.c
+++ clang/test/Sema/conversion-target-dep.c
@@ -6,7 +6,7 @@
 
 long double ld;
 double d;
-_Float16 f16; // x86-error {{_Float16 is not supported on this target}}
+_Float16 f16;
 
 int main(void) {
   ld = d; // x86-warning {{implicit conversion increases floating-point precision: 'double' to 'long double'}}
Index: clang/test/Sema/Float16.c
===
--- clang/test/Sema/Float16.c
+++ clang/test/Sema/Float16.c
@@ -1,18 +1,12 @@
 // RUN: %clang_cc1 -fsyntax-only -verify -triple x86_64-linux-pc %s
-// RUN: %clang_cc1 -fsyntax-only -verify -triple x86_64-linux-pc -target-feature +avx512fp16 %s -DHAVE
-// RUN: %clang_cc1 -fsyntax-only -verify -triple spir-unknown-unknown %s -DHAVE
-// RUN: %clang_cc1 -fsyntax-only -verify -triple armv7a-linux-gnu %s -DHAVE
-// RUN: %clang_cc1 -fsyntax-only -verify -triple aarch64-linux-gnu %s -DHAVE
+// RUN: %clang_cc1 -fsyntax-only -verify -triple x86_64-linux-pc -target-feature +avx512fp16 %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple spir-unknown-unknown %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple armv7a-linux-gnu %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple aarch64-linux-gnu %s
 
-#ifndef HAVE
-// expected-error@+2{{_Float16 is not supported on this target}}
-#endif // HAVE
-_Float16 f;
-
-#ifdef HAVE
 _Complex _Float16 a;
 void builtin_complex(void) {
   _Float16 a = 0;
   (void)__builtin_complex(a, a); // expected-error {{'_Complex _Float16' is invalid}}
 }
-#endif
+
Index: clang/test/CodeGen/X86/Float16-complex.c
===
--- clang/test/CodeGen/X86/Float16-complex.c
+++ clang/test/CodeGen/X86/Float16-complex.c
@@ -1,4 +1,5 @@
 // RUN: %clang_cc1 %s -O0 -emit-llvm -triple x86_64-unknown-unknown -target-feature +avx512fp16 -o - | FileCheck %s --check-prefix=X86
+// RUN: %clang_cc1 %s -O0 -emit-llvm -triple x86_64-unknown-unknown -o - | FileCheck %s --check-prefixes=X86-PROM
 
 _Float16 _Complex add_half_rr(_Float16 a, _Float16 b) {
   // X86-LABEL: @add_half_rr(
@@ -85,7 +86,29 @@
   return a * b;
 }
 _Float16 _Complex mul_half_cc(_Float16 _Complex a, _Float16 _Complex b) {
-  // X86-LABEL: @mul_half_cc(
+  // CHECK: @mul_half_cc(
+
+  // X86-PROM: fpext half {{.*}} to float
+  // X86-PROM: fpext half {{.*}} to float
+  // X86-PROM: fpext half {{.*}} to float
+  // X86-PROM: fpext half {{.*}} to float
+  // X86-PROM: %[[AC:[^ ]+]] = fmul float
+  // X86-PROM: %[[BD:[^ ]+]] = fmul float
+  // X86-PROM: %[[AD:[^ ]+]] = fmul float
+  // X86-PROM: %[[BC:[^ ]+]] = fmul float
+  // X86-PROM: %[[RR:[^ ]+]] = fsub float
+  // X86-PROM: %[[RI:[^ ]+]] = fadd float
+  // X86-PROM: fcmp uno float %[[RR]]
+  // X86-PROM: fcmp uno float %[[RI]]
+  // X86-PROM: call <2 x float> @__mulsc3(
+  // X86-PROM: fptrunc float {{.*}} to half
+  // X86-PROM: fptrunc float {{.*}} to half
+  // X86-PROM: %[[RETR:[^ ]+]] = getelementptr inbounds { half, half }
+  // X86-PROM: %[[RETI:[^ ]+]] = getelementptr inbounds { half, half }
+  // X86-PROM: store half {{.*}}, ptr %[[RETR]]
+  // X86-PROM: store half 

[PATCH] D113107: Support of expression granularity for _Float16.

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam marked 7 inline comments as done.
zahiraam added inline comments.



Comment at: clang/lib/CodeGen/CGExprComplex.cpp:896
+
+ComplexPairTy ComplexExprEmitter::EmitPromoted(const Expr *E) {
+  if (auto *BinOp = dyn_cast(E->IgnoreParens())) {

pengfei wrote:
> rjmccall wrote:
> > pengfei wrote:
> > > rjmccall wrote:
> > > > zahiraam wrote:
> > > > > rjmccall wrote:
> > > > > > `EmitPromoted` should take the promotion type.
> > > > > > 
> > > > > > You are missing the logic in this file which handles *unpromoted* 
> > > > > > emission (where you have a binary operator but the context wants an 
> > > > > > unpromoted value) by recognizing that you need to do a promoted 
> > > > > > operation and then truncate.
> > > > > Sorry but not sure what you mean here. A case where we don't want any 
> > > > > promotion would be:
> > > > > 
> > > > > float _Complex add(float _Complex a, float _Complex b) {
> > > > >   return a + b;
> > > > > }
> > > > > 
> > > > > In this case, getPromotionType would return the null type and 
> > > > > EmitBinOps would just go through the  "older" control path where 
> > > > > there is no promotion.
> > > > > Unless I misunderstood your comment?
> > > > > 
> > > > > 
> > > > I'm talking about the unpromoted emission path for an operation that we 
> > > > want to *internally* promote.  So like your example but using 
> > > > `_Float16` — we want to emit the binary `+` as a `float` operation, but 
> > > > the context needs an unpromoted value because it's going to be returned.
> > > > 
> > > > The promoted emission path (the various `EmitPromoted` methods) 
> > > > represents a request by the caller to produce a result that doesn't 
> > > > match the formal type of the expression.  The normal emission path 
> > > > `Visit` etc.) represents a request by the caller to produce a result 
> > > > normally, i.e. one that matches the formal type.  In general, we always 
> > > > start in the latter because arbitrary contexts always expect a value of 
> > > > the formal type; it's only these recursive calls within promoted 
> > > > emitters that contextually want a promoted value.
> > > > 
> > > > In your current patch, you're entering the promoted path by 
> > > > special-casing one context that frequently terminates promoted 
> > > > emission: `EmitComplexExprIntoLValue`, which is used for things like 
> > > > assignment.  That's not the right way to handle it, though.  Instead, 
> > > > you should do like I asked you to do with the scalar emitter, which is 
> > > > to recognize in the normal emission path for a promotable operation 
> > > > (like binary `+`) that you need to promote the operation and then 
> > > > unpromote the result.  Then things like `EmitComplexExprIntoLValue` 
> > > > will continue to simply enter the normal path because that's the kind 
> > > > of value they need, and the promotion logic will do the right thing 
> > > > from there to ensure we don't emit a `_Float16` operation in LLVM IR.
> > > > 
> > > > Incidentally, I thought of another context that you ought to do 
> > > > promotion for: when we're converting a promotable value to a larger 
> > > > floating-point type, we should presumably convert the promoted value 
> > > > directly rather than truncating it to the unpromoted type before the 
> > > > conversion.
> > > I'm not familiar with the FE details, but I understand the background is 
> > > just to promote expressions that have more than one operation. So I agree 
> > > with @zahiraam, and
> > > > to ensure we don't emit a _Float16 operation in LLVM IR
> > > is not what we expected here.
> > > 
> > > `_Float16` is a ABI type for which a target supported has to lower any 
> > > `_Float16` operations in LLVM IR. See what we have done on X86 backend by 
> > > D107082.
> > > 
> > > That said, a single `a + b` can be and should be emitted as `%c = fadd 
> > > half %a, %b`.
> > Well, you can provide operation-by-operation lowering support if you want 
> > to, but what's going to come out of Clang IRGen in this mode is not going 
> > to rely on it.  It's far easier to just emit these operations differently, 
> > always using `float`, than to try to recognize the special cases where all 
> > the inputs are naturally `half` and so you might as well emit a `half` 
> > operation.
> > 
> > And I think the postcondition that `half` operations don't come out of 
> > IRGen is a generally useful property even if you've already written this 
> > lowering code.  Among other things, it makes it easy to test that you 
> > haven't missed a case where you should be doing promoted emission.
> We define `_Float16` as ABI type and require targets to support the ABI 
> lowering. See 
> https://clang.llvm.org/docs/LanguageExtensions.html#half-precision-floating-point
>  Promoting in FE doesn't mean it works on any targets by default, so I think 
> it's not much useful.
> We need to support `-fexcess-precision=16` the same as GCC does, it's easier 

[PATCH] D113107: Support of expression granularity for _Float16.

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam marked 2 inline comments as done.
zahiraam added inline comments.



Comment at: clang/lib/CodeGen/CGExprComplex.cpp:896
+
+ComplexPairTy ComplexExprEmitter::EmitPromoted(const Expr *E) {
+  if (auto *BinOp = dyn_cast(E->IgnoreParens())) {

rjmccall wrote:
> `EmitPromoted` should take the promotion type.
> 
> You are missing the logic in this file which handles *unpromoted* emission 
> (where you have a binary operator but the context wants an unpromoted value) 
> by recognizing that you need to do a promoted operation and then truncate.
Sorry but not sure what you mean here. A case where we don't want any promotion 
would be:

float _Complex add(float _Complex a, float _Complex b) {
  return a + b;
}

In this case, getPromotionType would return the null type and EmitBinOps would 
just go through the  "older" control path where there is no promotion.
Unless I misunderstood your comment?




CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D113107/new/

https://reviews.llvm.org/D113107

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D113107: Support of expression granularity for _Float16.

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam added a comment.

@rjmccall 
I made some progress on the requests above. 
There are still a few things that need to be nailed down. The comma && ternary 
cases for EmitPromoted, I am not sure what needs to happen there? I am also not 
quite sure about the ComplexExpr’s generated IR . I updated only some of the 
Float16-Complex.c tests but before editing the rest of the tests, I would like 
your feedback to see if the IR generated is correct (mul_half_cc is now 
generating __mulsc3 with truncation instead of __mulhc3). 
Please at your convenience, let me know if this is converging into the right 
direction.
Thanks.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D113107/new/

https://reviews.llvm.org/D113107

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D113107: Support of expression granularity for _Float16.

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam updated this revision to Diff 437191.

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D113107/new/

https://reviews.llvm.org/D113107

Files:
  clang/docs/LanguageExtensions.rst
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/TargetInfo.h
  clang/lib/Basic/Targets/X86.cpp
  clang/lib/Basic/Targets/X86.h
  clang/lib/CodeGen/CGExprComplex.cpp
  clang/lib/CodeGen/CGExprScalar.cpp
  clang/lib/CodeGen/CodeGenFunction.h
  clang/test/CodeGen/X86/Float16-arithmetic.c
  clang/test/CodeGen/X86/Float16-complex.c
  clang/test/CodeGen/X86/avx512fp16-complex.c
  clang/test/Sema/Float16.c
  clang/test/Sema/conversion-target-dep.c
  clang/test/SemaCXX/Float16.cpp

Index: clang/test/SemaCXX/Float16.cpp
===
--- clang/test/SemaCXX/Float16.cpp
+++ clang/test/SemaCXX/Float16.cpp
@@ -1,18 +1,10 @@
 // RUN: %clang_cc1 -fsyntax-only -verify -triple x86_64-linux-pc %s
-// RUN: %clang_cc1 -fsyntax-only -verify -triple spir-unknown-unknown %s -DHAVE
-// RUN: %clang_cc1 -fsyntax-only -verify -triple armv7a-linux-gnu %s -DHAVE
-// RUN: %clang_cc1 -fsyntax-only -verify -triple aarch64-linux-gnu %s -DHAVE
+// RUN: %clang_cc1 -fsyntax-only -verify -triple spir-unknown-unknown %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple armv7a-linux-gnu %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple aarch64-linux-gnu %s
 
-#ifdef HAVE
 // expected-no-diagnostics
-#endif // HAVE
 
-#ifndef HAVE
-// expected-error@+2{{_Float16 is not supported on this target}}
-#endif // !HAVE
 _Float16 f;
 
-#ifndef HAVE
-// expected-error@+2{{invalid suffix 'F16' on floating constant}}
-#endif // !HAVE
 const auto g = 1.1F16;
Index: clang/test/Sema/conversion-target-dep.c
===
--- clang/test/Sema/conversion-target-dep.c
+++ clang/test/Sema/conversion-target-dep.c
@@ -6,7 +6,7 @@
 
 long double ld;
 double d;
-_Float16 f16; // x86-error {{_Float16 is not supported on this target}}
+_Float16 f16;
 
 int main(void) {
   ld = d; // x86-warning {{implicit conversion increases floating-point precision: 'double' to 'long double'}}
Index: clang/test/Sema/Float16.c
===
--- clang/test/Sema/Float16.c
+++ clang/test/Sema/Float16.c
@@ -1,18 +1,12 @@
 // RUN: %clang_cc1 -fsyntax-only -verify -triple x86_64-linux-pc %s
-// RUN: %clang_cc1 -fsyntax-only -verify -triple x86_64-linux-pc -target-feature +avx512fp16 %s -DHAVE
-// RUN: %clang_cc1 -fsyntax-only -verify -triple spir-unknown-unknown %s -DHAVE
-// RUN: %clang_cc1 -fsyntax-only -verify -triple armv7a-linux-gnu %s -DHAVE
-// RUN: %clang_cc1 -fsyntax-only -verify -triple aarch64-linux-gnu %s -DHAVE
+// RUN: %clang_cc1 -fsyntax-only -verify -triple x86_64-linux-pc -target-feature +avx512fp16 %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple spir-unknown-unknown %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple armv7a-linux-gnu %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple aarch64-linux-gnu %s
 
-#ifndef HAVE
-// expected-error@+2{{_Float16 is not supported on this target}}
-#endif // HAVE
-_Float16 f;
-
-#ifdef HAVE
 _Complex _Float16 a;
 void builtin_complex(void) {
   _Float16 a = 0;
   (void)__builtin_complex(a, a); // expected-error {{'_Complex _Float16' is invalid}}
 }
-#endif
+
Index: clang/test/CodeGen/X86/Float16-complex.c
===
--- clang/test/CodeGen/X86/Float16-complex.c
+++ clang/test/CodeGen/X86/Float16-complex.c
@@ -1,4 +1,5 @@
 // RUN: %clang_cc1 %s -O0 -emit-llvm -triple x86_64-unknown-unknown -target-feature +avx512fp16 -o - | FileCheck %s --check-prefix=X86
+// RUN: %clang_cc1 %s -O0 -emit-llvm -triple x86_64-unknown-unknown -o - | FileCheck %s --check-prefixes=X86-PROM
 
 _Float16 _Complex add_half_rr(_Float16 a, _Float16 b) {
   // X86-LABEL: @add_half_rr(
@@ -85,7 +86,29 @@
   return a * b;
 }
 _Float16 _Complex mul_half_cc(_Float16 _Complex a, _Float16 _Complex b) {
-  // X86-LABEL: @mul_half_cc(
+  // CHECK: @mul_half_cc(
+
+  // X86-PROM: fpext half {{.*}} to float
+  // X86-PROM: fpext half {{.*}} to float
+  // X86-PROM: fpext half {{.*}} to float
+  // X86-PROM: fpext half {{.*}} to float
+  // X86-PROM: %[[AC:[^ ]+]] = fmul float
+  // X86-PROM: %[[BD:[^ ]+]] = fmul float
+  // X86-PROM: %[[AD:[^ ]+]] = fmul float
+  // X86-PROM: %[[BC:[^ ]+]] = fmul float
+  // X86-PROM: %[[RR:[^ ]+]] = fsub float
+  // X86-PROM: %[[RI:[^ ]+]] = fadd float
+  // X86-PROM: fcmp uno float %[[RR]]
+  // X86-PROM: fcmp uno float %[[RI]]
+  // X86-PROM: call <2 x float> @__mulsc3(
+  // X86-PROM: fptrunc float {{.*}} to half
+  // X86-PROM: fptrunc float {{.*}} to half
+  // X86-PROM: %[[RETR:[^ ]+]] = getelementptr inbounds { half, half }
+  // X86-PROM: %[[RETI:[^ ]+]] = getelementptr inbounds { half, half }
+  // X86-PROM: store half {{.*}}, ptr %[[RETR]]
+  // X86-PROM: store half {{.*}}, ptr %[[RETI]]
+  // X86-PROM: load 

[PATCH] D113107: Support of expression granularity for _Float16.

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam added a comment.

In D113107#3554538 , @rjmccall wrote:

> Hmm.  I'm sorry, seeing the impact of this, I think it's not great to have 
> this `PromotionTy` field; it's too hard to get the invariants right. Let's do 
> this instead:
>
> 1. Add an `EmitPromoted` method to `ScalarExprEmitter`.  The general rule for 
> this method is that it will generate a value of a promoted type, which should 
> be passed in.
> 2. Make `EmitBinOps` take an optional promotion type. If it's provided, it 
> should call `EmitPromoted` instead of `Visit` to emit the operands, and it 
> should set up the promotion type as the formal type of the operation.
> 3. In `EmitPromoted`, call `IgnoreParens` and then split into various cases:
>   - all the promotable floating-point arithmetic expressions (`BinAdd`, 
> `BinSub`, `BinMul`, `BinDiv`, and `UnaryMinus`), which should emit the 
> operands as promoted and then perform a promoted operation, like this:
>
>   return Emit##OP(EmitBinOps(E, promotionTy));
>
>   - anything that promotion should propagate through, which under the 
> standard should not include assignments or casts, but could include things 
> like the comma operator and the ternary operator;
>   - everything else, which should emit the expression normally and then 
> promote the result.
> 1. Change the standard path for the promotable arithmetic expressions (the 
> macro-expanded `VisitBinAdd` etc.) to detect the need to do a promoted 
> operation and then truncate, like this:
>
>   QualType promotionTy = getPromotionType(E);
>   auto result = Emit##OP(EmitBinOps(E, promotionTy));
>   if (result && promotionTy) result = Builder.CreateFPTrunc(result, 
> ConvertType(E->getType()), "unpromotion");
>   return result;

@rjmccall Thanks for that.
I think I am ok for 1. 2. and 4.
Still trying to figure out 3., EmitPromoted. When I make the change 4. the call 
 to  Emit##OP(EmitBinOps(E, promotionTy)); in VisitBinOP. Is this function 
still needed? Am i missing something?

Also these changes seem to be only for ScalarExprEmitter not for 
ComplexExpEmitter. I still need a call to  getPromotionType(E) for 
ComplexPairTy VisitBinAdd/Sub/Mul/Div , since there are also calling 
EmitBinOps, right?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D113107/new/

https://reviews.llvm.org/D113107

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D113107: Support of expression granularity for _Float16.

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam added a comment.

In D113107#3520773 , @rjmccall wrote:

> Okay, well, first off, we definitely shouldn't be repeating conditions like 
> `isX86()` all over the place.  What you want to do is to have a general 
> predicate which answers whether we should emit this operation with excess 
> precision; imagine an architecture that wanted to emit `float` operations 
> with `double` and try to design something that would work for both your case 
> and that one.
>
> It looks like you ought to be able to use the abstraction around `BinOpInfo` 
> to good effect here.  You can add a promotion type on the `ScalarExprEmitter` 
> which, if set, tells the emitter that it should actually produce a value of 
> that type.  `EmitBinOps` can recognize that a promotion type is already set 
> and use that type as the operation type instead of the formal type of the 
> expression.  If a promotion type isn't set on the emitter, `EmitBinOps` can 
> try to recognize that it's in the case where it needs a promotion type; it 
> would then set a promotion type before evaluating the operands, but then 
> truncate the result (and clear the promotion type) before returning.  The 
> logic around compound assignment will take some care (and good testing), but 
> it should work the same basic way, and similarly in the complex emitter.

@rjmccall  Thanks for the review. I have updated the patch. There are still a 
few things  that I am not sure about, so I haven't' changed the complex emitter 
yet!
I have added as you suggested a promotion type to the ScalarExprEmitter and 
pushed most of things in EmitBinOps. The one thing that I am not sure about is 
the truncation. I don't seem able to do that in EmitBinOps since I don't really 
have a lvalue available. Please let me know if this is in the direction that 
you expected it to.
Once again thanks for the review and at your convenience please take a look at 
these latest changes.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D113107/new/

https://reviews.llvm.org/D113107

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits