[PATCH] D39994: Loosen MSVC 2017 path requirements
dmajor added a comment. > Anyway, I'm just venting. If rnk@ wants to lgtm this, I'm fine. @rnk, any objection to this patch? https://reviews.llvm.org/D39994 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D51204: [COFF, ARM64] Add MS intrinsics: __getReg, _ReadStatusReg, _WriteStatusReg
dmajor added a comment. In https://reviews.llvm.org/D51204#1253230, @mgrang wrote: > Will abandon this patch since I have implementations of these which I will > upstream soon. Just to link up the reviews: these landed in https://reviews.llvm.org/D52838 and https://reviews.llvm.org/D53115. (Thanks @mgrang!) https://reviews.llvm.org/D51204 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D65403: [COFF, ARM64] Reorder handling of aarch64 MSVC builtins
dmajor created this revision. dmajor added reviewers: mgrang, efriedma, hans. Herald added subscribers: kristina, jfb, kristof.beyls, javed.absar. Herald added a project: clang. In `CodeGenFunction::EmitAArch64BuiltinExpr()`, bulk move of all of the aarch64 MSVC-builtin cases to an earlier point in the function (the `// Handle non-overloaded intrinsics first.` switch block) in order to avoid an unreachable in `GetNeonType()`. The NEON type-overloading logic is not appropriate for the Windows builtins. Fixes https://llvm.org/pr42775 Repository: rC Clang https://reviews.llvm.org/D65403 Files: lib/CodeGen/CGBuiltin.cpp test/CodeGen/arm64-microsoft-intrinsics.c Index: test/CodeGen/arm64-microsoft-intrinsics.c === --- test/CodeGen/arm64-microsoft-intrinsics.c +++ test/CodeGen/arm64-microsoft-intrinsics.c @@ -8,6 +8,10 @@ return _InterlockedAdd(Addend, Value); } +long test_InterlockedAdd_constant(long volatile *Addend) { + return _InterlockedAdd(Addend, -1); +} + // CHECK-LABEL: define {{.*}} i32 @test_InterlockedAdd(i32* %Addend, i32 %Value) {{.*}} { // CHECK-MSVC: %[[OLDVAL:[0-9]+]] = atomicrmw add i32* %1, i32 %2 seq_cst // CHECK-MSVC: %[[NEWVAL:[0-9]+]] = add i32 %[[OLDVAL:[0-9]+]], %2 Index: lib/CodeGen/CGBuiltin.cpp === --- lib/CodeGen/CGBuiltin.cpp +++ lib/CodeGen/CGBuiltin.cpp @@ -8011,6 +8011,151 @@ return Builder.CreateExtractElement(Ops[0], EmitScalarExpr(E->getArg(1)), "vgetq_lane"); } + case AArch64::BI_BitScanForward: + case AArch64::BI_BitScanForward64: +return EmitMSVCBuiltinExpr(MSVCIntrin::_BitScanForward, E); + case AArch64::BI_BitScanReverse: + case AArch64::BI_BitScanReverse64: +return EmitMSVCBuiltinExpr(MSVCIntrin::_BitScanReverse, E); + case AArch64::BI_InterlockedAnd64: +return EmitMSVCBuiltinExpr(MSVCIntrin::_InterlockedAnd, E); + case AArch64::BI_InterlockedExchange64: +return EmitMSVCBuiltinExpr(MSVCIntrin::_InterlockedExchange, E); + case AArch64::BI_InterlockedExchangeAdd64: +return EmitMSVCBuiltinExpr(MSVCIntrin::_InterlockedExchangeAdd, E); + case AArch64::BI_InterlockedExchangeSub64: +return EmitMSVCBuiltinExpr(MSVCIntrin::_InterlockedExchangeSub, E); + case AArch64::BI_InterlockedOr64: +return EmitMSVCBuiltinExpr(MSVCIntrin::_InterlockedOr, E); + case AArch64::BI_InterlockedXor64: +return EmitMSVCBuiltinExpr(MSVCIntrin::_InterlockedXor, E); + case AArch64::BI_InterlockedDecrement64: +return EmitMSVCBuiltinExpr(MSVCIntrin::_InterlockedDecrement, E); + case AArch64::BI_InterlockedIncrement64: +return EmitMSVCBuiltinExpr(MSVCIntrin::_InterlockedIncrement, E); + case AArch64::BI_InterlockedExchangeAdd8_acq: + case AArch64::BI_InterlockedExchangeAdd16_acq: + case AArch64::BI_InterlockedExchangeAdd_acq: + case AArch64::BI_InterlockedExchangeAdd64_acq: +return EmitMSVCBuiltinExpr(MSVCIntrin::_InterlockedExchangeAdd_acq, E); + case AArch64::BI_InterlockedExchangeAdd8_rel: + case AArch64::BI_InterlockedExchangeAdd16_rel: + case AArch64::BI_InterlockedExchangeAdd_rel: + case AArch64::BI_InterlockedExchangeAdd64_rel: +return EmitMSVCBuiltinExpr(MSVCIntrin::_InterlockedExchangeAdd_rel, E); + case AArch64::BI_InterlockedExchangeAdd8_nf: + case AArch64::BI_InterlockedExchangeAdd16_nf: + case AArch64::BI_InterlockedExchangeAdd_nf: + case AArch64::BI_InterlockedExchangeAdd64_nf: +return EmitMSVCBuiltinExpr(MSVCIntrin::_InterlockedExchangeAdd_nf, E); + case AArch64::BI_InterlockedExchange8_acq: + case AArch64::BI_InterlockedExchange16_acq: + case AArch64::BI_InterlockedExchange_acq: + case AArch64::BI_InterlockedExchange64_acq: +return EmitMSVCBuiltinExpr(MSVCIntrin::_InterlockedExchange_acq, E); + case AArch64::BI_InterlockedExchange8_rel: + case AArch64::BI_InterlockedExchange16_rel: + case AArch64::BI_InterlockedExchange_rel: + case AArch64::BI_InterlockedExchange64_rel: +return EmitMSVCBuiltinExpr(MSVCIntrin::_InterlockedExchange_rel, E); + case AArch64::BI_InterlockedExchange8_nf: + case AArch64::BI_InterlockedExchange16_nf: + case AArch64::BI_InterlockedExchange_nf: + case AArch64::BI_InterlockedExchange64_nf: +return EmitMSVCBuiltinExpr(MSVCIntrin::_InterlockedExchange_nf, E); + case AArch64::BI_InterlockedCompareExchange8_acq: + case AArch64::BI_InterlockedCompareExchange16_acq: + case AArch64::BI_InterlockedCompareExchange_acq: + case AArch64::BI_InterlockedCompareExchange64_acq: +return EmitMSVCBuiltinExpr(MSVCIntrin::_InterlockedCompareExchange_acq, E); + case AArch64::BI_InterlockedCompareExchange8_rel: + case AArch64::BI_InterlockedCompareExchange16_rel: + case AArch64::BI_InterlockedCompareExchange_rel: + case AArch64::BI_InterlockedCompareExchange64_rel: +return EmitMSVCBuiltinExpr(MSVCIntrin::_InterlockedCompareExchange_rel, E); + case AArch64::BI_InterlockedCompar
[PATCH] D65403: [COFF, ARM64] Reorder handling of aarch64 MSVC builtins
dmajor marked an inline comment as done. dmajor added inline comments. Comment at: lib/CodeGen/CGBuiltin.cpp:8182 switch (BuiltinID) { default: return nullptr; case NEON::BI__builtin_neon_vbsl_v: efriedma wrote: > I'm a little concerned about the overall code structure here; even if moving > the code for the MSVC builtins is enough to fix those builtins specifically, > is it actually impossible to hit this "default"? If it is, can we convert it > to an "unreachable"? I'm not sure if this question was directed to me... this was a drive-by patch from my end so I'm not familiar with what other types of builtins there might be. I should probably mention that I'm hoping to get a fix merged to 9.0 in order to unblock Firefox. Unless someone can tell me that the unreachable is definitely safe, I'd worry about adding instability into the release branch. Perhaps the unreachable could be done in a separate commit only on 10.0 trunk where the tolerance for surprises is generally better. Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D65403/new/ https://reviews.llvm.org/D65403 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D65403: [COFF, ARM64] Reorder handling of aarch64 MSVC builtins
This revision was automatically updated to reflect the committed changes. Closed by commit rL367323: [COFF][ARM64] Reorder handling of aarch64 MSVC builtins (authored by dmajor, committed by ). Herald added a project: LLVM. Herald added a subscriber: llvm-commits. Changed prior to commit: https://reviews.llvm.org/D65403?vs=212181&id=212355#toc Repository: rL LLVM CHANGES SINCE LAST ACTION https://reviews.llvm.org/D65403/new/ https://reviews.llvm.org/D65403 Files: cfe/trunk/lib/CodeGen/CGBuiltin.cpp cfe/trunk/test/CodeGen/arm64-microsoft-intrinsics.c Index: cfe/trunk/test/CodeGen/arm64-microsoft-intrinsics.c === --- cfe/trunk/test/CodeGen/arm64-microsoft-intrinsics.c +++ cfe/trunk/test/CodeGen/arm64-microsoft-intrinsics.c @@ -8,6 +8,10 @@ return _InterlockedAdd(Addend, Value); } +long test_InterlockedAdd_constant(long volatile *Addend) { + return _InterlockedAdd(Addend, -1); +} + // CHECK-LABEL: define {{.*}} i32 @test_InterlockedAdd(i32* %Addend, i32 %Value) {{.*}} { // CHECK-MSVC: %[[OLDVAL:[0-9]+]] = atomicrmw add i32* %1, i32 %2 seq_cst // CHECK-MSVC: %[[NEWVAL:[0-9]+]] = add i32 %[[OLDVAL:[0-9]+]], %2 Index: cfe/trunk/lib/CodeGen/CGBuiltin.cpp === --- cfe/trunk/lib/CodeGen/CGBuiltin.cpp +++ cfe/trunk/lib/CodeGen/CGBuiltin.cpp @@ -8014,6 +8014,151 @@ return Builder.CreateExtractElement(Ops[0], EmitScalarExpr(E->getArg(1)), "vgetq_lane"); } + case AArch64::BI_BitScanForward: + case AArch64::BI_BitScanForward64: +return EmitMSVCBuiltinExpr(MSVCIntrin::_BitScanForward, E); + case AArch64::BI_BitScanReverse: + case AArch64::BI_BitScanReverse64: +return EmitMSVCBuiltinExpr(MSVCIntrin::_BitScanReverse, E); + case AArch64::BI_InterlockedAnd64: +return EmitMSVCBuiltinExpr(MSVCIntrin::_InterlockedAnd, E); + case AArch64::BI_InterlockedExchange64: +return EmitMSVCBuiltinExpr(MSVCIntrin::_InterlockedExchange, E); + case AArch64::BI_InterlockedExchangeAdd64: +return EmitMSVCBuiltinExpr(MSVCIntrin::_InterlockedExchangeAdd, E); + case AArch64::BI_InterlockedExchangeSub64: +return EmitMSVCBuiltinExpr(MSVCIntrin::_InterlockedExchangeSub, E); + case AArch64::BI_InterlockedOr64: +return EmitMSVCBuiltinExpr(MSVCIntrin::_InterlockedOr, E); + case AArch64::BI_InterlockedXor64: +return EmitMSVCBuiltinExpr(MSVCIntrin::_InterlockedXor, E); + case AArch64::BI_InterlockedDecrement64: +return EmitMSVCBuiltinExpr(MSVCIntrin::_InterlockedDecrement, E); + case AArch64::BI_InterlockedIncrement64: +return EmitMSVCBuiltinExpr(MSVCIntrin::_InterlockedIncrement, E); + case AArch64::BI_InterlockedExchangeAdd8_acq: + case AArch64::BI_InterlockedExchangeAdd16_acq: + case AArch64::BI_InterlockedExchangeAdd_acq: + case AArch64::BI_InterlockedExchangeAdd64_acq: +return EmitMSVCBuiltinExpr(MSVCIntrin::_InterlockedExchangeAdd_acq, E); + case AArch64::BI_InterlockedExchangeAdd8_rel: + case AArch64::BI_InterlockedExchangeAdd16_rel: + case AArch64::BI_InterlockedExchangeAdd_rel: + case AArch64::BI_InterlockedExchangeAdd64_rel: +return EmitMSVCBuiltinExpr(MSVCIntrin::_InterlockedExchangeAdd_rel, E); + case AArch64::BI_InterlockedExchangeAdd8_nf: + case AArch64::BI_InterlockedExchangeAdd16_nf: + case AArch64::BI_InterlockedExchangeAdd_nf: + case AArch64::BI_InterlockedExchangeAdd64_nf: +return EmitMSVCBuiltinExpr(MSVCIntrin::_InterlockedExchangeAdd_nf, E); + case AArch64::BI_InterlockedExchange8_acq: + case AArch64::BI_InterlockedExchange16_acq: + case AArch64::BI_InterlockedExchange_acq: + case AArch64::BI_InterlockedExchange64_acq: +return EmitMSVCBuiltinExpr(MSVCIntrin::_InterlockedExchange_acq, E); + case AArch64::BI_InterlockedExchange8_rel: + case AArch64::BI_InterlockedExchange16_rel: + case AArch64::BI_InterlockedExchange_rel: + case AArch64::BI_InterlockedExchange64_rel: +return EmitMSVCBuiltinExpr(MSVCIntrin::_InterlockedExchange_rel, E); + case AArch64::BI_InterlockedExchange8_nf: + case AArch64::BI_InterlockedExchange16_nf: + case AArch64::BI_InterlockedExchange_nf: + case AArch64::BI_InterlockedExchange64_nf: +return EmitMSVCBuiltinExpr(MSVCIntrin::_InterlockedExchange_nf, E); + case AArch64::BI_InterlockedCompareExchange8_acq: + case AArch64::BI_InterlockedCompareExchange16_acq: + case AArch64::BI_InterlockedCompareExchange_acq: + case AArch64::BI_InterlockedCompareExchange64_acq: +return EmitMSVCBuiltinExpr(MSVCIntrin::_InterlockedCompareExchange_acq, E); + case AArch64::BI_InterlockedCompareExchange8_rel: + case AArch64::BI_InterlockedCompareExchange16_rel: + case AArch64::BI_InterlockedCompareExchange_rel: + case AArch64::BI_InterlockedCompareExchange64_rel: +return EmitMSVCBuiltinExpr(MSVCIntrin::_InterlockedCompareExchange_rel, E); + case AArch64::BI_InterlockedCompareExchange8_nf: + case AArch64::BI_InterlockedComp
[PATCH] D56326: [OpenMP 5.0] Parsing/sema support for "omp declare mapper" directive
dmajor added a comment. Herald added a reviewer: jdoerfert. Herald added a subscriber: erik.pilkington. While debugging something else, I noticed that with this patch, `Decl` now has 33 bits worth of bitfields, so it has gained an extra word. Is that ok? Just want to make sure it wasn't unintentional. Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D56326/new/ https://reviews.llvm.org/D56326 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D39994: Loosen MSVC 2017 path requirements
dmajor created this revision. Herald added subscribers: kristof.beyls, aemerson. Mozilla's build machines are currently applying this patch locally, but I thought I'd offer it upstream because it should be pretty harmless. clang-cl has some sanity checks to make sure that the cl.exe it finds is actually the Microsoft compiler and not something else. The code expects the path to look like: ...\VC\Tools\MSVC\14.11.25503\bin\HostX64\x64\cl.exe It doesn't work on Mozilla's build automation where we have a fake Visual Studio installation that looks like: c:\vs2017\VC\bin\HostX64\x64\cl.exe This patch reduces the path requirement to `...\bin\Host*\*\cl.exe`. https://reviews.llvm.org/D39994 Files: lib/Driver/ToolChains/MSVC.cpp Index: lib/Driver/ToolChains/MSVC.cpp === --- lib/Driver/ToolChains/MSVC.cpp +++ lib/Driver/ToolChains/MSVC.cpp @@ -152,8 +152,7 @@ // path components with these prefixes when walking backwards through // the path. // Note: empty strings match anything. -llvm::StringRef ExpectedPrefixes[] = {"", "Host", "bin", "", - "MSVC", "Tools", "VC"}; +llvm::StringRef ExpectedPrefixes[] = {"", "Host", "bin"}; auto It = llvm::sys::path::rbegin(PathEntry); auto End = llvm::sys::path::rend(PathEntry); Index: lib/Driver/ToolChains/MSVC.cpp === --- lib/Driver/ToolChains/MSVC.cpp +++ lib/Driver/ToolChains/MSVC.cpp @@ -152,8 +152,7 @@ // path components with these prefixes when walking backwards through // the path. // Note: empty strings match anything. -llvm::StringRef ExpectedPrefixes[] = {"", "Host", "bin", "", - "MSVC", "Tools", "VC"}; +llvm::StringRef ExpectedPrefixes[] = {"", "Host", "bin"}; auto It = llvm::sys::path::rbegin(PathEntry); auto End = llvm::sys::path::rend(PathEntry); ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits