@@ -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 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'
@@ -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
@@ -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'
@@ -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/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_alw
@@ -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 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
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_alw
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/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'
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 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
@@ -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 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_alw
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
@@ -89,6 +89,19 @@ sections with improvements to Clang's support for those
languages.
C++ Language Changes
+C++17 Feature Support
+^
+- Clang now exposes ``__GCC_DESTRUCTIVE_SIZE`` and ``__GCC_CONSTRUCTIVE_SIZE``
+ predefined macros t
https://github.com/jyknight commented:
I think having the on-by-default diagnostic before we release this
functionality is critically important -- but the primarily-useful part of that
is going to be for the public libc++ APIs which expose these values (and, that
already landed in mainline).
https://github.com/jyknight edited
https://github.com/llvm/llvm-project/pull/89446
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1792,6 +1792,11 @@ class TargetInfo : public TransferrableTargetInfo,
/// Whether to support HIP image/texture API's.
virtual bool hasHIPImageSupport() const { return true; }
+ /// The minimum offset between two objects to avoid false sharing.
jyknigh
@@ -1792,6 +1792,11 @@ class TargetInfo : public TransferrableTargetInfo,
/// Whether to support HIP image/texture API's.
virtual bool hasHIPImageSupport() const { return true; }
+ /// The minimum offset between two objects to avoid false sharing.
+ virtual unsigned hard
@@ -89,6 +89,19 @@ sections with improvements to Clang's support for those
languages.
C++ Language Changes
+C++17 Feature Support
+^
+- Clang now exposes ``__GCC_DESTRUCTIVE_SIZE`` and ``__GCC_CONSTRUCTIVE_SIZE``
+ predefined macros t
https://github.com/jyknight approved this pull request.
One final nit before you submit, though: please update the PR description and
the release notes to also mention that x86 no longer modifies
`-fdenormal-fp-math` based on `-ffast-math`.
https://github.com/llvm/llvm-project/pull/80475
_
@@ -842,25 +842,6 @@ void Linux::addProfileRTLibs(const llvm::opt::ArgList
&Args,
ToolChain::addProfileRTLibs(Args, CmdArgs);
}
-llvm::DenormalMode
-Linux::getDefaultDenormalModeForType(const llvm::opt::ArgList &DriverArgs,
- const JobAct
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:
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:
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:
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 ope
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
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/96540
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -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 '-
@@ -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
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
@@ -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'
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
__
@@ -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
@@ -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:
``
@@ -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
@@ -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
@@ -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
@@ -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
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
@@ -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_
@@ -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
@@ -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
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
@@ -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
@@ -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
_
@@ -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
@@ -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
@@ -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
@@ -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
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
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
@@ -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_
@@ -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
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
@@ -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:/
@@ -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
@@ -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
jyknight wrote:
I note that this commit (probably unintentionally) fixed an issue with the
`-Wnonnull` warning for return values in Objective-C++ code.
Previously, `id _Nonnull foo() { return nullptr; }` does not warn under `clang
-fobjc-arc -target x86_64-apple-macos11 -x objective-c++ -fsynt
jyknight wrote:
Here's a test case that clang diagnoses with `-Wundefined-inline` after this
patch, which I'm not sure whether is correct or not. It might violate
https://eel.is/c++draft/temp.inst#11 to attempt to instantiate the unused
`S::operator int`?
I'm having a hard time telling whethe
jyknight wrote:
We _don't_ diagnose it at the end of the definition of M -- it looks like we
explicitly intentionally stopped doing so in the commit I referenced. That's
why I'm a little confused here.
With this patch, we start to diagnose only in the final line of code, `void
test(M m = {})
jyknight wrote:
https://discourse.llvm.org/t/rfc-building-llvm-for-webassembly/79073 and PR
#92677 also just arrived at the scene with a different take on implementing the
same thing. Looks like there's significant interest in this area!
https://github.com/llvm/llvm-project/pull/91051
jyknight wrote:
Please update the constraint code list
https://llvm.org/docs/LangRef.html#supported-constraint-code-list with any new
codes.
https://github.com/llvm/llvm-project/pull/92338
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https
jyknight wrote:
Heads up: this commit has triggered some weird errors for a compile, but only
when clang header modules are enabled. A std::vector, that's built through a
large amount of template gunk that definitely involves template template
parameter matching, ends up failing vector's "Allo
Author: James Y Knight
Date: 2022-01-12T21:18:52Z
New Revision: d1021978b8e7e35dcc30201ca1731d64b5a602a8
URL:
https://github.com/llvm/llvm-project/commit/d1021978b8e7e35dcc30201ca1731d64b5a602a8
DIFF:
https://github.com/llvm/llvm-project/commit/d1021978b8e7e35dcc30201ca1731d64b5a602a8.diff
Author: James Y Knight
Date: 2020-12-28T18:11:17-05:00
New Revision: 4ddf140c00408ecee9d20f4470e69e0f696d8f8a
URL:
https://github.com/llvm/llvm-project/commit/4ddf140c00408ecee9d20f4470e69e0f696d8f8a
DIFF:
https://github.com/llvm/llvm-project/commit
If phabricator/phorge do turn out to be non-viable in the future, I think
we may want to reopen the option of moving to Gerrit for the primary
code-review platform.
I'll note that the Golang folks are using Gerrit as their review platform,
and they have a GitHub bot setup to translate GH pull-requ
On Tue, Aug 24, 2021 at 7:33 AM Renato Golin wrote:
> The main problem with that (Go) solution is that the Gerrit install
> doesn't single-sign-on with Github accounts, it asked me for my Google
> account. We shouldn't ask people to create more accounts if we want
> integration with Github. I gue
@@ -1825,32 +1818,32 @@ def : ProcModel;
-def : Proc<"k6-2", [FeatureX87, FeatureCX8, Feature3DNow],
+def : Proc<"k6-2", [FeatureX87, FeatureCX8, FeatureMMX],
jyknight wrote:
Done.
https://github.com/llvm/llvm-project/pull/96246
_
jyknight wrote:
> I'd prefer we rip off ALL the 3dnow/mmx bandaid in one big series of patches
> - and not split across the 19.X/20.X releases.
The 3dnow part is a lot easier -- because it's not trying to be compatible,
just dropping support entirely. And I don't think anyone will care, since
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
@@ -150,8 +150,8 @@ TARGET_BUILTIN(__builtin_ia32_pmovmskb, "iV8c", "ncV:64:",
"mmx,sse")
TARGET_BUILTIN(__builtin_ia32_pmulhuw, "V4sV4sV4s", "ncV:64:", "mmx,sse")
TARGET_BUILTIN(__builtin_ia32_psadbw, "V4sV8cV8c", "ncV:64:", "mmx,sse")
TARGET_BUILTIN(__builtin_ia32_pshufw, "V
https://github.com/jyknight commented:
Thanks for the detailed review comments!
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
@@ -1035,10 +1077,11 @@ _mm_srli_pi32(__m64 __m, int __count)
/// \param __count
///A 64-bit integer vector interpreted as a single 64-bit integer.
/// \returns A 64-bit integer vector containing the right-shifted value.
-static __inline__ __m64 __DEFAULT_FN_ATTRS
+static _
@@ -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,
-
@@ -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_
@@ -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
@@ -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
@@ -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
@@ -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
@@ -17,13 +17,11 @@
#include
/* Define the default attributes for the functions in this file. */
-#define __DEFAULT_FN_ATTRS
\
- __attribute__((__always_inline__, __nodebug__,
\
-
@@ -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
@@ -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
@@ -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
@@ -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.
@@ -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
@@ -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
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 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
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'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
301 - 400 of 875 matches
Mail list logo
