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
jyknight wrote:
> I guess the clang calling convention code never uses MMX types for
> passing/returning values?
Correct, Clang never uses MMX types in its calling convention. This is actually
_wrong_ for the 32-bit x86 psABI. You're supposed to pass the first 3 MMX args
in mm0-2, and return
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
@@ -21,10 +21,29 @@ typedef int __v2si __attribute__((__vector_size__(8)));
typedef short __v4hi __attribute__((__vector_size__(8)));
typedef char __v8qi __attribute__((__vector_size__(8)));
jyknight wrote:
IIUC, these files intentionally don't have any depen
@@ -177,7 +175,10 @@ _mm_abs_epi32(__m128i __a)
/// \returns A 64-bit integer vector containing the concatenated right-shifted
///value.
#define _mm_alignr_pi8(a, b, n) \
- ((__m64)__builtin_ia32_palignr((__v8qi)(__m64)(a), (__v8qi)(__m64)(b), (n)))
+ ((__m64)__builtin_sh
@@ -614,12 +623,15 @@ _mm_shuffle_epi8(__m128i __a, __m128i __b)
///1: Clear the corresponding byte in the destination. \n
///0: Copy the selected source byte to the corresponding byte in the
///destination. \n
-///Bits [3:0] select the source byte to be copied.
@@ -242,10 +243,11 @@ _mm_hadd_epi32(__m128i __a, __m128i __b)
///destination.
/// \returns A 64-bit vector of [4 x i16] containing the horizontal sums of
both
///operands.
-static __inline__ __m64 __DEFAULT_FN_ATTRS_MMX
+static __inline__ __m64 __DEFAULT_FN_ATTRS
_mm
@@ -32,12 +32,13 @@ typedef unsigned int __v4su
__attribute__((__vector_size__(16)));
#endif
/* Define the default attributes for the functions in this file. */
-#define __DEFAULT_FN_ATTRS
\
- __attribute__((__always_inlin
@@ -0,0 +1,29 @@
+USE_XMM=
+#USE_XMM=--use-xmm
jyknight wrote:
It works if you first delete/ifdef-out test_stores and test_maskmove. I didn't
make those generic.
(The "USE_XMM" version is to validate that the unused bits of the input xmm
registers being set to
@@ -17,13 +17,11 @@
#include
/* Define the default attributes for the functions in this file. */
-#define __DEFAULT_FN_ATTRS
\
- __attribute__((__always_inline__, __nodebug__,
\
-
@@ -1558,10 +1559,10 @@ _mm_cvttss_si64(__m128 __a)
/// \param __a
///A 128-bit vector of [4 x float].
/// \returns A 64-bit integer vector containing the converted values.
-static __inline__ __m64 __DEFAULT_FN_ATTRS_MMX
+static __inline__ __m64 __DEFAULT_FN_ATTRS_SSE2
_mm
@@ -21,10 +21,29 @@ typedef int __v2si __attribute__((__vector_size__(8)));
typedef short __v4hi __attribute__((__vector_size__(8)));
typedef char __v8qi __attribute__((__vector_size__(8)));
+/* Unsigned types */
+typedef unsigned long long __v1du __attribute__ ((__vector_size
@@ -21,10 +21,29 @@ typedef int __v2si __attribute__((__vector_size__(8)));
typedef short __v4hi __attribute__((__vector_size__(8)));
typedef char __v8qi __attribute__((__vector_size__(8)));
+/* Unsigned types */
+typedef unsigned long long __v1du __attribute__ ((__vector_size
@@ -0,0 +1,29 @@
+USE_XMM=
jyknight wrote:
These are the tests I used to validate that the re-implementation works
properly: I found it extremely important to have validation that my
implementation works properly, because i certainly messed up a few times.
I d
@@ -124,10 +143,11 @@ _mm_cvtm64_si64(__m64 __m)
///written to the upper 32 bits of the result.
/// \returns A 64-bit integer vector of [8 x i8] containing the converted
///values.
-static __inline__ __m64 __DEFAULT_FN_ATTRS
+static __inline__ __m64 __DEFAULT_FN_ATTRS_S
@@ -2502,10 +2509,25 @@ _mm_mulhi_pu16(__m64 __a, __m64 __b)
///A pointer to a 64-bit memory location that will receive the
conditionally
///copied integer values. The address of the memory location does not have
///to be aligned.
-static __inline__ void __DEFAULT_
@@ -2108,9 +2106,8 @@ static __inline__ __m128i __DEFAULT_FN_ATTRS
_mm_add_epi32(__m128i __a,
/// \param __b
///A 64-bit integer.
/// \returns A 64-bit integer containing the sum of both parameters.
-static __inline__ __m64 __DEFAULT_FN_ATTRS_MMX _mm_add_si64(__m64 __a,
-
1 - 100 of 401 matches
Mail list logo
