[PATCH] D72110: [X86] ABI compat bugfix for MSVC vectorcall

craig.topper added inline comments. Comment at: clang/lib/CodeGen/TargetInfo.cpp:1648 + // a bit different than the x64 version. First, all vector types (not HVAs) + // are assigned, with the first 6 ending up in the YMM0-5 or XMM0-5 registers. + // This differs from the x64

[PATCH] D72114: [MS] Overhaul how clang passes overaligned args on x86_32

craig.topper added inline comments. Comment at: clang/test/CodeGen/x86_32-arguments-win32.c:77 +// CHECK-LABEL: define dso_local void @receive_vec_256(<8 x float> inreg %x, <8 x float> inreg %y, <8 x float> inreg %z, <8 x float>* %0, <8 x float>* %1) +// CHECK-LABEL: define dso_

[PATCH] D72053: [RFC] Handling implementation limits

craig.topper added inline comments. Comment at: clang/docs/ImplementationQuantities.rst:70 + +These limits are defined in the standards, but are imposed in Clang. + should this say ‘not defined’? CHANGES SINCE LAST ACTION https://reviews.llvm.org/D72053/new/

[PATCH] D72110: [X86] ABI compat bugfix for MSVC vectorcall

craig.topper accepted this revision. craig.topper added a comment. This revision is now accepted and ready to land. LGTM Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D72110/new/ https://reviews.llvm.org/D72110 ___

[PATCH] D69770: [APFloat] Add recoverable string parsing errors to APFloat

craig.topper added inline comments. Comment at: llvm/lib/Support/StringRef.cpp:593 + if (!ErrOrStatus) { +assert("Invalid floating point representation"); +return true; This is an invalid assert. lib/Support/StringRef.cpp:593:12: warning: implicit conve

[PATCH] D68720: Support -fstack-clash-protection for x86

craig.topper added inline comments. Comment at: clang/docs/ClangCommandLineReference.rst:1903 +.. option:: -fstack-clash-protection + Probably need a -fno-stack-class-protection as well. Looks like gcc has it. You'll need to update the handling in the driver t

[PATCH] D72247: Add Triple::isX86()

craig.topper accepted this revision. craig.topper added a comment. LGTM Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D72247/new/ https://reviews.llvm.org/D72247 ___ cfe-commits mailing list cfe-commits

[PATCH] D72227: Add options for clang to align branches within 32B boundary

craig.topper added inline comments. Comment at: clang/include/clang/Driver/Options.td:2196 +: Joined<["-"], "malign-branch-boundary=">, + Group, + Flags<[DriverOption, HelpHidden]>, MaskRay wrote: > `Group` Doesn't m_x86_Features_Group make things g

[PATCH] D71467: [FPEnv] Generate constrained FP comparisons from clang

craig.topper accepted this revision. craig.topper added a comment. This revision is now accepted and ready to land. LGTM CHANGES SINCE LAST ACTION https://reviews.llvm.org/D71467/new/ https://reviews.llvm.org/D71467 ___ cfe-commits mailing list c

[PATCH] D68720: Support -fstack-clash-protection for x86

craig.topper added inline comments. Comment at: clang/lib/CodeGen/CGStmt.cpp:2254 +CGM.getDiags().Report(S.getAsmLoc(), + diag::warn_fe_stack_clash_protection_inline_asm); + } serge-sans-paille wrote: > craig.topper wrote

[PATCH] D72820: Add pragma FP_CONTRACT support.

craig.topper added a comment. The title of this review is misleading. It should at least mention FPEnv, constrained intrinsics, or strict fp or something. Right now it sounds like FP_CONTRACT isn't supported at all. Can we split most of the X86 changes into a separate patch? Most of it can be

[PATCH] D72820: Add pragma FP_CONTRACT support.

