[PATCH] D151834: Include math-errno with fast-math

andrew.w.kaylor added inline comments. Comment at: clang/lib/CodeGen/CGBuiltin.cpp:2249 + // MSVC takes into account math-errno when compiling at -O2 level in + // the presence of a '#pragma float_control precise(on/off)'. Since we handle "#pragma float_contr

[PATCH] D139629: clang: Stop emitting "strictfp"

andrew.w.kaylor added a subscriber: erichkeane. andrew.w.kaylor added inline comments. Comment at: clang/lib/CodeGen/CodeGenModule.cpp:2135 -llvm::AttrBuilder FuncAttrs(F->getContext()); -FuncAttrs.addAttribute("strictfp"); -F->addFnAttrs(FuncAttrs);

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

andrew.w.kaylor added inline comments. Comment at: clang/test/CodeGen/X86/fexcess-precision.c:89 +// CHECK-EXT-NEXT:[[EXT1:%.*]] = fpext half [[TMP1]] to float +// CHECK-EXT-NEXT:[[MUL:%.*]] = fmul float [[EXT]], [[EXT1]] +// CHECK-EXT-NEXT:[[TMP2:%.*]] = load half, p

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

andrew.w.kaylor added inline comments. Comment at: clang/test/CodeGen/X86/fexcess-precision.c:89 +// CHECK-EXT-NEXT:[[EXT1:%.*]] = fpext half [[TMP1]] to float +// CHECK-EXT-NEXT:[[MUL:%.*]] = fmul float [[EXT]], [[EXT1]] +// CHECK-EXT-NEXT:[[TMP2:%.*]] = load half, p

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

andrew.w.kaylor accepted this revision. andrew.w.kaylor added a comment. This revision is now accepted and ready to land. With the latest test cases and explanations, I'm happy with this patch. @rjmccall is there anything else you wanted to see addressed? CHANGES SINCE LAST ACTION https://rev

[PATCH] D30662: Update clang filtering for mxcsr

andrew.w.kaylor created this revision. This patch updates the clang function that filters the mxcsr register name to recognize that mxcsr is being split into two pseduo-registers that model the control and status bits separately. Repository: rL LLVM https://reviews.llvm.org/D30662 Files:

[PATCH] D30662: Update clang filtering for mxcsr

andrew.w.kaylor added a comment. In https://reviews.llvm.org/D30662#693559, @ahatanak wrote: > Is it possible to add a test case (possibly in CodeGen)? This is covered by CodeGen/ms-inline-asm.c, which Reid added after I broke this adding the mxcsr register a couple of weeks ago. Repository:

[PATCH] D114564: Fix the use of -fno-approx-func along with -Ofast or -ffast-math

andrew.w.kaylor accepted this revision. andrew.w.kaylor added a comment. This revision is now accepted and ready to land. lgtm Comment at: clang/lib/Driver/ToolChains/Clang.cpp:2760 case options::OPT_fno_honor_nans: HonorNaNs = false;break; case options:

[PATCH] D120395: [X86] Prohibit arithmatic operations on type `__bfloat16`

andrew.w.kaylor added a comment. In D120395#3340496 , @pengfei wrote: > Update LangRef. We use `i16` type to represent bfloat16. Why are we using i16 to represent bfloat16? The bfloat type is better. Repository: rG LLVM Github Monorepo CHANGES SINCE

[PATCH] D120395: [X86] Prohibit arithmatic operations on type `__bfloat16`

andrew.w.kaylor added a comment. In D120395#3340953 , @craig.topper wrote: > These intrinsics pre-date the existence of the bfloat type in LLVM. To use > bfloat we have to make __bf16 a legal type in C. This means we need to > support loads, stores, an

[PATCH] D120395: [X86] Prohibit arithmetic operations on type `__bfloat16`

andrew.w.kaylor added a comment. In D120395#3344890 , @pengfei wrote: > Disscussed with GCC folks. We think it's better to use the same way as > D120411 that replacing it with short int. Which GCC folks did you discuss

[PATCH] D120395: [X86] Prohibit arithmetic operations on type `__bfloat16`

andrew.w.kaylor added inline comments. Comment at: clang/lib/Headers/avx512bf16intrin.h:37 ///and fraction field is extended to 23 bits. -static __inline__ float __DEFAULT_FN_ATTRS _mm_cvtsbh_ss(__bfloat16 __A) { +static __inline__ float __DEFAULT_FN_ATTRS _mm_cvtsbh_ss(unsi

[PATCH] D120411: [X86] Replace __m[128|256|512]bh with __m[128|256|512]i and mark the former deprecated

andrew.w.kaylor requested changes to this revision. andrew.w.kaylor added a comment. This revision now requires changes to proceed. Replacing `__m128bh` with `__m128i` does not prevent arithmetic operations on the type. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://

[PATCH] D120395: [X86] Prohibit arithmetic operations on type `__bfloat16`

andrew.w.kaylor added a comment. Herald added a project: All. In D120395#3346591 , @scanon wrote: > There's a lot of churn around proposed "solutions" on this and related PR, > but not a very clear analysis of what the problem we're trying to solve is.

[PATCH] D120395: [X86] Prohibit arithmetic operations on type `__bfloat16`

andrew.w.kaylor added a comment. In D120395#3356355 , @pengfei wrote: > Good question! This is actually the scope of ABI. Unfortunately, we don't > have the BF16 ABI at the present. We can't assume what are the physical > registers the arguments been pa

[PATCH] D120395: [X86] Prohibit arithmetic operations on type `__bfloat16`

andrew.w.kaylor added a comment. In D120395#3358533 , @craig.topper wrote: > __m256bh should not have been a new type. It should have been an alias of > __m256i. We don't have load/store intrinsics for __m256bh so if you can even > get the __m256bh typ

[PATCH] D120395: [X86] Prohibit arithmetic operations on type `__bfloat16`

andrew.w.kaylor added a comment. In D120395#3359255 , @pengfei wrote: > I don't agree. Unlike `__fp16`, `__bf16` is simple an ARM specific type. Why is __bf16 an ARM-specific type? It's a type that describes a floating point value with a specific binary

[PATCH] D121122: Set FLT_EVAL_METHOD to -1 when fast-math is enabled.

andrew.w.kaylor added a comment. The fix for the eval_method crash should be moved to a separate patch. Otherwise, this looks good. I have only minor comments. Comment at: clang/lib/Lex/PPMacroExpansion.cpp:1600 +} else { + OS << getTUFPEvalMethod(); + // __FLT_E

[PATCH] D99675: RFC [llvm][clang] Create new intrinsic llvm.arith.fence to control FP optimization at expression level

andrew.w.kaylor added a comment. In D99675#2671924 , @efriedma wrote: >> The expression “llvm.arith.fence(a * b) + c” means that “a * b” must happen >> before “+ c” and FMA guarantees that, but to prevent later optimizations >> from unpacking the FMA the

<    1   2