@@ -3963,8 +3995,8 @@ ExprResult Sema::BuildAtomicExpr(SourceRange CallRange,
SourceRange ExprRange,
return ExprError();
}
- if (!IsC11 && !AtomTy.isTriviallyCopyableType(Context) &&
- !AtomTy->isScalarType()) {
+ if (!IsC11 && Form != TestAndSet && Form != Clear
@@ -3686,12 +3687,18 @@ ExprResult Sema::BuildAtomicExpr(SourceRange CallRange,
SourceRange ExprRange,
C11CmpXchg,
// bool __atomic_compare_exchange(A *, C *, CP, bool, int, int)
-GNUCmpXchg
+GNUCmpXchg,
+
+// bool __atomic_test_and_set(A *, int)
+Test
https://github.com/jyknight commented:
Looks basically good to me, just a couple suggestions to improve the code
clarity.
https://github.com/llvm/llvm-project/pull/121943
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/c
@@ -3911,14 +3926,31 @@ ExprResult Sema::BuildAtomicExpr(SourceRange CallRange,
SourceRange ExprRange,
}
}
- // Pointer to object of size zero is not allowed.
- if (RequireCompleteType(Ptr->getBeginLoc(), AtomTy,
- diag::err_incomplete_type))
@@ -1977,16 +1977,16 @@ def AtomicNandFetch : AtomicBuiltin {
let Prototype = "void(...)";
}
-def AtomicTestAndSet : Builtin {
+def AtomicTestAndSet : AtomicBuiltin {
let Spellings = ["__atomic_test_and_set"];
- let Attributes = [NoThrow];
- let Prototype = "bool(void v
https://github.com/jyknight edited
https://github.com/llvm/llvm-project/pull/121943
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jyknight wrote:
Yes, the code in libpcap is correct, and the new Clang behavior is incorrect.
`__atomic_clear` and `__atomic_test_and_set` are intentionally different from
the other atomic builtins, in that they are _not_ type-generic, but instead
always operate on the single byte at the provi
jyknight wrote:
Hm, I had a thought which might meet the needs here, and not add additional
confusion: we could have the Darwin SDKROOT environment variable override both
`-isysroot` and `--sysroot`. Would that help the original issue?
https://github.com/llvm/llvm-project/pull/115993
_
jyknight wrote:
This is the intended/expected behavior.
On every other platform, `-isysroot` is supposed to be an override setting the
sysroot only for the header files, and _never_ overriding the linker sysroot.
The `--sysroot` flag, on the other hand, sets the value used for both libraries
https://github.com/jyknight approved this pull request.
https://github.com/llvm/llvm-project/pull/117364
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -2047,6 +2047,14 @@ StringRef CodeGenModule::getMangledName(GlobalDecl GD) {
GD.getWithKernelReferenceKind(KernelReferenceKind::Kernel),
ND));
+ // This invariant should hold true in the future.
+ // Prior work:
+ //
https://discourse.l
Author: James Y Knight
Date: 2024-11-21T21:03:11-05:00
New Revision: dc580c9cf65d9bdad92e127325b50e712422379b
URL:
https://github.com/llvm/llvm-project/commit/dc580c9cf65d9bdad92e127325b50e712422379b
DIFF:
https://github.com/llvm/llvm-project/commit/dc580c9cf65d9bdad92e127325b50e712422379b.diff
jyknight wrote:
(...and maybe we could also get rid of the similar hacks we did for
_mm_mfence/etc before? The commit message for
727ab8a80346eeec39e13293f5dc01cc82bb1d95 didn't say anything about the
rationale, but if it's the same as this, then perhaps so?)
https://github.com/llvm/llvm-proj
jyknight wrote:
So, this is interesting, because the decls _already_ don't conflict, normally.
They only conflict if the x86intrin.h is included within a `extern "C++" {}`
block, _and_ is included after windows.h.
It comes down to, effectively this. Note, run the examples with
`-fms-extension
jyknight wrote:
Some projects still seem to have a requirement for compatibility with GCC 4.8
-- which supports a lot of C++11 but didn't apply the change in CWG 1473, and
thus _require_ the space in `operator"" _udl`. That is somewhat unfortunate.
Two examples from the first page of github se
jyknight wrote:
Here's another test-case which is broken by this commit (both at this commit,
and after the follow-up PRs). It seems to no longer allow non-type template
packs of multiple types. I'm surprised we have no test-cases for this in the
clang test-suite!
```
template class Arg>
str
jyknight wrote:
> I think that's a separable issue from this PR
Yep. I brought it up mainly in case consideration of that set of issues might
necessitate design changes here. It sounds like that's not the case though, so
I'm happy for it to not be a blocker for this PR.
https://github.com/llv
jyknight wrote:
I worry about string literals in vague-linkage entities, because the "version"
of the string literal which is referred to from an inline-function/variable at
runtime may not actually be the same version of the string literal seen in the
current compilation -- at runtime we may
https://github.com/jyknight closed
https://github.com/llvm/llvm-project/pull/107155
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jyknight wrote:
I'll commit as soon as anyone gives it an approval. :)
https://github.com/llvm/llvm-project/pull/107155
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jyknight wrote:
If we don't keep the include-guard, then we'll report the same warning once per
`#include`, instead of once per TU, which is probably not ideal.
https://github.com/llvm/llvm-project/pull/107155
___
cfe-commits mailing list
cfe-commits@
jyknight wrote:
The only impact is that any modular header which includes this file will end up
with a definition of the header guard, instead of importing it, right? It's not
clear to me why it's useful to care about that?
(I totally do understand worrying about cases which result in e.g. hav
https://github.com/jyknight created
https://github.com/llvm/llvm-project/pull/107155
This avoids issuing the deprecation diagnostic when building the module.
Not building it into a module shouldn't cause any negative impacts, since it no
longer has any declarations other than the header guard.
jyknight wrote:
Do the include guard macros make it problematic to expose as a textual header?
I would not have thought that to be the case.
https://github.com/llvm/llvm-project/pull/96246
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https:
jyknight wrote:
I think we can just switch it to be a textual header; it no longer has any
decls.
https://github.com/llvm/llvm-project/pull/96246
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/c
jyknight wrote:
We aren't compliant for assignment either with x87 float/double -- e.g. enable
`-O2` on your example.
I think we need to say that we conform except on 32-bit x86 with SSE2 disabled,
and link to an appropriate bug. Maybe we'll fix that backend someday. Or maybe
not.
https://gi
https://github.com/jyknight approved this pull request.
LGTM, thanks.
https://github.com/llvm/llvm-project/pull/101005
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jyknight wrote:
It seems a bit confusing to me to create a situation where `-ffast-math` is
equivalent to `-ffp-model=aggressive`, not `-ffp-model=fast`.
https://github.com/llvm/llvm-project/pull/100453
___
cfe-commits mailing list
cfe-commits@lists.l
jyknight wrote:
@RKSimon has fixed in abacc5220e228012b0b86ca2ed540ef1a715f1ee, thanks. Sorry
for missing that!
https://github.com/llvm/llvm-project/pull/98505
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mail
@@ -94,14 +94,15 @@ entry:
;
; MMX Store
+; Note: doesn't actually emit a non-temporal store here.
;
define void @test_mmx(ptr nocapture %a0, ptr nocapture %a1) {
; ALL-LABEL: test_mmx:
; ALL: # %bb.0: # %entry
; ALL-NEXT:movq (%rdi), %mm0
; ALL-NEXT:psrl
@@ -159,6 +159,20 @@ AMDGPU Support
X86 Support
^^^
+- The MMX vector intrinsic functions from ``*mmintrin.h`` which
+ operate on `__m64` vectors, such as ``_mm_add_pi8``, have been
+ reimplemented to use the SSE2 instruction-set and XMM registers
+ unconditionally.
Author: James Y Knight
Date: 2024-07-24T18:39:16-04:00
New Revision: b79568654e38a14ef921af932ed96abd8961b1ed
URL:
https://github.com/llvm/llvm-project/commit/b79568654e38a14ef921af932ed96abd8961b1ed
DIFF:
https://github.com/llvm/llvm-project/commit/b79568654e38a14ef921af932ed96abd8961b1ed.diff
https://github.com/jyknight closed
https://github.com/llvm/llvm-project/pull/96540
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -49,12 +49,10 @@ typedef __bf16 __m128bh __attribute__((__vector_size__(16),
__aligned__(16)));
#endif
/* Define the default attributes for the functions in this file. */
-#define __DEFAULT_FN_ATTRS
\
- __attribute__((_
https://github.com/jyknight updated
https://github.com/llvm/llvm-project/pull/98273
>From 546963316017935bfbbc05d7095d645344fbd5f5 Mon Sep 17 00:00:00 2001
From: James Y Knight
Date: Wed, 10 Jul 2024 00:49:25 -0400
Subject: [PATCH 1/3] Clang: don't unnecessarily convert inline-asm operands to
https://github.com/jyknight closed
https://github.com/llvm/llvm-project/pull/99340
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jyknight updated
https://github.com/llvm/llvm-project/pull/99340
>From 2cb327b0377d4196982842455e2aaf4e6a21f667 Mon Sep 17 00:00:00 2001
From: James Y Knight
Date: Wed, 17 Jul 2024 10:43:45 -0400
Subject: [PATCH 1/4] Handle constant "pointers" for
`__atomic_always_lock_free`
@@ -94,14 +94,15 @@ entry:
;
; MMX Store
+; Note: doesn't actually emit a non-temporal store here.
;
define void @test_mmx(ptr nocapture %a0, ptr nocapture %a1) {
; ALL-LABEL: test_mmx:
; ALL: # %bb.0: # %entry
; ALL-NEXT:movq (%rdi), %mm0
; ALL-NEXT:psrl
https://github.com/jyknight closed
https://github.com/llvm/llvm-project/pull/99352
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jyknight edited
https://github.com/llvm/llvm-project/pull/99352
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jyknight edited
https://github.com/llvm/llvm-project/pull/99352
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jyknight edited
https://github.com/llvm/llvm-project/pull/99352
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jyknight updated
https://github.com/llvm/llvm-project/pull/99352
>From 70160e033ac94de92fc2cd6289548094cd893498 Mon Sep 17 00:00:00 2001
From: James Y Knight
Date: Wed, 17 Jul 2024 11:40:38 -0400
Subject: [PATCH 1/5] Remove 3dnow from X86TargetParser.
This should've been par
jyknight wrote:
I believe all the comments here are addressed; any more concerns/comments, or
is this good to go?
https://github.com/llvm/llvm-project/pull/96540
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/ma
https://github.com/jyknight updated
https://github.com/llvm/llvm-project/pull/99340
>From 2cb327b0377d4196982842455e2aaf4e6a21f667 Mon Sep 17 00:00:00 2001
From: James Y Knight
Date: Wed, 17 Jul 2024 10:43:45 -0400
Subject: [PATCH 1/3] Handle constant "pointers" for
`__atomic_always_lock_free`
https://github.com/jyknight edited
https://github.com/llvm/llvm-project/pull/99340
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -124,6 +124,24 @@ _Static_assert(__atomic_always_lock_free(4, &i64), "");
_Static_assert(!__atomic_always_lock_free(8, &i32), "");
_Static_assert(__atomic_always_lock_free(8, &i64), "");
+// Validate use with fake pointers constants. This mechanism is used to allow
+// vali
https://github.com/jyknight updated
https://github.com/llvm/llvm-project/pull/99340
>From 2cb327b0377d4196982842455e2aaf4e6a21f667 Mon Sep 17 00:00:00 2001
From: James Y Knight
Date: Wed, 17 Jul 2024 10:43:45 -0400
Subject: [PATCH 1/2] Handle constant "pointers" for
`__atomic_always_lock_free`
@@ -175,8 +175,6 @@ X86_FEATURE_COMPAT(AVX512BF16, "avx512bf16",
34)
X86_FEATURE_COMPAT(AVX512VP2INTERSECT, "avx512vp2intersect", 35)
// Below Features has some missings comparing to gcc, it's because gcc has some
// not one-to-one mapped in llvm.
-X86_FEATURE_
https://github.com/jyknight updated
https://github.com/llvm/llvm-project/pull/99352
>From 70160e033ac94de92fc2cd6289548094cd893498 Mon Sep 17 00:00:00 2001
From: James Y Knight
Date: Wed, 17 Jul 2024 11:40:38 -0400
Subject: [PATCH 1/4] Remove 3dnow from X86TargetParser.
This should've been par
@@ -175,8 +175,6 @@ X86_FEATURE_COMPAT(AVX512BF16, "avx512bf16",
34)
X86_FEATURE_COMPAT(AVX512VP2INTERSECT, "avx512vp2intersect", 35)
// Below Features has some missings comparing to gcc, it's because gcc has some
// not one-to-one mapped in llvm.
-X86_FEATURE_
@@ -124,6 +124,24 @@ _Static_assert(__atomic_always_lock_free(4, &i64), "");
_Static_assert(!__atomic_always_lock_free(8, &i32), "");
_Static_assert(__atomic_always_lock_free(8, &i64), "");
+// Validate use with fake pointers constants. This mechanism is used to allow
+// vali
https://github.com/jyknight updated
https://github.com/llvm/llvm-project/pull/99352
>From 70160e033ac94de92fc2cd6289548094cd893498 Mon Sep 17 00:00:00 2001
From: James Y Knight
Date: Wed, 17 Jul 2024 11:40:38 -0400
Subject: [PATCH 1/3] Remove 3dnow from X86TargetParser.
This should've been par
@@ -171,14 +171,14 @@ constexpr FeatureBitset FeaturesClearwaterforest =
// Geode Processor.
constexpr FeatureBitset FeaturesGeode =
-FeatureX87 | FeatureCMPXCHG8B | FeatureMMX | Feature3DNOW | Feature3DNOWA;
jyknight wrote:
OK, making the change.
I note
https://github.com/jyknight approved this pull request.
Thanks, LGTM. I like this version.
Did this change also fix any other bugs? Since it looks like we were previously
not skipping ProcessDeclAttribute for ``[[]]`` attributes in C23 mode, when
IncludeCXX11Attributes == false, and we were su
@@ -171,14 +171,14 @@ constexpr FeatureBitset FeaturesClearwaterforest =
// Geode Processor.
constexpr FeatureBitset FeaturesGeode =
-FeatureX87 | FeatureCMPXCHG8B | FeatureMMX | Feature3DNOW | Feature3DNOWA;
jyknight wrote:
(I somewhat lean towards submi
@@ -171,14 +171,14 @@ constexpr FeatureBitset FeaturesClearwaterforest =
// Geode Processor.
constexpr FeatureBitset FeaturesGeode =
-FeatureX87 | FeatureCMPXCHG8B | FeatureMMX | Feature3DNOW | Feature3DNOWA;
jyknight wrote:
Possibly not?
We didn't enabl
https://github.com/jyknight created
https://github.com/llvm/llvm-project/pull/99352
This addresses the spurious inclusion of (now unsupported) target features
'-3dnow' and '-3dnowa', when disabling mmx.
It should've been part of PR #96246, but was missed.
>From 70160e033ac94de92fc2cd628954809
https://github.com/jyknight created
https://github.com/llvm/llvm-project/pull/99340
The second argument passed to these builtins is used to validate whether the
object's alignment is sufficient for atomic operations of the given size.
Currently, the builtins can be folded at compile time only
jyknight wrote:
Thanks for the report! Looks like I missed some 3dnow mentions in
llvm/lib/TargetParser/X86TargetParser.cpp, so `-mno-mmx` is still emitting this
feature.
I don't believe it should have any impact other than the warning spam, but I
will fix it.
https://github.com/llvm/llvm-pr
https://github.com/jyknight closed
https://github.com/llvm/llvm-project/pull/96246
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jyknight approved this pull request.
Sounds good enough to me, thank you!
https://github.com/llvm/llvm-project/pull/98736
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-com
@@ -481,7 +481,7 @@ defm WriteAESKeyGen : X86SchedWritePair;
// Key Generation.
// Carry-less multiplication instructions.
defm WriteCLMul : X86SchedWritePair;
-// EMMS/FEMMS
jyknight wrote:
Thanks, done. That was a leftover from a previous iteration where I
@@ -936,6 +936,24 @@ X86 Support
^^^
- Remove knl/knm specific ISA supports: AVX512PF, AVX512ER, PREFETCHWT1
+- Support has been removed for the AMD "3DNow!" instruction-set.
+ Neither modern AMD CPUs, nor any Intel CPUs implement these
+ instructions, and they were
@@ -7,7 +7,7 @@
define <2 x i32> @test_pswapdsi(<2 x i32> %a) nounwind readnone {
jyknight wrote:
Done.
https://github.com/llvm/llvm-project/pull/96246
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https:/
jyknight wrote:
The part I'm confused about is that this commit doesn't appear to simply be
adding "or `alignas`" to some code that said "if `_Alignas`". Yes, the newly
added `isAlignas()` checks do cover both attributes, but `_Alignas` was still
working even after b9cf7f1.
That is, in clang
@@ -57594,6 +57599,86 @@ static SDValue combinePDEP(SDNode *N, SelectionDAG
&DAG,
return SDValue();
}
+// Fixup the MMX intrinsics' types: in IR they are expressed with <1 x i64>,
jyknight wrote:
We perhaps _could_ use i64, but i64 is also not a legal type
@@ -1,9 +0,0 @@
-; RUN: llvm-as < %s | llvm-dis | FileCheck %s
-; RUN: verify-uselistorder %s
-; Basic smoke test for x86_mmx type.
-
-; CHECK: define x86_mmx @sh16
jyknight wrote:
The compatibility* tests already cover bitcode-upgrade, and now the IR text
"x86_
jyknight wrote:
> It wasn't clear to me initially what the way forward is, but it seems like
> it's not really feasible to conditionalize each use of `std::mutex` and
> instead WASI sysroots should provide a single-threaded implementation of
> synchronization primitives for embeddings which do
https://github.com/jyknight edited
https://github.com/llvm/llvm-project/pull/92677
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -508,6 +512,9 @@ static bool is_local_impl(struct STATVFS &Vfs) {
#elif defined(__EMSCRIPTEN__)
// Emscripten doesn't currently support remote filesystem mounts.
return true;
+#elif defined(__wasi__)
jyknight wrote:
It doesn't; C++ compilation only targ
@@ -252,13 +257,21 @@ std::error_code Process::FixupStandardFileDescriptors() {
if (NullFD == StandardFD)
FDC.keepOpen();
+#if defined(__wasi__)
+else // WASI does not have `dup2` by design. Return EBADF.
jyknight wrote:
Does wasi have /dev/null
@@ -71,6 +71,7 @@ ProcessInfo::ProcessInfo() : Pid(0), ReturnCode(0) {}
ErrorOr sys::findProgramByName(StringRef Name,
ArrayRef Paths) {
assert(!Name.empty() && "Must have a name!");
+#if !defined(__wasi__)
jyknight
@@ -19,13 +19,13 @@
namespace llvm {
namespace sys {
Watchdog::Watchdog(unsigned int seconds) {
-#ifdef HAVE_UNISTD_H
+#if HAVE_UNISTD_H && !defined(__wasi__)
jyknight wrote:
Looks like this could again be switched to a WASI/Watchdog.inc, with stub impls.
htt
@@ -30,7 +30,10 @@
#include
#include
#include
+
+#if !defined(__wasi__)
#include
jyknight wrote:
Is this header even needed on other platforms? I don't see anything clearly
'wait' related in this header.
https://github.com/llvm/llvm-project/pull/92677
_
@@ -13,8 +13,17 @@
#include "llvm/Support/Signals.h"
#include "llvm/Support/thread.h"
#include
+#if !defined(__wasi__)
+#include
+#endif
+#if LLVM_ENABLE_THREADS
jyknight wrote:
This is unfortunate; there's no reason (in theory) that mutex shouldn't work
fi
https://github.com/jyknight commented:
Overall, I think this would be improved by splitting off a bunch of the
lib/Support/Unix/*.inc files into separate lib/Support/WASI/*.inc files. Some
of these files do seem to make sense to share, e.g. Path.inc, but seems to me
like most of the rest are a
@@ -508,6 +512,9 @@ static bool is_local_impl(struct STATVFS &Vfs) {
#elif defined(__EMSCRIPTEN__)
// Emscripten doesn't currently support remote filesystem mounts.
return true;
+#elif defined(__wasi__)
jyknight wrote:
`__EMSCRIPTEN__ || __wasi__` is effec
@@ -41,6 +41,8 @@
using namespace llvm;
+#if defined(_WIN32) || !defined(__wasi__)
jyknight wrote:
This conditional is weird; there's no case where `__wasi__` is defined at the
same time as `_WIN32`, so you just mean `#if !defined(__wasi__)`.
Also you've r
@@ -94,7 +94,7 @@ static std::error_code getHostID(SmallVectorImpl
&HostID) {
StringRef UUIDRef(UUIDStr);
HostID.append(UUIDRef.begin(), UUIDRef.end());
-#elif LLVM_ON_UNIX
+#elif !defined(__wasi__)
jyknight wrote:
You're changing behavior for `!LLVM_ON_
https://github.com/jyknight edited
https://github.com/llvm/llvm-project/pull/92677
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -45,8 +45,11 @@ void lld::unlinkAsync(StringRef path) {
if (!sys::fs::exists(path) || !sys::fs::is_regular_file(path))
return;
+// If threads are disabled, remove the file synchronously.
jyknight wrote:
There's already a check below,
```
if (parall
@@ -273,9 +273,19 @@ static bool printMarkupStackTrace(StringRef Argv0, void
**StackTrace, int Depth,
}
// Include the platform-specific parts of this class.
-#ifdef LLVM_ON_UNIX
+#if defined(__wasi__)
+// WASI does not have signals.
jyknight wrote:
Move the
@@ -44,8 +44,8 @@ Type *Type::getPrimitiveType(LLVMContext &C, TypeID IDNumber)
{
case FP128TyID : return getFP128Ty(C);
case PPC_FP128TyID : return getPPC_FP128Ty(C);
case LabelTyID : return getLabelTy(C);
- case MetadataTyID : return getMetadataTy(C);
- case
@@ -57594,6 +57599,86 @@ static SDValue combinePDEP(SDNode *N, SelectionDAG
&DAG,
return SDValue();
}
+// Fixup the MMX intrinsics' types: in IR they are expressed with <1 x i64>,
jyknight wrote:
No -- the problem is that DAGtoDAG is after LegalizeTypes, a
@@ -1,9 +0,0 @@
-; RUN: llvm-as < %s | llvm-dis | FileCheck %s
-; RUN: verify-uselistorder %s
-; Basic smoke test for x86_mmx type.
-
-; CHECK: define x86_mmx @sh16
jyknight wrote:
`x86_mmx` would be translated to `<1 x i64>`, like in the other tests. That is:
``
@@ -38,11 +38,11 @@ int test4(volatile int *addr) {
return (int)oldval;
}
-// This should have both inputs be of type x86_mmx.
+// This should have both inputs be of type <1 x i64>.
jyknight wrote:
No conflict, although the comment doesn't really have any v
jyknight wrote:
I'm not sure I understand what happened here, since `_Alignas` did work
properly before this change, right? How/why are `_Alignas` and `alignas` acting
differently from eachother in C23 mode?
https://github.com/llvm/llvm-project/pull/98642
__
@@ -442,6 +442,9 @@ def warn_drv_deprecated_arg : Warning<
def warn_drv_deprecated_arg_no_relaxed_template_template_args : Warning<
"argument '-fno-relaxed-template-template-args' is deprecated">,
InGroup;
+def warn_drv_deprecated_arg_ofast : Warning<
+ "argument '-Ofast'
https://github.com/jyknight edited
https://github.com/llvm/llvm-project/pull/98736
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jyknight commented:
Thanks for sending this. I had planned to, but hadn't gotten around to it yet.
https://github.com/llvm/llvm-project/pull/98736
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin
@@ -470,6 +470,9 @@ New Compiler Flags
Deprecated Compiler Flags
-
+- ``-Ofast`` is deprecated in favor of ``-O3``, possibly combined with
``-ffast-math``.
jyknight wrote:
Suggestion:
```
- The ``-Ofast`` command-line option has been
@@ -10,6 +10,7 @@
// RUN: %clang -Ofast -fno-strict-aliasing -### %s 2>&1 | FileCheck
-check-prefix=CHECK-OFAST-NO-STRICT-ALIASING %s
// RUN: %clang -Ofast -fno-vectorize -### %s 2>&1 | FileCheck
-check-prefix=CHECK-OFAST-NO-VECTORIZE %s
+// CHECK-OFAST: warning: argument '-
https://github.com/jyknight edited
https://github.com/llvm/llvm-project/pull/96540
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jyknight wrote:
I've written down an overall plan into issue #98272. I'm not sure if everything
can be finished by the LLVM 19 branch date, but I don't think there's any
reason to wait on this CL. I'd like to just go ahead with it.
https://github.com/llvm/llvm-project/pull/96246
__
https://github.com/jyknight edited
https://github.com/llvm/llvm-project/pull/96246
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jyknight edited
https://github.com/llvm/llvm-project/pull/96246
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jyknight updated
https://github.com/llvm/llvm-project/pull/98273
>From 546963316017935bfbbc05d7095d645344fbd5f5 Mon Sep 17 00:00:00 2001
From: James Y Knight
Date: Wed, 10 Jul 2024 00:49:25 -0400
Subject: [PATCH 1/2] Clang: don't unnecessarily convert inline-asm operands to
https://github.com/jyknight created
https://github.com/llvm/llvm-project/pull/98273
The SelectionDAG asm-lowering code can already handle conversion of other
vector types to MMX if needed.
>From 546963316017935bfbbc05d7095d645344fbd5f5 Mon Sep 17 00:00:00 2001
From: James Y Knight
Date: Wed,
jyknight wrote:
> Really, the question is whether we plan to completely drop support for the
> x86_mmx type (including inline asm operands/results)
Yes, I do think it would be good to eliminate the type.
For inline-asm, we could switch to using a standard IR vector type for "y"
constraint ope
1 - 100 of 417 matches
Mail list logo