craig.topper added inline comments. Comment at: llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp:7064 + + auto pushOutChain = [&]() { +assert(Result.getNode()->getNumValues() == 2); Can you make the SDValue Result an argument of this and only capture 't

[PATCH] D72820: Add pragma FP_CONTRACT support.

craig.topper added inline comments. Comment at: llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp:7061 + auto pushOutChain = [this](auto &Result, auto EB) { +assert(Result.getNode()->getNumValues() == 2); Why is Result a reference? It's not modified is

[PATCH] D87604: [X86] Convert integer _mm_reduce_* intrinsics to emit llvm.reduction intrinsics (PR47506)

craig.topper added a comment. Longer term should we have a variadic version of this like __builtin_shufflevector or __builtin_convertvector that can handle any reduction? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D87604/new/ https://reviews.ll

[PATCH] D87888: [X86] Use inlineasm flag output for the _bittest* intrinsics.

craig.topper created this revision. craig.topper added reviewers: rnk, niravd. Herald added a project: clang. craig.topper requested review of this revision. Instead of expliciting emitting a setc in the inline asm instructions, we can use flag output. This allows the backend to use the flag direc

[PATCH] D87888: [X86] Use inlineasm flag output for the _bittest* intrinsics.

craig.topper added a comment. In D87888#2281360 , @RKSimon wrote: > Do we have sufficient backend test coverage for this? Taking a closer look, I don't think our coverage is very good. We just have one test for each the 28 condition code strings we suppo

[PATCH] D87888: [X86] Use inlineasm flag output for the _bittest* intrinsics.

craig.topper added a comment. @rnk should this inline asm have a memory clobber on it? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D87888/new/ https://reviews.llvm.org/D87888 ___ cfe-commits mailing lis

[PATCH] D87888: [X86] Use inlineasm flag output for the _bittest* intrinsics.

craig.topper added a comment. In D87888#2285878 , @rnk wrote: > Honestly, I forget exactly what the memory clobber does beyond the > "sideeffect" marker. I would expect LLVM to model these just as external > function calls that could read or write memory

[PATCH] D88121: [X86] Add a memory clobber to the bittest intrinsic inline asm. Get default clobbers from the target

craig.topper created this revision. craig.topper added reviewers: RKSimon, spatel, rnk, echristo. craig.topper requested review of this revision. I believe the inline asm emitted here should have a memory clobber since it writes to memory. It was also missing the dirflag clobber that we use by d

[PATCH] D88121: [X86] Add a memory clobber to the bittest intrinsic inline asm. Get default clobbers from the target

craig.topper updated this revision to Diff 293789. craig.topper added a comment. Update more check lines to fully check the clobbers CHANGES SINCE LAST ACTION https://reviews.llvm.org/D88121/new/ https://reviews.llvm.org/D88121 Files: clang/lib/CodeGen/CGBuiltin.cpp clang/test/CodeGen/bi

[PATCH] D88121: [X86] Add a memory clobber to the bittest intrinsic inline asm. Get default clobbers from the target

This revision was automatically updated to reflect the committed changes. Closed by commit rGd9717d8ee714: [X86] Add a memory clobber to the bittest intrinsic inline asm. Get default… (authored by craig.topper). Herald added a project: clang. Changed prior to commit: https://reviews.llvm.org/D8

[PATCH] D87888: [X86] Use inlineasm flag output for the _bittest* intrinsics.

craig.topper updated this revision to Diff 294593. craig.topper added a comment. Herald added a project: LLVM. Herald added a subscriber: llvm-commits. Rebase and add a backend test file Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D87888/new/ http

[PATCH] D85384: [X86] Add basic support for -mtune command line option in clang

craig.topper added inline comments. Comment at: clang/test/Misc/target-invalid-cpu-note.c:49 + +// RUN: not %clang_cc1 -triple x86_64--- -tune-cpu not-a-cpu -fsyntax-only %s 2>&1 | FileCheck %s --check-prefix TUNE_X86_64 +// TUNE_X86_64: error: unknown target CPU 'not-a-cpu' ---

[PATCH] D85384: [X86] Add basic support for -mtune command line option in clang

This revision was automatically updated to reflect the committed changes. Closed by commit rG4cbceb74bb56: [X86] Add basic support for -mtune command line option in clang (authored by craig.topper). Herald added a project: clang. Changed prior to commit: https://reviews.llvm.org/D85384?vs=28345

[PATCH] D86187: [X86] Add support 'tune' in target attribute

craig.topper created this revision. craig.topper added reviewers: echristo, erichkeane, spatel, RKSimon. Herald added a reviewer: aaron.ballman. craig.topper requested review of this revision. This adds parsing and codegen support for tune in target attribute. I've implemented this so that arch i

[PATCH] D85384: [X86] Add basic support for -mtune command line option in clang

craig.topper added a subscriber: ddunbar. craig.topper added a comment. In D85384#2225434 , @phosek wrote: > This seems to have broken our Mac builders with the following error: > > -- Testing: 25226 tests, 24 workers -- > Testing: 0.. 10.. 20. > FA

[PATCH] D85384: [X86] Add basic support for -mtune command line option in clang

craig.topper added a comment. In D85384#2225459 , @echristo wrote: > This would be because at that point the default cpu was that and it > probably had something to do with fallbacks. > > At this point it can be changed I imagine to whatever makes sense.

[PATCH] D86229: [X86] Enable constexpr on POPCNT intrinsics (PR31446)

craig.topper added inline comments. Comment at: clang/lib/Headers/popcntintrin.h:16 +#ifdef __cplusplus +#define __DEFAULT_FN_ATTRS_CONSTEXPR __DEFAULT_FN_ATTRS constexpr Do we need to check for C++11? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST

[PATCH] D86229: [X86] Enable constexpr on POPCNT intrinsics (PR31446)

craig.topper added inline comments. Comment at: clang/test/CodeGen/popcnt-builtins.cpp:3 +// RUN: %clang_cc1 -std=c++11 -ffreestanding %s -triple=x86_64-apple-darwin -emit-llvm -o - | FileCheck %s + + arsenm wrote: > Missing required register target? Do we need

[PATCH] D86187: [X86] Add support 'tune' in target attribute

craig.topper updated this revision to Diff 286602. craig.topper added a comment. Add a note to AttrDocs.td CHANGES SINCE LAST ACTION https://reviews.llvm.org/D86187/new/ https://reviews.llvm.org/D86187 Files: clang/include/clang/AST/Attr.h clang/include/clang/Basic/Attr.td clang/includ

[PATCH] D86187: [X86] Add support 'tune' in target attribute

craig.topper added inline comments. Comment at: clang/include/clang/AST/Attr.h:346 + Tune == Other.Tune && + BranchProtection == Other.BranchProtection && + Features == Other.Features; Was it a bug that BranchProtection wasn't in the

[PATCH] D85384: [X86] Add basic support for -mtune command line option in clang

craig.topper added a comment. In D85384#2226842 , @aeubanks wrote: > This doesn't work with -mtune=generic > (https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html), can gcc compatibility > be added? > > (https://crbug.com/1119448) > > $ cat /tmp/a.c >

[PATCH] D86187: [X86] Add support 'tune' in target attribute

craig.topper added inline comments. Comment at: clang/test/Sema/attr-target.c:26 +//expected-warning@+1 {{unsupported tune 'hiss' in the 'target' attribute string; 'target' attribute ignored}} +int __attribute__((target("tune=hiss,tune=woof"))) apple_tree() { return 4; } + -

[PATCH] D86187: [X86] Add support 'tune' in target attribute

craig.topper updated this revision to Diff 286661. craig.topper added a comment. Refine the diagnostic message CHANGES SINCE LAST ACTION https://reviews.llvm.org/D86187/new/ https://reviews.llvm.org/D86187 Files: clang/include/clang/AST/Attr.h clang/include/clang/Basic/Attr.td clang/in

[PATCH] D86187: [X86] Add support 'tune' in target attribute

This revision was automatically updated to reflect the committed changes. Closed by commit rG724f570ad255: [X86] Add support 'tune' in target attribute (authored by craig.topper). Herald added a project: clang. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llv

[PATCH] D86229: [X86] Enable constexpr on POPCNT intrinsics (PR31446)

craig.topper added a comment. Should we test the intrinsics in a constexpr context? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D86229/new/ https://reviews.llvm.org/D86229 ___ cfe-commits mailing list c

[PATCH] D86310: [X86] Align i128 to 16 bytes in x86-64 datalayout

craig.topper created this revision. craig.topper added reviewers: efriedma, echristo, RKSimon, spatel. Herald added subscribers: nikic, dexonsmith, steven_wu, javed.absar, hiraditya, dschuff. Herald added a project: LLVM. craig.topper requested review of this revision. This is an attempt at reboo

[PATCH] D86229: [X86] Enable constexpr on POPCNT intrinsics (PR31446)

craig.topper accepted this revision. craig.topper added a comment. This revision is now accepted and ready to land. LGTM Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D86229/new/ https://reviews.llvm.org/D86229 _

[PATCH] D86310: [X86] Align i128 to 16 bytes in x86-64 datalayout

craig.topper added a comment. In D86310#2231136 , @efriedma wrote: > I'm afraid the AutoUpgrade component of this isn't compatible with existing > IR without some additional work. I'm most concerned about cases like the > following: > > #pragma pack(8

[PATCH] D86398: [X86] Enable constexpr on _cast fp<-> uint intrinsics (PR31446)

craig.topper accepted this revision. craig.topper added a comment. This revision is now accepted and ready to land. LGTM Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D86398/new/ https://reviews.llvm.org/D86398 _

[PATCH] D86488: [X86] Default to -mtune=generic unless -march is passed to the driver. Add TuneCPU to the AST serialization

craig.topper created this revision. craig.topper added reviewers: spatel, erichkeane, RKSimon, echristo, efriedma. craig.topper requested review of this revision. This patch defaults to -mtune=generic unless -march is present. If -march is present we'll use the empty string unless its overridden

[PATCH] D86503: [X86] Support -march=sapphirerapids

craig.topper accepted this revision. craig.topper added a comment. This revision is now accepted and ready to land. LGTM Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D86503/new/ https://reviews.llvm.org/D86503 _

[PATCH] D86488: [X86] Default to -mtune=generic unless -march is passed to the driver. Add TuneCPU to the AST serialization

craig.topper added inline comments. Comment at: clang/lib/Serialization/ASTReader.cpp:395 CHECK_TARGET_OPT(CPU, "target CPU"); +CHECK_TARGET_OPT(TuneCPU, "tune CPU"); + } erichkeane wrote: > What does this string do? Does there have to be a test for it

[PATCH] D86488: [X86] Default to -mtune=generic unless -march is passed to the driver. Add TuneCPU to the AST serialization

This revision was automatically updated to reflect the committed changes. Closed by commit rG71f3169e1bae: [X86] Default to -mtune=generic unless -march is passed to the driver. Add… (authored by craig.topper). Herald added a project: clang. Repository: rG LLVM Github Monorepo CHANGES SINCE LA

[PATCH] D86488: [X86] Default to -mtune=generic unless -march is passed to the driver. Add TuneCPU to the AST serialization

craig.topper added a comment. In D86488#2241176 , @nikic wrote: > This change has a 0.3% compile-time regression > (https://llvm-compile-time-tracker.com/compare.php?from=0c55889d809027136048a0d144209a2bc282e7fc&to=71f3169e1baeff262583b35ef88f8fb6df7be85e

[PATCH] D86820: [X86] Add a /tune: option for clang-cl

craig.topper created this revision. craig.topper added reviewers: rnk, thakis, hans, echristo, erichkeane. Herald added subscribers: dang, danielkiss. craig.topper requested review of this revision. We recently added support for -mtune. This patch adds /tune: so we can specify the tune CPU from c

[PATCH] D86855: Convert __m64 intrinsics to unconditionally use SSE2 instead of MMX instructions.

craig.topper added inline comments. Comment at: clang/lib/Headers/mmintrin.h:367 { -return (__m64)__builtin_ia32_paddb((__v8qi)__m1, (__v8qi)__m2); +return (__m64)(((__v8qi)__m1) + ((__v8qi)__m2)); } I think you we should use __v8qu to match what we do

[PATCH] D86820: [X86] Add a /tune: option for clang-cl

craig.topper added a comment. In D86820#2247336 , @hans wrote: > Would it be enough for users to specify /clang:-mtune instead? How does icc > spell its option? I didn't know you could spell it as /clang:-mtune. ICC has /tune: according to this docu

[PATCH] D86820: [X86] Add a /tune: option for clang-cl

craig.topper updated this revision to Diff 289273. craig.topper added a comment. Use an alias. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D86820/new/ https://reviews.llvm.org/D86820 Files: clang/include/clang/Driver/Options.td clang/test/Driver/cl-x86-flags.c Index: clang/test/

[PATCH] D86820: [X86] Add a /tune: option for clang-cl

This revision was automatically updated to reflect the committed changes. Closed by commit rGca134374b74e: [X86] Add a /tune: option for clang-cl (authored by craig.topper). Herald added a project: clang. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/

[PATCH] D87218: [builtins] Inline __paritysi2 into __paritydi2 and inline __paritydi2 into __parityti2.

craig.topper created this revision. craig.topper added reviewers: scanon, MaskRay, efriedma. Herald added a project: Sanitizers. Herald added a subscriber: Sanitizers. craig.topper requested review of this revision. No point in making __parityti2 go through 2 calls to get to __paritysi2. Reposit

[PATCH] D83360: [InstSimplify] Remove select ?, undef, X -> X and select ?, X, undef -> X

craig.topper abandoned this revision. craig.topper added a comment. This got replaced by D85765 Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D83360/new/ https://reviews.llvm.org/D83360

[PATCH] D87218: [builtins] Inline __paritysi2 into __paritydi2 and inline __paritydi2 into __parityti2.

craig.topper added a comment. In D87218#2259972 , @MaskRay wrote: > I think this is correct, but does their performance matter? > `llvm/IR/RuntimeLibcalls.def` does not define them (they cannot be produced > by llvm). Targets either emit popcount & 1 or

[PATCH] D87218: [builtins] Inline __paritysi2 into __paritydi2 and inline __paritydi2 into __parityti2.

This revision was automatically updated to reflect the committed changes. Closed by commit rG35f708a3c9ff: [builtins] Inline __paritysi2 into __paritydi2 and inline __paritydi2 into… (authored by craig.topper). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llv

[PATCH] D92812: [X86] AMD Znver3 (Family 19H) Enablement

craig.topper added a comment. Please upload the patch with full context Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D92812/new/ https://reviews.llvm.org/D92812 ___ cfe-commits mailing list cfe-commits@l

[PATCH] D92812: [X86] AMD Znver3 (Family 19H) Enablement

craig.topper added a subscriber: bkramer. craig.topper added inline comments. Comment at: clang/lib/Basic/Targets/X86.cpp:548 break; - case CK_ZNVER3: -defineCPUMacros(Builder, "znver3"); Why is this being deleted? Comment at: clang/l

[PATCH] D92715: [Clang][RISCV] Define RISC-V V builtin types

craig.topper added inline comments. Comment at: clang/include/clang/Basic/RISCVVTypes.def:67 +RVV_VECTOR_TYPE_INT("__rvv_int8m2_t", RvvInt8m2, RvvInt8m2Ty, 16, 8, 1, true) +RVV_VECTOR_TYPE_INT("__rvv_int8m4_t", RvvInt8m4, RvvInt8m4Ty, 32, 8, 1, true) +RVV_VECTOR_TYPE_IN

[PATCH] D92080: [Clang] Mutate long-double math builtins into f128 under IEEE-quad

craig.topper added a comment. I don't think I understand the whole picture here. Why would only builtins get mutated? Does a call to "modf" still call "modf"? But __builtin_modf will call modf128? Is there a corresponding patch to the runtime libcalls table in the backend? With -ffast-math __bu

[PATCH] D92715: [Clang][RISCV] Define RISC-V V builtin types

craig.topper added a comment. Can we discuss this patch in tomorrows RISC-V meeting? @jrtc27 @kito-cheng @khchen @liaolucy CHANGES SINCE LAST ACTION https://reviews.llvm.org/D92715/new/ https://reviews.llvm.org/D92715 ___ cfe-commits mailing list

[PATCH] D92715: [Clang][RISCV] Define RISC-V V builtin types

craig.topper added a comment. I think it would be possible to add a new attribute to define these types. But only specific values for parameters would be allowed so that it could only generate the exact types we see here and the future segment load patches. It wouldn't be general purpose like v

[PATCH] D87188: [InstCombine] Canonicalize SPF to abs intrinc

craig.topper added a comment. In D87188#2446096 , @spatel wrote: > In D87188#2445506 , @lebedev.ri > wrote: > >> Partial rebase (without updating test coverage) > > Thanks for reducing! > If I'm seeing it correctly

[PATCH] D92080: [Clang] Mutate long-double math builtins into f128 under IEEE-quad

craig.topper added a comment. In D92080#2448094 , @qiucf wrote: > In D92080#244 , @craig.topper > wrote: > >> I don't think I understand the whole picture here. Why would only builtins >> get mutated? Does a c

[PATCH] D93298: [RISCV] add the MC layer support of Zfinx extension

craig.topper added inline comments. Comment at: clang/lib/Basic/Targets/RISCV.h:40 : TargetInfo(Triple), HasM(false), HasA(false), HasF(false), HasD(false), -HasC(false), HasB(false), HasV(false), HasZfh(false) { LongDoubleWidth = 128; We real

[PATCH] D93446: [RISCV] Add vadd with mask and without mask builtin.

craig.topper added inline comments. Comment at: clang/lib/CodeGen/CGBuiltin.cpp:17569 + // The order of intrinsic operands is (maskedoff, op1, op2, mask, vl). + SmallVector ShuffleOps(Ops.size()); + ShuffleOps[0] = Ops[1]; I think this whole sequen

[PATCH] D90441: [X86] Add support for vex, vex2, vex3, and evex for MASM

craig.topper added inline comments. Comment at: llvm/lib/Target/X86/AsmParser/X86AsmParser.cpp:2851 +// Parse MASM style pseudo prefixes. +// FIXME: This prefix should only be used for MASM, not for intel-syntax. +if (isParsingIntelSyntax()) { epastor

[PATCH] D90822: [X86] use macros to split GFNI intrinsics into different kinds

craig.topper added inline comments. Comment at: clang/lib/Headers/gfniintrin.h:23 +#ifdef __AVX__ +#ifdef __AVX512BW__ This needs to be more like #if !(defined(_MSC_VER) || defined(__SCE__)) || __has_feature(modules) || \

[PATCH] D90822: [X86] use macros to split GFNI intrinsics into different kinds

craig.topper added a comment. What compilation failure do you get without this? The feature checks are compile time optimization for MSVC because windows.h includes intrin.h. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D90822/new/ https://reviews

[PATCH] D90822: [X86] use macros to split GFNI intrinsics into different kinds

craig.topper added a comment. In D90822#2375372 , @FreddyYe wrote: > The fails are all unknown type errors on Windows, since those typedefs are > declared in other header files. > The error message goes like: > > $ clang -march=tremont gfni.c > ..

[PATCH] D90822: [X86] use macros to split GFNI intrinsics into different kinds

craig.topper added a comment. In D90822#2375425 , @pengfei wrote: > In D90822#2375423 , @pengfei wrote: > >> Craig's method sounds good. > > I think it may result in potential problem once we change the order of the

[PATCH] D90822: [X86] use macros to split GFNI intrinsics into different kinds

craig.topper added a comment. In D90822#2375463 , @FreddyYe wrote: > In D90822#2375423 , @pengfei wrote: > >> Craig's method sounds good. >> @FreddyYe , Why we check AVX512BW instead of AVX512F. I saw SDM says it >

[PATCH] D90822: [X86] use macros to split GFNI intrinsics into different kinds

craig.topper accepted this revision. craig.topper added a comment. This revision is now accepted and ready to land. LGTM Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D90822/new/ https://reviews.llvm.org/D90822 _

[PATCH] D87981: [X86] AMX programming model.

craig.topper added a comment. This triggers an assertion in X86LowerAMXType::visit() when compiled with clang test.c -O3 typedef int vec1024 __attribute__((vector_size(1024))); vec1024 foo(vec1024 x, vec1024 y) { return x + y; } While deleting: <256 x i32> %x Use still stuck

[PATCH] D87981: [X86] AMX programming model.

craig.topper added a comment. Remind me what happened with the idea of using a dedicated type for tiles in IR like mmx? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D87981/new/ https://reviews.llvm.org/D87981 _

[PATCH] D91840: OpaquePtr: Require byval on x86_intrcc parameter 0

craig.topper added inline comments. Comment at: llvm/test/Bitcode/compatibility-6.0.ll:439 ; CHECK: declare hhvm_ccc void @f.hhvm_ccc() -declare cc83 void @f.cc83() +declare cc83 void @f.cc83(i8* byval(i8)) ; CHECK: declare x86_intrcc void @f.cc83() Why do we n

[PATCH] D87888: [X86] Use inlineasm flag output for the _bittest* intrinsics.

This revision was automatically updated to reflect the committed changes. Closed by commit rG288c5776c9d3: [X86] Use inlineasm flag output for the _bittest* intrinsics. (authored by craig.topper). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D87888/n

[PATCH] D87279: [clang] Fix handling of physical registers in inline assembly operands.

craig.topper added inline comments. Comment at: clang/lib/CodeGen/CGStmt.cpp:2090 +CGM.Error(S.getAsmLoc(), "Multiple outputs to hard register: " + GCCReg); + PhysRegOutputs.insert(GCCReg); +} Can we get rid of the count call above and just use

[PATCH] D89197: [X86] Support -march=x86-64-v[234]

craig.topper added a comment. Don't we need a change to X86.td too? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D89197/new/ https://reviews.llvm.org/D89197 ___ cfe-commits mailing list cfe-commits@lists

[PATCH] D89198: [X86] Define __LAHF_SAHF__ if feature 'sahf' is set

craig.topper added inline comments. Comment at: clang/lib/Basic/Targets/X86.cpp:564 + if (HasLAHFSAHF) +Builder.defineMacro("__LAHF_SAHF__"); if (HasLZCNT) It looks like gcc may define this always in 32-bit mode? Repository: rG LLVM Github Monorepo C

[PATCH] D89198: [X86] Define __LAHF_SAHF__ if feature 'sahf' is set

craig.topper added inline comments. Comment at: clang/lib/Basic/Targets/X86.cpp:564 + if (HasLAHFSAHF) +Builder.defineMacro("__LAHF_SAHF__"); if (HasLZCNT) craig.topper wrote: > It looks like gcc may define this always in 32-bit mode? More confusingly, th

[PATCH] D89198: [X86] Define __LAHF_SAHF__ if feature 'sahf' is set

craig.topper added inline comments. Comment at: clang/lib/Basic/Targets/X86.cpp:564 + if (HasLAHFSAHF) +Builder.defineMacro("__LAHF_SAHF__"); if (HasLZCNT) MaskRay wrote: > craig.topper wrote: > > craig.topper wrote: > > > It looks like gcc may define thi

[PATCH] D89198: [X86] Define __LAHF_SAHF__ if feature 'sahf' is set

craig.topper accepted this revision. craig.topper added a comment. This revision is now accepted and ready to land. LGTM Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D89198/new/ https://reviews.llvm.org/D89198 _

[PATCH] D89197: [X86] Support -march=x86-64-v[234]

craig.topper accepted this revision. craig.topper added a comment. This revision is now accepted and ready to land. LGTM Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D89197/new/ https://reviews.llvm.org/D89197 _

[PATCH] D89197: [X86] Support -march=x86-64-v[234]

craig.topper added a comment. In D89197#2323946 , @MaskRay wrote: > Test __LAHF_SAHF__ > Update clang/docs/ReleaseNotes.rst > Update clang/test/CodeGen/attr-target-x86.c to test X86.td changes. Ideally > "target-features" should be testable with llc to ha

[PATCH] D89197: [X86] Support -march=x86-64-v[234]

craig.topper accepted this revision. craig.topper added a comment. LGTM Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D89197/new/ https://reviews.llvm.org/D89197 ___ cfe-commits mailing list cfe-commits@l

[PATCH] D89102: [X86] Add HRESET instruction.

craig.topper accepted this revision. craig.topper added a comment. This revision is now accepted and ready to land. LGTM Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D89102/new/ https://reviews.llvm.org/D89102 _

[PATCH] D87604: [X86] Convert integer _mm_reduce_* intrinsics to emit llvm.reduction intrinsics (PR47506)

craig.topper accepted this revision. craig.topper added a comment. This revision is now accepted and ready to land. LGTM Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D87604/new/ https://reviews.llvm.org/D87604 _

[PATCH] D89184: Support complex target features combinations

craig.topper added a comment. This is needed for D89105 and was split from it. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D89184/new/ https://reviews.llvm.org/D89184 ___ cfe-commits mailing list cfe-commit

[PATCH] D89405: [CodeGen][X86] Emit fshl/fshr ir intrinsics for shiftleft128/shiftright128 ms intrinsics

craig.topper accepted this revision. craig.topper added a comment. This revision is now accepted and ready to land. LGTM Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D89405/new/ https://reviews.llvm.org/D89405 _

[PATCH] D91927: [X86] Add x86_amx type for intel AMX.

craig.topper added a comment. I only took a quick pass through this so far. What happens if a bitcast between x86amx and v256i32(or any other 1024-bit vector type) exists in the IR but isn't next to a load/store? Comment at: llvm/lib/Target/X86/X86ISelLowering.cpp:5334 //

[PATCH] D91927: [X86] Add x86_amx type for intel AMX.

craig.topper added a comment. In D91927#2412604 , @LuoYuanke wrote: > In D91927#2412557 , @craig.topper > wrote: > >> I only took a quick pass through this so far. What happens if a bitcast >> between x86amx and

[PATCH] D91927: [X86] Add x86_amx type for intel AMX.

craig.topper added inline comments. Comment at: llvm/lib/Target/X86/X86LowerAMXType.cpp:72 LLVMContext &Ctx = Builder.getContext(); - Type *Ty = LD->getType(); - EVT VT = EVT::getEVT(Ty); - EVT HalfVT = VT.getHalfNumVectorElementsVT(Ctx); - Type *HalfTy = HalfVT.getTypeFor

[PATCH] D92080: [Clang] Mutate long-double math builtins into f128 under IEEE-quad

craig.topper added a comment. gcc calls the *l version with -mlong-double-128 on x86. Should we match gcc here? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D92080/new/ https://reviews.llvm.org/D92080 _

[PATCH] D88394: [Driver][M68k] (Patch 8/8) Add driver support for M68k

craig.topper added inline comments. Comment at: clang/include/clang/Driver/Options.td:164 +def m_m68k_Features_Group: OptionGroup<"">, + Group, DocName<"M68k">; def m_mips_Features_Group : OptionGroup<"">, bruno wrote: > Looks like th

[PATCH] D92715: [Clang][RISCV] Define RISC-V V builtin types

craig.topper added a comment. Can you re-upload the patch with full context? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D92715/new/ https://reviews.llvm.org/D92715 ___ cfe-commits mailing list cfe-comm

[PATCH] D92715: [Clang][RISCV] Define RISC-V V builtin types

craig.topper added inline comments. Comment at: clang/include/clang/Basic/RISCVVTypes.def:32 +// - ElBits is the size of one element in bits (SEW). +// +// - IsSigned is true for vectors of signed integer elements and NF argument isn't documented. And is always 1

[PATCH] D92715: [Clang][RISCV] Define RISC-V V builtin types

craig.topper added inline comments. Comment at: clang/include/clang/Basic/RISCVVTypes.def:67 +RVV_VECTOR_TYPE_INT("__rvv_int8m2_t", RvvInt8m2, RvvInt8m2Ty, 16, 8, 1, true) +RVV_VECTOR_TYPE_INT("__rvv_int8m4_t", RvvInt8m4, RvvInt8m4Ty, 32, 8, 1, true) +RVV_VECTOR_TYPE_IN

[PATCH] D92715: [Clang][RISCV] Define RISC-V V builtin types

craig.topper added inline comments. Comment at: clang/include/clang/Basic/RISCVVTypes.def:67 +RVV_VECTOR_TYPE_INT("__rvv_int8m2_t", RvvInt8m2, RvvInt8m2Ty, 16, 8, 1, true) +RVV_VECTOR_TYPE_INT("__rvv_int8m4_t", RvvInt8m4, RvvInt8m4Ty, 32, 8, 1, true) +RVV_VECTOR_TYPE_IN

[PATCH] D89664: [X86] Add missing code in D89102 [X86] Add HRESET instruction.

craig.topper added inline comments. Comment at: llvm/lib/Target/X86/X86.td:770 FeaturePTWRITE, + FeatureHRESET, FeatureTSXLDTRK,

[PATCH] D89301: [X86] Add user-level interrupt instructions

craig.topper added inline comments. Comment at: llvm/lib/Target/X86/X86InstrInfo.td:320 +def X86testui : SDNode<"X86ISD::TESTUI", + SDTypeProfile<1, 0, [SDTCisVT<0, i32>]>, [SDNPHasChain]>; I think this should have SDNPSideEffect to match

[PATCH] D89301: [X86] Add User Interrupts(UINTR) instructions

craig.topper accepted this revision. craig.topper added a comment. This revision is now accepted and ready to land. LGTM Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D89301/new/ https://reviews.llvm.org/D89301 _

<    2   3   4   5   6   7   8   9   10   11   >