Adjust modulemap to mark mm3dnow as textual header.

[jyknight]

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. It's also very rarely included by anything.

Addresses #96246 (comment)

[llvmbot]

@llvm/pr-subscribers-clang

@llvm/pr-subscribers-backend-x86

Author: James Y Knight (jyknight)

Changes

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. It's also very rarely included by anything.

Addresses #96246 (comment)

---

Full diff: https://github.com/llvm/llvm-project/pull/107155.diff

1 Files Affected:

• (modified) clang/lib/Headers/module.modulemap (+2-4)

diff --git a/clang/lib/Headers/module.modulemap b/clang/lib/Headers/module.modulemap
index 9ffc249c8d1a23..dcaf09e8f2c558 100644
--- a/clang/lib/Headers/module.modulemap
+++ b/clang/lib/Headers/module.modulemap
@@ -66,6 +66,8 @@ module _Builtin_intrinsics [system] [extern_c] {
     textual header "__wmmintrin_aes.h"
     textual header "__wmmintrin_pclmul.h"
 
+    textual header "mm3dnow.h"
+
     explicit module mm_malloc {
       requires !freestanding
       header "mm_malloc.h"
@@ -122,10 +124,6 @@ module _Builtin_intrinsics [system] [extern_c] {
       header "popcntintrin.h"
     }
 
-    explicit module mm3dnow {
-      header "mm3dnow.h"
-    }
-
     explicit module aes_pclmul {
       header "wmmintrin.h"
       export aes

[ian-twilightcoder]

Does anything rely on the header guard? It would be good if we could remove it since textual headers are not generally expected to declare anything, even macros.

[jyknight]

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. having to merge 100s of duplicate function decls -- that can have noticeable performance impact.)

[ian-twilightcoder]

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. having to merge 100s of duplicate function decls -- that can have noticeable performance impact.)

Just good to not unintentionally add decls to pcms, and I think the intent of mm3dnow.h is not to add that define to the pcm, it's more like an implementation detail for include-once. But we don't really need to require include-once anymore with this one, and that'll save us writing unnecessary junk to the pcm of anything that includes this.

That said, there shouldn't be any significant impact either way.

[jyknight]

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.

[ian-twilightcoder]

That's true. Probably nobody's using this header anymore anyway so either way should be fine I think.

[jyknight]

I'll commit as soon as anyone gives it an approval. :)