[clang] Add clang atomic control options and attribute (PR #114841)

2025-02-26 Thread Yaxun Liu via cfe-commits


@@ -5442,6 +5442,155 @@ third argument, can only occur at file scope.
 a = b[i] * c[i] + e;
   }
 
+Extensions for controlling atomic code generation
+=
+
+The ``[[clang::atomic]]`` statement attribute enables users to control how
+atomic operations are lowered in LLVM IR by conveying additional metadata to
+the backend. The primary goal is to allow users to specify certain options,
+like whether atomic operations may be performed on specific types of memory or
+whether to ignore denormal mode correctness in floating-point operations,
+without affecting the correctness of code that does not rely on these 
behaviors.
+
+In LLVM, lowering of atomic operations (e.g., ``atomicrmw``) can differ based
+on the target's capabilities. Some backends support native atomic instructions
+only for certain operation types or alignments, or only in specific memory
+regions. Likewise, floating-point atomic instructions may or may not respect
+IEEE denormal requirements. When the user is unconcerned about denormal-mode
+compliance (for performance reasons) or knows that certain atomic operations
+will not be performed on a particular type of memory, extra hints are needed to
+tell the backend how to proceed.
+
+A classic example is an architecture where floating-point atomic add does not
+fully conform to IEEE denormal-mode handling. If the user does not mind 
ignoring
+that aspect, they would prefer to still emit a faster hardware atomic 
instruction,
+rather than a fallback or CAS loop. Conversely, on certain GPUs (e.g., AMDGPU),
+memory accessed via PCIe may only support a subset of atomic operations. To 
ensure
+correct and efficient lowering, the compiler must know whether the user wants 
to
+allow atomic operations on that type of memory.
+
+The allowed atomic attribute values are now ``remote_memory``, 
``fine_grained_memory``,
+and ``ignore_denormal_mode``, each optionally prefixed with ``no_``. The 
meanings
+are as follows:
+
+- ``remote_memory`` means atomic operations may be performed on remote memory.
+  Prefixing with ``no_`` (i.e. ``no_remote_memory``) indicates that atomic
+  operations should not be performed on remote memory.
+- ``fine_grained_memory`` means atomic operations may be performed on 
fine-grained
+  memory. Prefixing with ``no_`` (i.e. ``no_fine_grained_memory``) indicates 
that
+  atomic operations should not be performed on fine-grained memory.
+- ``ignore_denormal_mode`` means that atomic operations are allowed to ignore
+  correctness for denormal mode in floating-point operations, potentially 
improving
+  performance on architectures that handle denormals inefficiently. The 
negated form,
+  if specified as ``no_ignore_denormal_mode``, would enforce strict denormal 
mode
+  correctness.
+
+Within the same atomic attribute, duplicate and conflict values are accepted 
and the
+last value of conflicting values wins. Multiple atomic attributes are allowed
+for the same compound statement and the last atomic attribute wins.
+
+Without any atomic metadata, LLVM IR defaults to conservative settings for
+correctness: atomic operations are assumed to use remote memory, fine-grained
+memory, and enforce denormal mode correctness (i.e. the equivalent of
+``remote_memory``, ``fine_grained_memory``, and ``no_ignore_denormal_mode``).
+
+The attribute may be applied only to a compound statement and looks like:
+
+.. code-block:: c++
+
+   [[clang::atomic(remote_memory, fine_grained_memory, ignore_denormal_mode)]]
+   {
+   // Atomic instructions in this block carry extra metadata reflecting
+   // these user-specified options.
+   }
+
+You can provide one or more of these options, each optionally prefixed with
+``no_`` to negate that option. Any unspecified option is inherited from the
+global defaults, which can be set by a compiler flag or the target's built-in 
defaults.
+
+A new compiler option now globally sets the defaults for these atomic-lowering
+options. The command-line format has changed to:
+
+.. code-block:: console
+
+   $ clang -fatomic-remote-memory -fno-atomic-fine-grained-memory 
-fatomic-ignore-denormal-mode file.cpp
+
+Each option has a corresponding flag:
+``-fatomic-remote-memory`` / ``-fno-atomic-remote-memory``,
+``-fatomic-fine-grained-memory`` / ``-fno-atomic-fine-grained-memory``,
+and ``-fatomic-ignore-denormal-mode`` / ``-fno-atomic-ignore-denormal-mode``.
+
+Code using the ``[[clang::atomic]]`` attribute can then selectively override
+the command-line defaults on a per-block basis. For instance:
+
+.. code-block:: c++
+
+   // Suppose the global defaults assume:
+   //   remote_memory, fine_grained_memory, and no_ignore_denormal_mode
+   // (for conservative correctness)
+
+   void example() {
+   // Locally override the settings: disable remote_memory and enable
+   // fine_grained_memory.
+   [[clang::atomic(no_remote_memory, fine_grained_memory)]]
+   {
+   // In this 

[clang] Add clang atomic control options and attribute (PR #114841)

2025-02-26 Thread Yaxun Liu via cfe-commits


@@ -132,6 +132,12 @@ Attribute Changes in Clang
   This forces the global to be considered small or large in regards to the
   x86-64 code model, regardless of the code model specified for the 
compilation.
 
+- Introduced a new statement attribute ``[[clang::atomic]]`` that enables
+  fine-grained control over atomic code generation on a per-statement basis.
+  Supported options include ``[no_]remote_memory``,
+  ``[no_]fine_grained_memory``, and ``[no_]ignore_denormal_mode``, particularly
+  relevant for AMDGPU targets, where they map to corresponding IR metadata.

yxsamliu wrote:

will do

https://github.com/llvm/llvm-project/pull/114841
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [llvm] APFloat: Fix maxnum and minnum with sNaN (PR #112854)

2025-02-26 Thread YunQiang Su via cfe-commits

wzssyqa wrote:

@arsenm ping

https://github.com/llvm/llvm-project/pull/112854
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [llvm] [RISCV] Add Qualcomm uC Xqcisim (Simulation Hint) extension (PR #128833)

2025-02-26 Thread Sudharsan Veeravalli via cfe-commits

https://github.com/svs-quic updated 
https://github.com/llvm/llvm-project/pull/128833

>From 10f62d3697b3e2d773d828fc3e7a6767ff71a072 Mon Sep 17 00:00:00 2001
From: Sudharsan Veeravalli 
Date: Wed, 26 Feb 2025 12:13:32 +0530
Subject: [PATCH 1/2] [RISCV] Add Qualcomm uC Xqcisim (Simulation Hint]
 extension

This extension adds 10 instructions that provide hints to the interface
simulation environment.

The current spec can be found at:
https://github.com/quic/riscv-unified-db/releases/

This patch adds assembler only support.
---
 .../Driver/print-supported-extensions-riscv.c |   1 +
 llvm/docs/RISCVUsage.rst  |   3 +
 llvm/docs/ReleaseNotes.md |   2 +
 .../RISCV/Disassembler/RISCVDisassembler.cpp  |   2 +-
 llvm/lib/Target/RISCV/RISCVFeatures.td|   8 ++
 llvm/lib/Target/RISCV/RISCVInstrInfoXqci.td   |  50 +++
 llvm/lib/TargetParser/RISCVISAInfo.cpp|   2 +-
 llvm/test/CodeGen/RISCV/attributes.ll |   2 +
 llvm/test/MC/RISCV/xqcisim-invalid.s  | 125 ++
 llvm/test/MC/RISCV/xqcisim-valid.s|  52 
 .../TargetParser/RISCVISAInfoTest.cpp |   3 +-
 11 files changed, 247 insertions(+), 3 deletions(-)
 create mode 100644 llvm/test/MC/RISCV/xqcisim-invalid.s
 create mode 100644 llvm/test/MC/RISCV/xqcisim-valid.s

diff --git a/clang/test/Driver/print-supported-extensions-riscv.c 
b/clang/test/Driver/print-supported-extensions-riscv.c
index fcd820464e2d1..5a5d2db7df072 100644
--- a/clang/test/Driver/print-supported-extensions-riscv.c
+++ b/clang/test/Driver/print-supported-extensions-riscv.c
@@ -203,6 +203,7 @@
 // CHECK-NEXT: xqcilia  0.2   'Xqcilia' (Qualcomm uC Large 
Immediate Arithmetic Extension)
 // CHECK-NEXT: xqcilo   0.2   'Xqcilo' (Qualcomm uC Large 
Offset Load Store Extension)
 // CHECK-NEXT: xqcilsm  0.2   'Xqcilsm' (Qualcomm uC Load 
Store Multiple Extension)
+// CHECK-NEXT: xqcisim  0.2   'Xqcisim' (Qualcomm uC 
Simulation Hint Extension)
 // CHECK-NEXT: xqcisls  0.2   'Xqcisls' (Qualcomm uC 
Scaled Load Store Extension)
 // CHECK-NEXT: xrivosvizip  0.1   'XRivosVizip' (Rivos Vector 
Register Zips)
 // CHECK-EMPTY:
diff --git a/llvm/docs/RISCVUsage.rst b/llvm/docs/RISCVUsage.rst
index 051eaf6999edb..bbb98cd209b98 100644
--- a/llvm/docs/RISCVUsage.rst
+++ b/llvm/docs/RISCVUsage.rst
@@ -459,6 +459,9 @@ The current vendor extensions supported are:
 ``experimental-Xqcilsm``
   LLVM implements `version 0.2 of the Qualcomm uC Load Store Multiple 
extension specification 
`__ by Qualcomm.  All 
instructions are prefixed with `qc.` as described in the specification. These 
instructions are only available for riscv32.
 
+``experimental-Xqcisim``
+  LLVM implements `version 0.2 of the Qualcomm uC Simulation Hint extension 
specification `__ by 
Qualcomm.  All instructions are prefixed with `qc.` as described in the 
specification. These instructions are only available for riscv32.
+
 ``experimental-Xqcisls``
   LLVM implements `version 0.2 of the Qualcomm uC Scaled Load Store extension 
specification `__ by 
Qualcomm.  All instructions are prefixed with `qc.` as described in the 
specification. These instructions are only available for riscv32.
 
diff --git a/llvm/docs/ReleaseNotes.md b/llvm/docs/ReleaseNotes.md
index 2a617901a1146..2dc49bbd945a5 100644
--- a/llvm/docs/ReleaseNotes.md
+++ b/llvm/docs/ReleaseNotes.md
@@ -109,6 +109,8 @@ Changes to the RISC-V Backend
 
 * Adds experimental assembler support for the Qualcomm uC 'Xqcilia` (Large 
Immediate Arithmetic)
   extension.
+* Adds experimental assembler support for the Qualcomm uC 'Xqcisim` 
(Simulation Hint)
+  extension.
 
 Changes to the WebAssembly Backend
 --
diff --git a/llvm/lib/Target/RISCV/Disassembler/RISCVDisassembler.cpp 
b/llvm/lib/Target/RISCV/Disassembler/RISCVDisassembler.cpp
index 1025b57369f4a..81ace9138fded 100644
--- a/llvm/lib/Target/RISCV/Disassembler/RISCVDisassembler.cpp
+++ b/llvm/lib/Target/RISCV/Disassembler/RISCVDisassembler.cpp
@@ -628,7 +628,7 @@ static constexpr FeatureBitset XqciFeatureGroup = {
 RISCV::FeatureVendorXqcics,  RISCV::FeatureVendorXqcicsr,
 RISCV::FeatureVendorXqciint, RISCV::FeatureVendorXqcilia,
 RISCV::FeatureVendorXqcilo,  RISCV::FeatureVendorXqcilsm,
-RISCV::FeatureVendorXqcisls,
+RISCV::FeatureVendorXqcisim, RISCV::FeatureVendorXqcisls,
 };
 
 DecodeStatus RISCVDisassembler::getInstruction32(MCInst &MI, uint64_t &Size,
diff --git a/llvm/lib/Target/RISCV/RISCVFeatures.td 
b/llvm/lib/Target/RISCV/RISCVFeatures.td
index 1a93371a4d92f..e60c0e611179c 100644
--- a/llvm/lib/Target/RISCV/RISCVFeatures.td
+++ b/llvm/lib/Target/RISCV/RISCVFeatures.td
@@ -1374,6 +13

[clang] Add clang atomic control options and attribute (PR #114841)

2025-02-26 Thread Yaxun Liu via cfe-commits


@@ -5442,6 +5442,155 @@ third argument, can only occur at file scope.
 a = b[i] * c[i] + e;
   }
 
+Extensions for controlling atomic code generation
+=
+
+The ``[[clang::atomic]]`` statement attribute enables users to control how
+atomic operations are lowered in LLVM IR by conveying additional metadata to
+the backend. The primary goal is to allow users to specify certain options,
+like whether atomic operations may be performed on specific types of memory or
+whether to ignore denormal mode correctness in floating-point operations,
+without affecting the correctness of code that does not rely on these 
behaviors.
+
+In LLVM, lowering of atomic operations (e.g., ``atomicrmw``) can differ based
+on the target's capabilities. Some backends support native atomic instructions
+only for certain operation types or alignments, or only in specific memory
+regions. Likewise, floating-point atomic instructions may or may not respect
+IEEE denormal requirements. When the user is unconcerned about denormal-mode
+compliance (for performance reasons) or knows that certain atomic operations
+will not be performed on a particular type of memory, extra hints are needed to
+tell the backend how to proceed.
+
+A classic example is an architecture where floating-point atomic add does not
+fully conform to IEEE denormal-mode handling. If the user does not mind 
ignoring
+that aspect, they would prefer to still emit a faster hardware atomic 
instruction,
+rather than a fallback or CAS loop. Conversely, on certain GPUs (e.g., AMDGPU),
+memory accessed via PCIe may only support a subset of atomic operations. To 
ensure
+correct and efficient lowering, the compiler must know whether the user wants 
to
+allow atomic operations on that type of memory.
+
+The allowed atomic attribute values are now ``remote_memory``, 
``fine_grained_memory``,
+and ``ignore_denormal_mode``, each optionally prefixed with ``no_``. The 
meanings
+are as follows:
+
+- ``remote_memory`` means atomic operations may be performed on remote memory.
+  Prefixing with ``no_`` (i.e. ``no_remote_memory``) indicates that atomic
+  operations should not be performed on remote memory.
+- ``fine_grained_memory`` means atomic operations may be performed on 
fine-grained
+  memory. Prefixing with ``no_`` (i.e. ``no_fine_grained_memory``) indicates 
that
+  atomic operations should not be performed on fine-grained memory.
+- ``ignore_denormal_mode`` means that atomic operations are allowed to ignore
+  correctness for denormal mode in floating-point operations, potentially 
improving
+  performance on architectures that handle denormals inefficiently. The 
negated form,
+  if specified as ``no_ignore_denormal_mode``, would enforce strict denormal 
mode
+  correctness.
+
+Within the same atomic attribute, duplicate and conflict values are accepted 
and the
+last value of conflicting values wins. Multiple atomic attributes are allowed
+for the same compound statement and the last atomic attribute wins.
+
+Without any atomic metadata, LLVM IR defaults to conservative settings for
+correctness: atomic operations are assumed to use remote memory, fine-grained
+memory, and enforce denormal mode correctness (i.e. the equivalent of
+``remote_memory``, ``fine_grained_memory``, and ``no_ignore_denormal_mode``).

yxsamliu wrote:

will do

https://github.com/llvm/llvm-project/pull/114841
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [llvm] APFloat: Fix maxnum and minnum with sNaN (PR #112854)

2025-02-26 Thread Matt Arsenault via cfe-commits

https://github.com/arsenm approved this pull request.


https://github.com/llvm/llvm-project/pull/112854
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] Hlsl or intrinsic (PR #128979)

2025-02-26 Thread via cfe-commits


@@ -2305,6 +2305,25 @@ bool SemaHLSL::CheckBuiltinFunctionCall(unsigned 
BuiltinID, CallExpr *TheCall) {
 TheCall->setType(ArgTyA);
 break;
   }
+  case Builtin::BI__builtin_hlsl_or: {
+if (SemaRef.checkArgCount(TheCall, 2))
+  return true;
+if (CheckVectorElementCallArgs(&SemaRef, TheCall))
+  return true;
+
+// Ensure input expr type is a scalar/vector and the same as the return 
type

metkarpoonam wrote:

Yes, good catch! The checks aren't affecting the return type. I'll update the 
comments to clarify this.

https://github.com/llvm/llvm-project/pull/128979
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [CIR] Function type return type improvements (PR #128787)

2025-02-26 Thread LLVM Continuous Integration via cfe-commits

llvm-ci wrote:

LLVM Buildbot has detected a new failure on builder 
`sanitizer-x86_64-linux-android` running on `sanitizer-buildbot-android` while 
building `clang` at step 2 "annotate".

Full details are available at: 
https://lab.llvm.org/buildbot/#/builders/186/builds/6880


Here is the relevant piece of the build log for the reference

```
Step 2 (annotate) failure: 'python 
../sanitizer_buildbot/sanitizers/zorg/buildbot/builders/sanitizers/buildbot_selector.py'
 (failure)
...
PASS: HWAddressSanitizer-aarch64 :: TestCases/Posix/ignore_free_hook.cpp (532 
of 1738)
PASS: HWAddressSanitizer-aarch64 :: TestCases/libc_thread_freeres.c (533 of 
1738)
PASS: HWAddressSanitizer-aarch64 :: TestCases/longjmp-out-of-range.c (534 of 
1738)
PASS: HWAddressSanitizer-aarch64 :: TestCases/lto.c (535 of 1738)
PASS: HWAddressSanitizer-aarch64 :: TestCases/longjmp-setjmp-interception.c 
(536 of 1738)
PASS: HWAddressSanitizer-aarch64 :: TestCases/deep-recursion.c (537 of 1738)
PASS: HWAddressSanitizer-aarch64 :: TestCases/malloc-test.c (538 of 1738)
PASS: HWAddressSanitizer-aarch64 :: TestCases/malloc-align.c (539 of 1738)
PASS: HWAddressSanitizer-aarch64 :: TestCases/longjmp.c (540 of 1738)
PASS: AddressSanitizer-aarch64-android :: TestCases/use-after-scope-types.cpp 
(541 of 1738)
FAIL: HWAddressSanitizer-aarch64 :: 
TestCases/hwasan_symbolize_stack_overflow.cpp (542 of 1738)
 TEST 'HWAddressSanitizer-aarch64 :: 
TestCases/hwasan_symbolize_stack_overflow.cpp' FAILED 
Exit Code: 1

Command Output (stderr):
--
RUN: at line 1: rm -rf 
/var/lib/buildbot/sanitizer-buildbot6/sanitizer-x86_64-linux-android/build/compiler_rt_build_android_aarch64/test/hwasan/AARCH64/TestCases/Output/hwasan_symbolize_stack_overflow.cpp.tmp;
 mkdir 
/var/lib/buildbot/sanitizer-buildbot6/sanitizer-x86_64-linux-android/build/compiler_rt_build_android_aarch64/test/hwasan/AARCH64/TestCases/Output/hwasan_symbolize_stack_overflow.cpp.tmp
+ rm -rf 
/var/lib/buildbot/sanitizer-buildbot6/sanitizer-x86_64-linux-android/build/compiler_rt_build_android_aarch64/test/hwasan/AARCH64/TestCases/Output/hwasan_symbolize_stack_overflow.cpp.tmp
+ mkdir 
/var/lib/buildbot/sanitizer-buildbot6/sanitizer-x86_64-linux-android/build/compiler_rt_build_android_aarch64/test/hwasan/AARCH64/TestCases/Output/hwasan_symbolize_stack_overflow.cpp.tmp
RUN: at line 2: 
/var/lib/buildbot/sanitizer-buildbot6/sanitizer-x86_64-linux-android/build/llvm-project/compiler-rt/test/sanitizer_common/android_commands/android_compile.py
  
/var/lib/buildbot/sanitizer-buildbot6/sanitizer-x86_64-linux-android/build/llvm_build64/bin/clang
   --target=aarch64-linux-android24 
--sysroot=/var/lib/buildbot/sanitizer-buildbot6/sanitizer-x86_64-linux-android/build/android_ndk/toolchains/llvm/prebuilt/linux-x86_64/sysroot
 
--gcc-toolchain=/var/lib/buildbot/sanitizer-buildbot6/sanitizer-x86_64-linux-android/build/android_ndk/toolchains/llvm/prebuilt/linux-x86_64
  
-B/var/lib/buildbot/sanitizer-buildbot6/sanitizer-x86_64-linux-android/build/android_ndk/toolchains/llvm/prebuilt/linux-x86_64
 -Wthread-safety -Wthread-safety-reference -Wthread-safety-beta  -fuse-ld=lld  
-gline-tables-only -fsanitize=hwaddress -fuse-ld=lld -mllvm -hwasan-globals 
-mllvm -hwasan-use-short-granules -mllvm -hwasan-instrument-landing-pads=0 
-mllvm -hwasan-instrument-personality-functions -Wl,--build-id -g 
/var/lib/buildbot/sanitizer-buildbot6/sanitizer-x86_64-linux-android/build/llvm-project/compiler-rt/test/hwasan/TestCases/hwasan_symbolize_stack_overflow.cpp
 -o 
/var/lib/buildbot/sanitizer-buildbot6/sanitizer-x86_64-linux-android/build/compiler_rt_build_android_aarch64/test/hwasan/AARCH64/TestCases/Output/hwasan_symbolize_stack_overflow.cpp.tmp/hwasan_overflow
+ 
/var/lib/buildbot/sanitizer-buildbot6/sanitizer-x86_64-linux-android/build/llvm-project/compiler-rt/test/sanitizer_common/android_commands/android_compile.py
 
/var/lib/buildbot/sanitizer-buildbot6/sanitizer-x86_64-linux-android/build/llvm_build64/bin/clang
 --target=aarch64-linux-android24 
--sysroot=/var/lib/buildbot/sanitizer-buildbot6/sanitizer-x86_64-linux-android/build/android_ndk/toolchains/llvm/prebuilt/linux-x86_64/sysroot
 
--gcc-toolchain=/var/lib/buildbot/sanitizer-buildbot6/sanitizer-x86_64-linux-android/build/android_ndk/toolchains/llvm/prebuilt/linux-x86_64
 
-B/var/lib/buildbot/sanitizer-buildbot6/sanitizer-x86_64-linux-android/build/android_ndk/toolchains/llvm/prebuilt/linux-x86_64
 -Wthread-safety -Wthread-safety-reference -Wthread-safety-beta -fuse-ld=lld 
-gline-tables-only -fsanitize=hwaddress -fuse-ld=lld -mllvm -hwasan-globals 
-mllvm -hwasan-use-short-granules -mllvm -hwasan-instrument-landing-pads=0 
-mllvm -hwasan-instrument-personality-functions -Wl,--build-id -g 
/var/lib/buildbot/sanitizer-buildbot6/sanitizer-x86_64-linux-android/build/llvm-project/compiler-rt/test/hwasan/TestCases/hwasan_symbolize_stack_overflow.cpp
 -o 
/var/lib/buildbot/sanitizer-buildbot6/sanitizer-x86_64-linux-android/build/c

[clang] Add clang atomic control options and attribute (PR #114841)

2025-02-26 Thread Yaxun Liu via cfe-commits


@@ -5442,6 +5442,155 @@ third argument, can only occur at file scope.
 a = b[i] * c[i] + e;
   }
 
+Extensions for controlling atomic code generation
+=
+
+The ``[[clang::atomic]]`` statement attribute enables users to control how
+atomic operations are lowered in LLVM IR by conveying additional metadata to
+the backend. The primary goal is to allow users to specify certain options,
+like whether atomic operations may be performed on specific types of memory or
+whether to ignore denormal mode correctness in floating-point operations,
+without affecting the correctness of code that does not rely on these 
behaviors.
+
+In LLVM, lowering of atomic operations (e.g., ``atomicrmw``) can differ based
+on the target's capabilities. Some backends support native atomic instructions
+only for certain operation types or alignments, or only in specific memory
+regions. Likewise, floating-point atomic instructions may or may not respect
+IEEE denormal requirements. When the user is unconcerned about denormal-mode
+compliance (for performance reasons) or knows that certain atomic operations
+will not be performed on a particular type of memory, extra hints are needed to
+tell the backend how to proceed.
+
+A classic example is an architecture where floating-point atomic add does not
+fully conform to IEEE denormal-mode handling. If the user does not mind 
ignoring
+that aspect, they would prefer to still emit a faster hardware atomic 
instruction,
+rather than a fallback or CAS loop. Conversely, on certain GPUs (e.g., AMDGPU),
+memory accessed via PCIe may only support a subset of atomic operations. To 
ensure
+correct and efficient lowering, the compiler must know whether the user wants 
to
+allow atomic operations on that type of memory.
+
+The allowed atomic attribute values are now ``remote_memory``, 
``fine_grained_memory``,
+and ``ignore_denormal_mode``, each optionally prefixed with ``no_``. The 
meanings
+are as follows:
+
+- ``remote_memory`` means atomic operations may be performed on remote memory.
+  Prefixing with ``no_`` (i.e. ``no_remote_memory``) indicates that atomic
+  operations should not be performed on remote memory.
+- ``fine_grained_memory`` means atomic operations may be performed on 
fine-grained
+  memory. Prefixing with ``no_`` (i.e. ``no_fine_grained_memory``) indicates 
that
+  atomic operations should not be performed on fine-grained memory.
+- ``ignore_denormal_mode`` means that atomic operations are allowed to ignore
+  correctness for denormal mode in floating-point operations, potentially 
improving
+  performance on architectures that handle denormals inefficiently. The 
negated form,
+  if specified as ``no_ignore_denormal_mode``, would enforce strict denormal 
mode
+  correctness.
+
+Within the same atomic attribute, duplicate and conflict values are accepted 
and the
+last value of conflicting values wins. Multiple atomic attributes are allowed
+for the same compound statement and the last atomic attribute wins.
+
+Without any atomic metadata, LLVM IR defaults to conservative settings for
+correctness: atomic operations are assumed to use remote memory, fine-grained
+memory, and enforce denormal mode correctness (i.e. the equivalent of
+``remote_memory``, ``fine_grained_memory``, and ``no_ignore_denormal_mode``).
+
+The attribute may be applied only to a compound statement and looks like:
+
+.. code-block:: c++
+
+   [[clang::atomic(remote_memory, fine_grained_memory, ignore_denormal_mode)]]
+   {
+   // Atomic instructions in this block carry extra metadata reflecting
+   // these user-specified options.
+   }
+
+You can provide one or more of these options, each optionally prefixed with
+``no_`` to negate that option. Any unspecified option is inherited from the
+global defaults, which can be set by a compiler flag or the target's built-in 
defaults.

yxsamliu wrote:

will do

https://github.com/llvm/llvm-project/pull/114841
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [llvm] [RISCV] Add Qualcomm uC Xqcisim (Simulation Hint) extension (PR #128833)

2025-02-26 Thread Jessica Clarke via cfe-commits

jrtc27 wrote:

Is this the kind of thing we have agreed to take in LLVM? If it's "simulation 
hint" instructions, does that not by definition mean that it's not an extension 
present in real hardware?

https://github.com/llvm/llvm-project/pull/128833
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] Hlsl or intrinsic (PR #128979)

2025-02-26 Thread via cfe-commits


@@ -290,6 +290,24 @@ _HLSL_BUILTIN_ALIAS(__builtin_hlsl_and)
 bool4 and(bool4 x, bool4 y);
 // clang-format on
 
+//===--===//
+// or builtins
+//===--===//
+
+/// \fn T or(T x, T y)
+/// \brief Returns the bitwise OR of the two input values, \a x and \a y.
+/// \param x The first input value and y The second input value.
+///
+/// \returns The logically OR a vector and retuens bool vector.

metkarpoonam wrote:

When I initially added 'or intrinsic' to the code, 'and intrinsic' was not 
included, so I utilized a different function style. This resulted in the 
discrepancy. I am now aligning it with the 'and intrinsic' description.

https://github.com/llvm/llvm-project/pull/128979
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] Add clang atomic control options and attribute (PR #114841)

2025-02-26 Thread Yaxun Liu via cfe-commits


@@ -5442,6 +5442,155 @@ third argument, can only occur at file scope.
 a = b[i] * c[i] + e;
   }
 
+Extensions for controlling atomic code generation
+=
+
+The ``[[clang::atomic]]`` statement attribute enables users to control how
+atomic operations are lowered in LLVM IR by conveying additional metadata to
+the backend. The primary goal is to allow users to specify certain options,
+like whether atomic operations may be performed on specific types of memory or
+whether to ignore denormal mode correctness in floating-point operations,
+without affecting the correctness of code that does not rely on these 
behaviors.
+
+In LLVM, lowering of atomic operations (e.g., ``atomicrmw``) can differ based
+on the target's capabilities. Some backends support native atomic instructions
+only for certain operation types or alignments, or only in specific memory
+regions. Likewise, floating-point atomic instructions may or may not respect
+IEEE denormal requirements. When the user is unconcerned about denormal-mode
+compliance (for performance reasons) or knows that certain atomic operations
+will not be performed on a particular type of memory, extra hints are needed to
+tell the backend how to proceed.
+
+A classic example is an architecture where floating-point atomic add does not
+fully conform to IEEE denormal-mode handling. If the user does not mind 
ignoring
+that aspect, they would prefer to still emit a faster hardware atomic 
instruction,
+rather than a fallback or CAS loop. Conversely, on certain GPUs (e.g., AMDGPU),
+memory accessed via PCIe may only support a subset of atomic operations. To 
ensure
+correct and efficient lowering, the compiler must know whether the user wants 
to
+allow atomic operations on that type of memory.

yxsamliu wrote:

will do

https://github.com/llvm/llvm-project/pull/114841
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] Hlsl or intrinsic (PR #128979)

2025-02-26 Thread via cfe-commits


@@ -290,6 +290,24 @@ _HLSL_BUILTIN_ALIAS(__builtin_hlsl_and)
 bool4 and(bool4 x, bool4 y);
 // clang-format on
 
+//===--===//
+// or builtins
+//===--===//
+
+/// \fn T or(T x, T y)
+/// \brief Returns the bitwise OR of the two input values, \a x and \a y.
+/// \param x The first input value and y The second input value.
+///
+/// \returns The logically OR a vector and retuens bool vector.
+
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_or)
+bool or(bool, bool);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_or)
+bool2 or(bool2, bool2);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_or)
+bool3 or(bool3, bool3);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_or)
+bool4 or(bool4, bool4);

metkarpoonam wrote:

When I initially added 'or intrinsic' to the code, 'and intrinsic' was not 
included, so I utilized a different function style. This resulted in the 
discrepancy. I am now aligning it with the 'and intrinsic' description.

I have added clang format off and on comments, similar to the 'and intrinsic' 
comments.

https://github.com/llvm/llvm-project/pull/128979
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [ARM] Introduce -mtp=auto and make it the default (PR #128901)

2025-02-26 Thread via cfe-commits

github-actions[bot] wrote:




:warning: C/C++ code formatter, clang-format found issues in your code. 
:warning:



You can test this locally with the following command:


``bash
git-clang-format --diff a955426a16bcbb9bf05eb0e3894663dff4983b00 
fb062da006042e7f0d6cab77f9d0d57a50d091f9 --extensions cpp,c -- 
clang/lib/Driver/ToolChains/Arch/ARM.cpp clang/test/Driver/arm-thread-pointer.c
``





View the diff from clang-format here.


``diff
diff --git a/clang/lib/Driver/ToolChains/Arch/ARM.cpp 
b/clang/lib/Driver/ToolChains/Arch/ARM.cpp
index c07b6afc08..42f92eb946 100644
--- a/clang/lib/Driver/ToolChains/Arch/ARM.cpp
+++ b/clang/lib/Driver/ToolChains/Arch/ARM.cpp
@@ -576,7 +576,7 @@ llvm::ARM::FPUKind arm::getARMTargetFeatures(const Driver 
&D,
 
   arm::ReadTPMode TPMode = getReadTPMode(D, Args, Triple, ForAS);
 
-  if (TPMode  == ReadTPMode::TPIDRURW)
+  if (TPMode == ReadTPMode::TPIDRURW)
 Features.push_back("+read-tp-tpidrurw");
   else if (TPMode == ReadTPMode::TPIDRURO)
 Features.push_back("+read-tp-tpidruro");

``




https://github.com/llvm/llvm-project/pull/128901
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [ARM] Introduce -mtp=auto and make it the default (PR #128901)

2025-02-26 Thread via cfe-commits

https://github.com/Zhenhang1213 updated 
https://github.com/llvm/llvm-project/pull/128901

>From 4bb02c6f8a81a4060fe99ca57602b65a507905d0 Mon Sep 17 00:00:00 2001
From: Austin 
Date: Thu, 27 Feb 2025 00:11:56 +0800
Subject: [PATCH] [ARM] Introduce -mtp=auto and make it the default

This adds a new value auto to the possible values of the existing -mtp= clang 
option which controls how the thread pointer is found. auto means the same as 
soft if the target architecture doesn't support a hardware thread pointer at 
all; otherwise it means the same as cp15.

This behavior is the default in gcc version 7.3.0 and later. The new auto 
option is therefore also the default in clang, so this change aligns clang with 
gcc.
---
 clang/lib/Driver/ToolChains/Arch/ARM.cpp | 10 +-
 clang/test/Driver/arm-thread-pointer.c   |  2 +-
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/clang/lib/Driver/ToolChains/Arch/ARM.cpp 
b/clang/lib/Driver/ToolChains/Arch/ARM.cpp
index 3aee540d501be..42f92eb94657a 100644
--- a/clang/lib/Driver/ToolChains/Arch/ARM.cpp
+++ b/clang/lib/Driver/ToolChains/Arch/ARM.cpp
@@ -239,7 +239,7 @@ arm::ReadTPMode arm::getReadTPMode(const Driver &D, const 
ArgList &Args,
   D.Diag(diag::err_drv_invalid_mtp) << A->getAsString(Args);
 return ReadTPMode::Invalid;
   }
-  return ReadTPMode::Soft;
+  return (isHardTPSupported(Triple) ? ReadTPMode::TPIDRURO : ReadTPMode::Soft);
 }
 
 void arm::setArchNameInTriple(const Driver &D, const ArgList &Args,
@@ -574,12 +574,12 @@ llvm::ARM::FPUKind arm::getARMTargetFeatures(const Driver 
&D,
   A->ignoreTargetSpecific();
   }
 
-  if (getReadTPMode(D, Args, Triple, ForAS) == ReadTPMode::TPIDRURW)
+  arm::ReadTPMode TPMode = getReadTPMode(D, Args, Triple, ForAS);
+
+  if (TPMode == ReadTPMode::TPIDRURW)
 Features.push_back("+read-tp-tpidrurw");
-  if (getReadTPMode(D, Args, Triple, ForAS) == ReadTPMode::TPIDRURO)
+  else if (TPMode == ReadTPMode::TPIDRURO)
 Features.push_back("+read-tp-tpidruro");
-  if (getReadTPMode(D, Args, Triple, ForAS) == ReadTPMode::TPIDRPRW)
-Features.push_back("+read-tp-tpidrprw");
 
   const Arg *ArchArg = Args.getLastArg(options::OPT_march_EQ);
   const Arg *CPUArg = Args.getLastArg(options::OPT_mcpu_EQ);
diff --git a/clang/test/Driver/arm-thread-pointer.c 
b/clang/test/Driver/arm-thread-pointer.c
index 5521e1865b276..e4bce724be74a 100644
--- a/clang/test/Driver/arm-thread-pointer.c
+++ b/clang/test/Driver/arm-thread-pointer.c
@@ -42,4 +42,4 @@
 
 // RUN: %clang --target=armv7-linux -### -S %s 2>&1 | \
 // RUN: FileCheck -check-prefix=ARMv7_THREAD_POINTER_NON %s
-// ARMv7_THREAD_POINTER_NON-NOT: "-target-feature" "+read-tp-tpidruro"
+// ARMv7_THREAD_POINTER_NON: "-target-feature" "+read-tp-tpidruro"

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang-tools-extra] [libcxx] [llvm] [libc++][ranges] P2542R8: Implement `views::concat` (PR #120920)

2025-02-26 Thread Nhat Nguyen via cfe-commits

https://github.com/changkhothuychung updated 
https://github.com/llvm/llvm-project/pull/120920

error: too big or took too long to generate
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [ARM] Introduce -mtp=auto and make it the default (PR #128901)

2025-02-26 Thread via cfe-commits

https://github.com/Zhenhang1213 updated 
https://github.com/llvm/llvm-project/pull/128901

>From fb062da006042e7f0d6cab77f9d0d57a50d091f9 Mon Sep 17 00:00:00 2001
From: Austin 
Date: Thu, 27 Feb 2025 00:11:56 +0800
Subject: [PATCH] [ARM] Introduce -mtp=auto and make it the default

This adds a new value auto to the possible values of the existing -mtp= clang 
option which controls how the thread pointer is found. auto means the same as 
soft if the target architecture doesn't support a hardware thread pointer at 
all; otherwise it means the same as cp15.

This behavior is the default in gcc version 7.3.0 and later. The new auto 
option is therefore also the default in clang, so this change aligns clang with 
gcc.
---
 clang/lib/Driver/ToolChains/Arch/ARM.cpp | 10 +-
 clang/test/Driver/arm-thread-pointer.c   |  2 +-
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/clang/lib/Driver/ToolChains/Arch/ARM.cpp 
b/clang/lib/Driver/ToolChains/Arch/ARM.cpp
index 3aee540d501be..c07b6afc08fd3 100644
--- a/clang/lib/Driver/ToolChains/Arch/ARM.cpp
+++ b/clang/lib/Driver/ToolChains/Arch/ARM.cpp
@@ -239,7 +239,7 @@ arm::ReadTPMode arm::getReadTPMode(const Driver &D, const 
ArgList &Args,
   D.Diag(diag::err_drv_invalid_mtp) << A->getAsString(Args);
 return ReadTPMode::Invalid;
   }
-  return ReadTPMode::Soft;
+  return (isHardTPSupported(Triple) ? ReadTPMode::TPIDRURO : ReadTPMode::Soft);
 }
 
 void arm::setArchNameInTriple(const Driver &D, const ArgList &Args,
@@ -574,12 +574,12 @@ llvm::ARM::FPUKind arm::getARMTargetFeatures(const Driver 
&D,
   A->ignoreTargetSpecific();
   }
 
-  if (getReadTPMode(D, Args, Triple, ForAS) == ReadTPMode::TPIDRURW)
+  arm::ReadTPMode TPMode = getReadTPMode(D, Args, Triple, ForAS);
+
+  if (TPMode  == ReadTPMode::TPIDRURW)
 Features.push_back("+read-tp-tpidrurw");
-  if (getReadTPMode(D, Args, Triple, ForAS) == ReadTPMode::TPIDRURO)
+  else if (TPMode == ReadTPMode::TPIDRURO)
 Features.push_back("+read-tp-tpidruro");
-  if (getReadTPMode(D, Args, Triple, ForAS) == ReadTPMode::TPIDRPRW)
-Features.push_back("+read-tp-tpidrprw");
 
   const Arg *ArchArg = Args.getLastArg(options::OPT_march_EQ);
   const Arg *CPUArg = Args.getLastArg(options::OPT_mcpu_EQ);
diff --git a/clang/test/Driver/arm-thread-pointer.c 
b/clang/test/Driver/arm-thread-pointer.c
index 5521e1865b276..e4bce724be74a 100644
--- a/clang/test/Driver/arm-thread-pointer.c
+++ b/clang/test/Driver/arm-thread-pointer.c
@@ -42,4 +42,4 @@
 
 // RUN: %clang --target=armv7-linux -### -S %s 2>&1 | \
 // RUN: FileCheck -check-prefix=ARMv7_THREAD_POINTER_NON %s
-// ARMv7_THREAD_POINTER_NON-NOT: "-target-feature" "+read-tp-tpidruro"
+// ARMv7_THREAD_POINTER_NON: "-target-feature" "+read-tp-tpidruro"

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] ExprEngine::performTrivialCopy triggers checkLocation (PR #129016)

2025-02-26 Thread via cfe-commits

https://github.com/T-Gruber created 
https://github.com/llvm/llvm-project/pull/129016

The triggered callbacks for the default copy constructed instance and the 
instance used for initialization now behave in the same way. The LHS already 
calls checkBind. To keep this consistent, checkLocation is now triggered 
accordingly for the RHS. 
Further details on the previous discussion: 
https://discourse.llvm.org/t/checklocation-for-implicitcastexpr-of-kind-ck-noop/84729

>From 79d8f061476c6ba21bf48f55597eaaef345c2e80 Mon Sep 17 00:00:00 2001
From: "tobias.gruber" 
Date: Wed, 26 Feb 2025 18:00:21 +0100
Subject: [PATCH 1/4] Trigger checkLocation for RHS of copy construction

---
 .../lib/StaticAnalyzer/Core/ExprEngineCXX.cpp | 250 +-
 1 file changed, 121 insertions(+), 129 deletions(-)

diff --git a/clang/lib/StaticAnalyzer/Core/ExprEngineCXX.cpp 
b/clang/lib/StaticAnalyzer/Core/ExprEngineCXX.cpp
index f7020da2e6da2..fbb5e316bb068 100644
--- a/clang/lib/StaticAnalyzer/Core/ExprEngineCXX.cpp
+++ b/clang/lib/StaticAnalyzer/Core/ExprEngineCXX.cpp
@@ -69,6 +69,7 @@ void ExprEngine::performTrivialCopy(NodeBuilder &Bldr, 
ExplodedNode *Pred,
 
   assert(ThisRD);
   SVal V = Call.getArgSVal(0);
+  const Expr *VExpr = Call.getArgExpr(0);
 
   // If the value being copied is not unknown, load from its location to get
   // an aggregate rvalue.
@@ -76,7 +77,11 @@ void ExprEngine::performTrivialCopy(NodeBuilder &Bldr, 
ExplodedNode *Pred,
 V = Pred->getState()->getSVal(*L);
   else
 assert(V.isUnknownOrUndef());
-  evalBind(Dst, CallExpr, Pred, ThisVal, V, true);
+
+  ExplodedNodeSet Tmp;
+  evalLocation(Tmp, CallExpr, VExpr, Pred, Pred->getState(), V, true);
+  for (ExplodedNode *N : Tmp)
+evalBind(Dst, CallExpr, N, ThisVal, V, true);
 
   PostStmt PS(CallExpr, LCtx);
   for (ExplodedNode *N : Dst) {
@@ -141,10 +146,9 @@ SVal ExprEngine::computeObjectUnderConstruction(
   if (Init->isBaseInitializer()) {
 const auto *ThisReg = cast(ThisVal.getAsRegion());
 const CXXRecordDecl *BaseClass =
-  Init->getBaseClass()->getAsCXXRecordDecl();
-const auto *BaseReg =
-  MRMgr.getCXXBaseObjectRegion(BaseClass, ThisReg,
-   Init->isBaseVirtual());
+Init->getBaseClass()->getAsCXXRecordDecl();
+const auto *BaseReg = MRMgr.getCXXBaseObjectRegion(
+BaseClass, ThisReg, Init->isBaseVirtual());
 return SVB.makeLoc(BaseReg);
   }
   if (Init->isDelegatingInitializer())
@@ -183,7 +187,7 @@ SVal ExprEngine::computeObjectUnderConstruction(
 
 return loc::MemRegionVal(R);
   }
-  return  V;
+  return V;
 }
 // TODO: Detect when the allocator returns a null pointer.
 // Constructor shall not be called in this case.
@@ -405,99 +409,99 @@ ProgramStateRef 
ExprEngine::updateObjectsUnderConstruction(
   case ConstructionContext::SimpleVariableKind: {
 const auto *DSCC = cast(CC);
 return addObjectUnderConstruction(State, DSCC->getDeclStmt(), LCtx, V);
-}
-case ConstructionContext::CXX17ElidedCopyConstructorInitializerKind:
-case ConstructionContext::SimpleConstructorInitializerKind: {
-  const auto *ICC = cast(CC);
-  const auto *Init = ICC->getCXXCtorInitializer();
-  // Base and delegating initializers handled above
-  assert(Init->isAnyMemberInitializer() &&
- "Base and delegating initializers should have been handled by"
- "computeObjectUnderConstruction()");
-  return addObjectUnderConstruction(State, Init, LCtx, V);
-}
-case ConstructionContext::NewAllocatedObjectKind: {
+  }
+  case ConstructionContext::CXX17ElidedCopyConstructorInitializerKind:
+  case ConstructionContext::SimpleConstructorInitializerKind: {
+const auto *ICC = cast(CC);
+const auto *Init = ICC->getCXXCtorInitializer();
+// Base and delegating initializers handled above
+assert(Init->isAnyMemberInitializer() &&
+   "Base and delegating initializers should have been handled by"
+   "computeObjectUnderConstruction()");
+return addObjectUnderConstruction(State, Init, LCtx, V);
+  }
+  case ConstructionContext::NewAllocatedObjectKind: {
+return State;
+  }
+  case ConstructionContext::SimpleReturnedValueKind:
+  case ConstructionContext::CXX17ElidedCopyReturnedValueKind: {
+const StackFrameContext *SFC = LCtx->getStackFrame();
+const LocationContext *CallerLCtx = SFC->getParent();
+if (!CallerLCtx) {
+  // No extra work is necessary in top frame.
   return State;
 }
-case ConstructionContext::SimpleReturnedValueKind:
-case ConstructionContext::CXX17ElidedCopyReturnedValueKind: {
-  const StackFrameContext *SFC = LCtx->getStackFrame();
-  const LocationContext *CallerLCtx = SFC->getParent();
-  if (!CallerLCtx) {
-// No extra work is necessary in top frame.
-return State;
-  }
 
-  auto RTC =

[clang] [ARM] Introduce -mtp=auto and make it the default (PR #128901)

2025-02-26 Thread via cfe-commits

https://github.com/Zhenhang1213 updated 
https://github.com/llvm/llvm-project/pull/128901

>From 3c2a6d7b1ea527a5cc4c54ce05d9cb6d57433b73 Mon Sep 17 00:00:00 2001
From: Austin 
Date: Thu, 27 Feb 2025 00:11:56 +0800
Subject: [PATCH] [ARM] Introduce -mtp=auto and make it the default

This adds a new value auto to the possible values of the existing -mtp= clang 
option which controls how the thread pointer is found. auto means the same as 
soft if the target architecture doesn't support a hardware thread pointer at 
all; otherwise it means the same as cp15.

This behavior is the default in gcc version 7.3.0 and later. The new auto 
option is therefore also the default in clang, so this change aligns clang with 
gcc.
---
 clang/lib/Driver/ToolChains/Arch/ARM.cpp | 10 ++
 clang/test/Driver/arm-thread-pointer.c   |  2 +-
 2 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/clang/lib/Driver/ToolChains/Arch/ARM.cpp 
b/clang/lib/Driver/ToolChains/Arch/ARM.cpp
index 3aee540d501be..6cc2437d27b0f 100644
--- a/clang/lib/Driver/ToolChains/Arch/ARM.cpp
+++ b/clang/lib/Driver/ToolChains/Arch/ARM.cpp
@@ -239,7 +239,7 @@ arm::ReadTPMode arm::getReadTPMode(const Driver &D, const 
ArgList &Args,
   D.Diag(diag::err_drv_invalid_mtp) << A->getAsString(Args);
 return ReadTPMode::Invalid;
   }
-  return ReadTPMode::Soft;
+  return (isHardTPSupported(Triple) ? ReadTPMode::TPIDRURO : ReadTPMode::Soft);
 }
 
 void arm::setArchNameInTriple(const Driver &D, const ArgList &Args,
@@ -574,11 +574,13 @@ llvm::ARM::FPUKind arm::getARMTargetFeatures(const Driver 
&D,
   A->ignoreTargetSpecific();
   }
 
-  if (getReadTPMode(D, Args, Triple, ForAS) == ReadTPMode::TPIDRURW)
+  arm::ReadTPMode TPMode = getReadTPMode(D, Args, Triple, ForAS);
+
+  if (TPMode == ReadTPMode::TPIDRURW)
 Features.push_back("+read-tp-tpidrurw");
-  if (getReadTPMode(D, Args, Triple, ForAS) == ReadTPMode::TPIDRURO)
+  else if (TPMode == ReadTPMode::TPIDRURO)
 Features.push_back("+read-tp-tpidruro");
-  if (getReadTPMode(D, Args, Triple, ForAS) == ReadTPMode::TPIDRPRW)
+  else if (TPMode == ReadTPMode::TPIDRPRW)
 Features.push_back("+read-tp-tpidrprw");
 
   const Arg *ArchArg = Args.getLastArg(options::OPT_march_EQ);
diff --git a/clang/test/Driver/arm-thread-pointer.c 
b/clang/test/Driver/arm-thread-pointer.c
index 5521e1865b276..e4bce724be74a 100644
--- a/clang/test/Driver/arm-thread-pointer.c
+++ b/clang/test/Driver/arm-thread-pointer.c
@@ -42,4 +42,4 @@
 
 // RUN: %clang --target=armv7-linux -### -S %s 2>&1 | \
 // RUN: FileCheck -check-prefix=ARMv7_THREAD_POINTER_NON %s
-// ARMv7_THREAD_POINTER_NON-NOT: "-target-feature" "+read-tp-tpidruro"
+// ARMv7_THREAD_POINTER_NON: "-target-feature" "+read-tp-tpidruro"

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] ExprEngine::performTrivialCopy triggers checkLocation (PR #129016)

2025-02-26 Thread via cfe-commits

llvmbot wrote:




@llvm/pr-subscribers-clang

Author: None (T-Gruber)


Changes

The triggered callbacks for the default copy constructed instance and the 
instance used for initialization now behave in the same way. The LHS already 
calls checkBind. To keep this consistent, checkLocation is now triggered 
accordingly for the RHS. 
Further details on the previous discussion: 
https://discourse.llvm.org/t/checklocation-for-implicitcastexpr-of-kind-ck-noop/84729

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


2 Files Affected:

- (modified) clang/lib/StaticAnalyzer/Core/ExprEngineCXX.cpp (+7-2) 
- (modified) clang/unittests/StaticAnalyzer/ExprEngineVisitTest.cpp (+54) 


``diff
diff --git a/clang/lib/StaticAnalyzer/Core/ExprEngineCXX.cpp 
b/clang/lib/StaticAnalyzer/Core/ExprEngineCXX.cpp
index f7020da2e6da2..47888cf9689c7 100644
--- a/clang/lib/StaticAnalyzer/Core/ExprEngineCXX.cpp
+++ b/clang/lib/StaticAnalyzer/Core/ExprEngineCXX.cpp
@@ -69,6 +69,7 @@ void ExprEngine::performTrivialCopy(NodeBuilder &Bldr, 
ExplodedNode *Pred,
 
   assert(ThisRD);
   SVal V = Call.getArgSVal(0);
+  const Expr *VExpr = Call.getArgExpr(0);
 
   // If the value being copied is not unknown, load from its location to get
   // an aggregate rvalue.
@@ -76,7 +77,11 @@ void ExprEngine::performTrivialCopy(NodeBuilder &Bldr, 
ExplodedNode *Pred,
 V = Pred->getState()->getSVal(*L);
   else
 assert(V.isUnknownOrUndef());
-  evalBind(Dst, CallExpr, Pred, ThisVal, V, true);
+  
+  ExplodedNodeSet Tmp;
+  evalLocation(Tmp, CallExpr, VExpr, Pred, Pred->getState(), V, true);
+  for (ExplodedNode *N : Tmp)
+evalBind(Dst, CallExpr, N, ThisVal, V, true);
 
   PostStmt PS(CallExpr, LCtx);
   for (ExplodedNode *N : Dst) {
@@ -1199,4 +1204,4 @@ void ExprEngine::VisitLambdaExpr(const LambdaExpr *LE, 
ExplodedNode *Pred,
 
   // FIXME: Move all post/pre visits to ::Visit().
   getCheckerManager().runCheckersForPostStmt(Dst, Tmp, LE, *this);
-}
+}
\ No newline at end of file
diff --git a/clang/unittests/StaticAnalyzer/ExprEngineVisitTest.cpp 
b/clang/unittests/StaticAnalyzer/ExprEngineVisitTest.cpp
index a8579f9d0f90c..19de9919701a3 100644
--- a/clang/unittests/StaticAnalyzer/ExprEngineVisitTest.cpp
+++ b/clang/unittests/StaticAnalyzer/ExprEngineVisitTest.cpp
@@ -12,6 +12,8 @@
 #include "clang/StaticAnalyzer/Core/BugReporter/BugType.h"
 #include "clang/StaticAnalyzer/Core/Checker.h"
 #include "clang/StaticAnalyzer/Core/PathSensitive/CheckerContext.h"
+#include "clang/StaticAnalyzer/Core/PathSensitive/SVals.h"
+#include "llvm/Support/Casting.h"
 #include "gtest/gtest.h"
 
 using namespace clang;
@@ -27,6 +29,14 @@ void emitErrorReport(CheckerContext &C, const BugType &Bug,
   }
 }
 
+inline std::string getMemRegionName(const SVal &Val) {
+  if (auto MemVal = llvm::dyn_cast(Val))
+return MemVal->getRegion()->getDescriptiveName(false);
+  if (auto ComVal = llvm::dyn_cast(Val))
+return ComVal->getRegion()->getDescriptiveName(false);
+  return "";
+}
+
 #define CREATE_EXPR_ENGINE_CHECKER(CHECKER_NAME, CALLBACK, STMT_TYPE,  
\
BUG_NAME)   
\
   class CHECKER_NAME : public Checker> {
\
@@ -44,6 +54,21 @@ CREATE_EXPR_ENGINE_CHECKER(ExprEngineVisitPreChecker, 
PreStmt, GCCAsmStmt,
 CREATE_EXPR_ENGINE_CHECKER(ExprEngineVisitPostChecker, PostStmt, GCCAsmStmt,
"GCCAsmStmtBug")
 
+class MemAccessChecker : public Checker {
+public:
+  void checkLocation(const SVal &Loc, bool IsLoad, const Stmt *S,
+ CheckerContext &C) const {
+emitErrorReport(C, Bug, "checkLocation: Loc = " + getMemRegionName(Loc));
+  }
+
+  void checkBind(SVal Loc, SVal Val, const Stmt *S, CheckerContext &C) const {
+emitErrorReport(C, Bug, "checkBind: Loc = " + getMemRegionName(Loc));
+  }
+
+private:
+  const BugType Bug{this, "MemAccess"};
+};
+
 void addExprEngineVisitPreChecker(AnalysisASTConsumer &AnalysisConsumer,
   AnalyzerOptions &AnOpts) {
   AnOpts.CheckersAndPackages = {{"ExprEngineVisitPreChecker", true}};
@@ -62,6 +87,15 @@ void addExprEngineVisitPostChecker(AnalysisASTConsumer 
&AnalysisConsumer,
   });
 }
 
+void addMemAccessChecker(AnalysisASTConsumer &AnalysisConsumer,
+ AnalyzerOptions &AnOpts) {
+  AnOpts.CheckersAndPackages = {{"MemAccessChecker", true}};
+  AnalysisConsumer.AddCheckerRegistrationFn([](CheckerRegistry &Registry) {
+Registry.addChecker("MemAccessChecker", "Desc",
+  "DocsURI");
+  });
+}
+
 TEST(ExprEngineVisitTest, checkPreStmtGCCAsmStmt) {
   std::string Diags;
   EXPECT_TRUE(runCheckerOnCode(R"(
@@ -84,4 +118,24 @@ TEST(ExprEngineVisitTest, checkPostStmtGCCAsmStmt) {
   EXPECT_EQ(Diags, "ExprEngineVisitPostChecker: checkPostStmt\n");
 }
 
+TEST(ExprEngineVisitTest, checkLocationAndBind) {
+  std::string Diags;
+  EXPECT_TRUE(runCheckerOnCode(R"(
+class MyClas

[clang] ExprEngine::performTrivialCopy triggers checkLocation (PR #129016)

2025-02-26 Thread via cfe-commits

github-actions[bot] wrote:




:warning: C/C++ code formatter, clang-format found issues in your code. 
:warning:



You can test this locally with the following command:


``bash
git-clang-format --diff af68927a831c45b92248b1f6fc24d445be42dd91 
57b4517b29bd6d8d7ba2fafa94b6b7b17494050b --extensions cpp -- 
clang/lib/StaticAnalyzer/Core/ExprEngineCXX.cpp 
clang/unittests/StaticAnalyzer/ExprEngineVisitTest.cpp
``





View the diff from clang-format here.


``diff
diff --git a/clang/lib/StaticAnalyzer/Core/ExprEngineCXX.cpp 
b/clang/lib/StaticAnalyzer/Core/ExprEngineCXX.cpp
index 47888cf968..0dbeee10ec 100644
--- a/clang/lib/StaticAnalyzer/Core/ExprEngineCXX.cpp
+++ b/clang/lib/StaticAnalyzer/Core/ExprEngineCXX.cpp
@@ -77,7 +77,7 @@ void ExprEngine::performTrivialCopy(NodeBuilder &Bldr, 
ExplodedNode *Pred,
 V = Pred->getState()->getSVal(*L);
   else
 assert(V.isUnknownOrUndef());
-  
+
   ExplodedNodeSet Tmp;
   evalLocation(Tmp, CallExpr, VExpr, Pred, Pred->getState(), V, true);
   for (ExplodedNode *N : Tmp)

``




https://github.com/llvm/llvm-project/pull/129016
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] ExprEngine::performTrivialCopy triggers checkLocation (PR #129016)

2025-02-26 Thread via cfe-commits

https://github.com/T-Gruber updated 
https://github.com/llvm/llvm-project/pull/129016

>From 79d8f061476c6ba21bf48f55597eaaef345c2e80 Mon Sep 17 00:00:00 2001
From: "tobias.gruber" 
Date: Wed, 26 Feb 2025 18:00:21 +0100
Subject: [PATCH 1/5] Trigger checkLocation for RHS of copy construction

---
 .../lib/StaticAnalyzer/Core/ExprEngineCXX.cpp | 250 +-
 1 file changed, 121 insertions(+), 129 deletions(-)

diff --git a/clang/lib/StaticAnalyzer/Core/ExprEngineCXX.cpp 
b/clang/lib/StaticAnalyzer/Core/ExprEngineCXX.cpp
index f7020da2e6da2..fbb5e316bb068 100644
--- a/clang/lib/StaticAnalyzer/Core/ExprEngineCXX.cpp
+++ b/clang/lib/StaticAnalyzer/Core/ExprEngineCXX.cpp
@@ -69,6 +69,7 @@ void ExprEngine::performTrivialCopy(NodeBuilder &Bldr, 
ExplodedNode *Pred,
 
   assert(ThisRD);
   SVal V = Call.getArgSVal(0);
+  const Expr *VExpr = Call.getArgExpr(0);
 
   // If the value being copied is not unknown, load from its location to get
   // an aggregate rvalue.
@@ -76,7 +77,11 @@ void ExprEngine::performTrivialCopy(NodeBuilder &Bldr, 
ExplodedNode *Pred,
 V = Pred->getState()->getSVal(*L);
   else
 assert(V.isUnknownOrUndef());
-  evalBind(Dst, CallExpr, Pred, ThisVal, V, true);
+
+  ExplodedNodeSet Tmp;
+  evalLocation(Tmp, CallExpr, VExpr, Pred, Pred->getState(), V, true);
+  for (ExplodedNode *N : Tmp)
+evalBind(Dst, CallExpr, N, ThisVal, V, true);
 
   PostStmt PS(CallExpr, LCtx);
   for (ExplodedNode *N : Dst) {
@@ -141,10 +146,9 @@ SVal ExprEngine::computeObjectUnderConstruction(
   if (Init->isBaseInitializer()) {
 const auto *ThisReg = cast(ThisVal.getAsRegion());
 const CXXRecordDecl *BaseClass =
-  Init->getBaseClass()->getAsCXXRecordDecl();
-const auto *BaseReg =
-  MRMgr.getCXXBaseObjectRegion(BaseClass, ThisReg,
-   Init->isBaseVirtual());
+Init->getBaseClass()->getAsCXXRecordDecl();
+const auto *BaseReg = MRMgr.getCXXBaseObjectRegion(
+BaseClass, ThisReg, Init->isBaseVirtual());
 return SVB.makeLoc(BaseReg);
   }
   if (Init->isDelegatingInitializer())
@@ -183,7 +187,7 @@ SVal ExprEngine::computeObjectUnderConstruction(
 
 return loc::MemRegionVal(R);
   }
-  return  V;
+  return V;
 }
 // TODO: Detect when the allocator returns a null pointer.
 // Constructor shall not be called in this case.
@@ -405,99 +409,99 @@ ProgramStateRef 
ExprEngine::updateObjectsUnderConstruction(
   case ConstructionContext::SimpleVariableKind: {
 const auto *DSCC = cast(CC);
 return addObjectUnderConstruction(State, DSCC->getDeclStmt(), LCtx, V);
-}
-case ConstructionContext::CXX17ElidedCopyConstructorInitializerKind:
-case ConstructionContext::SimpleConstructorInitializerKind: {
-  const auto *ICC = cast(CC);
-  const auto *Init = ICC->getCXXCtorInitializer();
-  // Base and delegating initializers handled above
-  assert(Init->isAnyMemberInitializer() &&
- "Base and delegating initializers should have been handled by"
- "computeObjectUnderConstruction()");
-  return addObjectUnderConstruction(State, Init, LCtx, V);
-}
-case ConstructionContext::NewAllocatedObjectKind: {
+  }
+  case ConstructionContext::CXX17ElidedCopyConstructorInitializerKind:
+  case ConstructionContext::SimpleConstructorInitializerKind: {
+const auto *ICC = cast(CC);
+const auto *Init = ICC->getCXXCtorInitializer();
+// Base and delegating initializers handled above
+assert(Init->isAnyMemberInitializer() &&
+   "Base and delegating initializers should have been handled by"
+   "computeObjectUnderConstruction()");
+return addObjectUnderConstruction(State, Init, LCtx, V);
+  }
+  case ConstructionContext::NewAllocatedObjectKind: {
+return State;
+  }
+  case ConstructionContext::SimpleReturnedValueKind:
+  case ConstructionContext::CXX17ElidedCopyReturnedValueKind: {
+const StackFrameContext *SFC = LCtx->getStackFrame();
+const LocationContext *CallerLCtx = SFC->getParent();
+if (!CallerLCtx) {
+  // No extra work is necessary in top frame.
   return State;
 }
-case ConstructionContext::SimpleReturnedValueKind:
-case ConstructionContext::CXX17ElidedCopyReturnedValueKind: {
-  const StackFrameContext *SFC = LCtx->getStackFrame();
-  const LocationContext *CallerLCtx = SFC->getParent();
-  if (!CallerLCtx) {
-// No extra work is necessary in top frame.
-return State;
-  }
 
-  auto RTC = (*SFC->getCallSiteBlock())[SFC->getIndex()]
- .getAs();
-  assert(RTC && "Could not have had a target region without it");
-  if (isa(CallerLCtx)) {
-// Unwrap block invocation contexts. They're mostly part of
-// the current stack frame.
-CallerLCtx = CallerLCtx->getParent();
-assert(!isa(CallerLCtx));
-  }
-
-  r

[clang] [ARM] make -mtp=TPIDRURO the default if the target architecture support a hardware thread pointer (PR #128901)

2025-02-26 Thread via cfe-commits

https://github.com/Zhenhang1213 edited 
https://github.com/llvm/llvm-project/pull/128901
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang][LoongArch] Add OHOS target (PR #127555)

2025-02-26 Thread via cfe-commits

https://github.com/Ami-zhang updated 
https://github.com/llvm/llvm-project/pull/127555

>From 49312a2cd5d1b6ab59f92571a925cfaeb0cf9eb3 Mon Sep 17 00:00:00 2001
From: Ami-zhang 
Date: Tue, 25 Feb 2025 11:28:36 +0800
Subject: [PATCH] [clang][LoongArch] Add OHOS target

Add support for OHOS on loongarch64.
---
 clang/lib/Basic/Targets.cpp   | 10 +++--
 clang/lib/Driver/ToolChains/OHOS.cpp  |  6 +-
 .../x.y.z/lib/loongarch64-linux-ohos/.keep|  0
 .../clang_rt.crtbegin.o   |  0
 .../loongarch64-linux-ohos/clang_rt.crtend.o  |  0
 .../libclang_rt.builtins.a|  0
 .../usr/include/loongarch64-linux-ohos/.keep  |  0
 .../usr/lib/loongarch64-linux-ohos/.keep  |  0
 clang/test/Driver/ohos.c  | 21 ++-
 clang/test/Preprocessor/ohos.c|  2 ++
 10 files changed, 35 insertions(+), 4 deletions(-)
 create mode 100644 
clang/test/Driver/Inputs/ohos_native_tree/llvm/lib/clang/x.y.z/lib/loongarch64-linux-ohos/.keep
 create mode 100644 
clang/test/Driver/Inputs/ohos_native_tree/llvm/lib/clang/x.y.z/lib/loongarch64-linux-ohos/clang_rt.crtbegin.o
 create mode 100644 
clang/test/Driver/Inputs/ohos_native_tree/llvm/lib/clang/x.y.z/lib/loongarch64-linux-ohos/clang_rt.crtend.o
 create mode 100644 
clang/test/Driver/Inputs/ohos_native_tree/llvm/lib/clang/x.y.z/lib/loongarch64-linux-ohos/libclang_rt.builtins.a
 create mode 100644 
clang/test/Driver/Inputs/ohos_native_tree/sysroot/usr/include/loongarch64-linux-ohos/.keep
 create mode 100644 
clang/test/Driver/Inputs/ohos_native_tree/sysroot/usr/lib/loongarch64-linux-ohos/.keep

diff --git a/clang/lib/Basic/Targets.cpp b/clang/lib/Basic/Targets.cpp
index 281aebdb1c35d..c6d228fe98100 100644
--- a/clang/lib/Basic/Targets.cpp
+++ b/clang/lib/Basic/Targets.cpp
@@ -749,8 +749,14 @@ std::unique_ptr AllocateTarget(const 
llvm::Triple &Triple,
   case llvm::Triple::loongarch64:
 switch (os) {
 case llvm::Triple::Linux:
-  return std::make_unique>(Triple,
-  Opts);
+  switch (Triple.getEnvironment()) {
+  default:
+return std::make_unique>(Triple,
+Opts);
+  case llvm::Triple::OpenHOS:
+return std::make_unique>(Triple,
+   Opts);
+  }
 case llvm::Triple::FreeBSD:
   return std::make_unique>(Triple,
 Opts);
diff --git a/clang/lib/Driver/ToolChains/OHOS.cpp 
b/clang/lib/Driver/ToolChains/OHOS.cpp
index 6e1a09ae908b2..e213c695a9fef 100644
--- a/clang/lib/Driver/ToolChains/OHOS.cpp
+++ b/clang/lib/Driver/ToolChains/OHOS.cpp
@@ -111,6 +111,8 @@ std::string OHOS::getMultiarchTriple(const llvm::Triple &T) 
const {
 return "x86_64-linux-ohos";
   case llvm::Triple::aarch64:
 return "aarch64-linux-ohos";
+  case llvm::Triple::loongarch64:
+return "loongarch64-linux-ohos";
   }
   return T.str();
 }
@@ -368,7 +370,9 @@ void OHOS::addExtraOpts(llvm::opt::ArgStringList &CmdArgs) 
const {
   CmdArgs.push_back("-z");
   CmdArgs.push_back("relro");
   CmdArgs.push_back("-z");
-  CmdArgs.push_back("max-page-size=4096");
+  CmdArgs.push_back(getArch() == llvm::Triple::loongarch64
+? "max-page-size=16384"
+: "max-page-size=4096");
   // .gnu.hash section is not compatible with the MIPS target
   if (getArch() != llvm::Triple::mipsel)
 CmdArgs.push_back("--hash-style=both");
diff --git 
a/clang/test/Driver/Inputs/ohos_native_tree/llvm/lib/clang/x.y.z/lib/loongarch64-linux-ohos/.keep
 
b/clang/test/Driver/Inputs/ohos_native_tree/llvm/lib/clang/x.y.z/lib/loongarch64-linux-ohos/.keep
new file mode 100644
index 0..e69de29bb2d1d
diff --git 
a/clang/test/Driver/Inputs/ohos_native_tree/llvm/lib/clang/x.y.z/lib/loongarch64-linux-ohos/clang_rt.crtbegin.o
 
b/clang/test/Driver/Inputs/ohos_native_tree/llvm/lib/clang/x.y.z/lib/loongarch64-linux-ohos/clang_rt.crtbegin.o
new file mode 100644
index 0..e69de29bb2d1d
diff --git 
a/clang/test/Driver/Inputs/ohos_native_tree/llvm/lib/clang/x.y.z/lib/loongarch64-linux-ohos/clang_rt.crtend.o
 
b/clang/test/Driver/Inputs/ohos_native_tree/llvm/lib/clang/x.y.z/lib/loongarch64-linux-ohos/clang_rt.crtend.o
new file mode 100644
index 0..e69de29bb2d1d
diff --git 
a/clang/test/Driver/Inputs/ohos_native_tree/llvm/lib/clang/x.y.z/lib/loongarch64-linux-ohos/libclang_rt.builtins.a
 
b/clang/test/Driver/Inputs/ohos_native_tree/llvm/lib/clang/x.y.z/lib/loongarch64-linux-ohos/libclang_rt.builtins.a
new file mode 100644
index 0..e69de29bb2d1d
diff --git 
a/clang/test/Driver/Inputs/ohos_native_tree/sysroot/usr/include/loongarch64-linux-ohos/.keep
 
b/clang/test/Driver/Inputs/ohos_native_tree/sysroot/usr/include/loongarch64-linux-ohos/.keep

[clang] [clang][LoongArch] Add OHOS target (PR #127555)

2025-02-26 Thread via cfe-commits


@@ -19,13 +23,16 @@
 // CHECK-NOT: "--build-id"
 // CHECK: "--hash-style=both"
 // CHECK: "-pie"
-// CHECK: "-dynamic-linker" "/lib/ld-musl-arm.so.1"
+// CHECK-ARM: "-dynamic-linker" "/lib/ld-musl-arm.so.1"

Ami-zhang wrote:

Yes, it dose. 

https://github.com/llvm/llvm-project/pull/127555
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] Mark union member destructors referenced (PR #128866)

2025-02-26 Thread Maurice Heumann via cfe-commits

https://github.com/momo5502 updated 
https://github.com/llvm/llvm-project/pull/128866

>From 484ff7a53ab700fda30ee90f739bb2573f41c851 Mon Sep 17 00:00:00 2001
From: Maurice Heumann 
Date: Wed, 26 Feb 2025 08:37:04 +0100
Subject: [PATCH 1/2] Mark union member destructors referenced

---
 clang/lib/Sema/SemaDeclCXX.cpp | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/clang/lib/Sema/SemaDeclCXX.cpp b/clang/lib/Sema/SemaDeclCXX.cpp
index 664d48ccbc382..ce7927dedd96b 100644
--- a/clang/lib/Sema/SemaDeclCXX.cpp
+++ b/clang/lib/Sema/SemaDeclCXX.cpp
@@ -5764,7 +5764,7 @@ 
Sema::MarkBaseAndMemberDestructorsReferenced(SourceLocation Location,
  CXXRecordDecl *ClassDecl) {
   // Ignore dependent contexts. Also ignore unions, since their members never
   // have destructors implicitly called.
-  if (ClassDecl->isDependentContext() || ClassDecl->isUnion())
+  if (ClassDecl->isDependentContext() /*|| ClassDecl->isUnion()*/)
 return;
 
   // FIXME: all the access-control diagnostics are positioned on the
@@ -5793,8 +5793,10 @@ 
Sema::MarkBaseAndMemberDestructorsReferenced(SourceLocation Location,
 if (FieldClassDecl->hasIrrelevantDestructor())
   continue;
 // The destructor for an implicit anonymous union member is never invoked.
-if (FieldClassDecl->isUnion() && 
FieldClassDecl->isAnonymousStructOrUnion())
+if (FieldClassDecl->isUnion() && 
FieldClassDecl->isAnonymousStructOrUnion()) {
+  MarkBaseAndMemberDestructorsReferenced(Location, FieldClassDecl);
   continue;
+}
 
 CXXDestructorDecl *Dtor = LookupDestructor(FieldClassDecl);
 // Dtor might still be missing, e.g because it's invalid.

>From fdfa8e245c87e127068436cb10d75e2a10be6f33 Mon Sep 17 00:00:00 2001
From: Maurice Heumann 
Date: Wed, 26 Feb 2025 14:31:47 +0100
Subject: [PATCH 2/2] Instantiate initialized field destructors

---
 clang/include/clang/Sema/Sema.h |  2 +
 clang/lib/Sema/SemaDeclCXX.cpp  | 84 ++---
 2 files changed, 49 insertions(+), 37 deletions(-)

diff --git a/clang/include/clang/Sema/Sema.h b/clang/include/clang/Sema/Sema.h
index 476abe86cb2d2..6d3879985c6ce 100644
--- a/clang/include/clang/Sema/Sema.h
+++ b/clang/include/clang/Sema/Sema.h
@@ -5432,6 +5432,8 @@ class Sema final : public SemaBase {
   void MarkBaseAndMemberDestructorsReferenced(SourceLocation Loc,
   CXXRecordDecl *Record);
 
+  void MarkFieldDestructorReferenced(SourceLocation Loc, FieldDecl *Field);
+
   /// Mark destructors of virtual bases of this class referenced. In the 
Itanium
   /// C++ ABI, this is done when emitting a destructor for any non-abstract
   /// class. In the Microsoft C++ ABI, this is done any time a class's
diff --git a/clang/lib/Sema/SemaDeclCXX.cpp b/clang/lib/Sema/SemaDeclCXX.cpp
index ce7927dedd96b..63602616b75be 100644
--- a/clang/lib/Sema/SemaDeclCXX.cpp
+++ b/clang/lib/Sema/SemaDeclCXX.cpp
@@ -5451,10 +5451,17 @@ bool Sema::SetCtorInitializers(CXXConstructorDecl 
*Constructor, bool AnyErrors,
NumInitializers * sizeof(CXXCtorInitializer*));
 Constructor->setCtorInitializers(baseOrMemberInitializers);
 
+SourceLocation Location = Constructor->getLocation();
+
+for (CXXCtorInitializer *Initializer : Info.AllToInit) {
+  auto *Field = Initializer->getAnyMember();
+  MarkFieldDestructorReferenced(Location, Field);
+}
+
 // Constructors implicitly reference the base and member
 // destructors.
-MarkBaseAndMemberDestructorsReferenced(Constructor->getLocation(),
-   Constructor->getParent());
+// MarkBaseAndMemberDestructorsReferenced(Location,
+// Constructor->getParent());
   }
 
   return HadError;
@@ -5759,6 +5766,43 @@ void Sema::ActOnMemInitializers(Decl *ConstructorDecl,
   DiagnoseUninitializedFields(*this, Constructor);
 }
 
+
+void Sema::MarkFieldDestructorReferenced(SourceLocation Location,
+ FieldDecl *Field) {
+  if (Field->isInvalidDecl())
+return;
+
+  // Don't destroy incomplete or zero-length arrays.
+  if (isIncompleteOrZeroLengthArrayType(Context, Field->getType()))
+return;
+
+  QualType FieldType = Context.getBaseElementType(Field->getType());
+
+  const RecordType *RT = FieldType->getAs();
+  if (!RT)
+return;
+
+  CXXRecordDecl *FieldClassDecl = cast(RT->getDecl());
+  if (FieldClassDecl->isInvalidDecl())
+return;
+  if (FieldClassDecl->hasIrrelevantDestructor())
+return;
+  // The destructor for an implicit anonymous union member is never invoked.
+  if (FieldClassDecl->isUnion() && FieldClassDecl->isAnonymousStructOrUnion())
+return;
+
+  CXXDestructorDecl *Dtor = LookupDestructor(FieldClassDecl);
+  // Dtor might still be missing, e.g because it's invalid.
+  if (!Dtor)
+return;
+  CheckDestructorAccess(Field->getLocation(), Dtor,
+PDiag(diag::err_access_dtor_fiel

[clang-tools-extra] [clang-tidy] Fix performance-move-const-arg false negative in ternary… (PR #128402)

2025-02-26 Thread David Rivera via cfe-commits

RiverDave wrote:

> ⚠️ C/C++ code formatter, clang-format found issues in your code. ⚠️
> 
> You can test this locally with the following command:
> ```shell
> git-clang-format --diff 5d501c6137976ff1f14f3b0e2e593fb9740d0146 
> 848be2ccd25fd68b6a2d2037198184b08ff5d6e2 --extensions cpp -- 
> clang-tools-extra/clang-tidy/performance/MoveConstArgCheck.cpp 
> clang-tools-extra/test/clang-tidy/checkers/performance/move-const-arg.cpp
> ```
> 
> View the diff from clang-format here.
> ```diff
> diff --git a/clang-tools-extra/clang-tidy/performance/MoveConstArgCheck.cpp 
> b/clang-tools-extra/clang-tidy/performance/MoveConstArgCheck.cpp
> index 553c1d20cb..703ad162f9 100644
> --- a/clang-tools-extra/clang-tidy/performance/MoveConstArgCheck.cpp
> +++ b/clang-tools-extra/clang-tidy/performance/MoveConstArgCheck.cpp
> @@ -63,16 +63,15 @@ void MoveConstArgCheck::registerMatchers(MatchFinder 
> *Finder) {
>// Matches respective ParmVarDecl for a CallExpr or CXXConstructExpr.
>auto ArgumentWithParamMatcher = forEachArgumentWithParam(
>anyOf(MoveCallMatcher, TernaryWithMoveMatcher),
> -  parmVarDecl(anyOf(hasType(ConstTypeParmMatcher),
> - hasType(RValueTypeParmMatcher)))
> -   .bind("invocation-parm"));
> +  parmVarDecl(
> +  anyOf(hasType(ConstTypeParmMatcher), 
> hasType(RValueTypeParmMatcher)))
> +  .bind("invocation-parm"));
>// Matches respective types of arguments for a CallExpr or CXXConstructExpr
>// and it works on calls through function pointers as well.
>auto ArgumentWithParamTypeMatcher = forEachArgumentWithParamType(
>anyOf(MoveCallMatcher, TernaryWithMoveMatcher),
>anyOf(ConstTypeParmMatcher, RValueTypeParmMatcher));
>  
> -
>Finder->addMatcher(
>invocation(anyOf(ArgumentWithParamMatcher, 
> ArgumentWithParamTypeMatcher))
>.bind("receiving-expr"),
> ```

This should be fixed now

https://github.com/llvm/llvm-project/pull/128402
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] Hlsl or intrinsic (PR #128979)

2025-02-26 Thread Sarah Spall via cfe-commits

https://github.com/spall edited https://github.com/llvm/llvm-project/pull/128979
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] Hlsl or intrinsic (PR #128979)

2025-02-26 Thread Sarah Spall via cfe-commits


@@ -290,6 +290,24 @@ _HLSL_BUILTIN_ALIAS(__builtin_hlsl_and)
 bool4 and(bool4 x, bool4 y);
 // clang-format on
 
+//===--===//
+// or builtins
+//===--===//
+
+/// \fn T or(T x, T y)
+/// \brief Returns the bitwise OR of the two input values, \a x and \a y.
+/// \param x The first input value and y The second input value.
+///
+/// \returns The logically OR a vector and retuens bool vector.

spall wrote:

Can you reword this sentence, I don't know what it means. I assume you mean to 
say the vectors are logically or'd together elementwise?

https://github.com/llvm/llvm-project/pull/128979
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] Hlsl or intrinsic (PR #128979)

2025-02-26 Thread Sarah Spall via cfe-commits


@@ -0,0 +1,27 @@
+// RUN: %clang_cc1 -finclude-default-header -triple 
dxil-pc-shadermodel6.6-library %s -verify -DTEST_FUNC=__builtin_hlsl_or
+// RUN: %clang_cc1 -finclude-default-header -triple 
dxil-pc-shadermodel6.6-library %s -verify -DTEST_FUNC=__builtin_hlsl_and
+
+
+bool test_too_few_arg(bool a)
+{
+return TEST_FUNC(a);
+  // expected-error@-1 {{too few arguments to function call, expected 2, have 
1}}
+}
+
+bool test_too_many_arg(bool a)
+{
+return TEST_FUNC(a, a, a);
+  // expected-error@-1 {{too many arguments to function call, expected 2, have 
3}}
+}
+
+bool2 test_mismatched_args(bool2 a, bool3 b)
+{
+return TEST_FUNC(a, b);
+  // expected-error@-1 {{all arguments to}}{{.*}}{{must have the same type}}
+}
+
+bool test_incorrect_type(int a)
+{
+return TEST_FUNC(a, a);
+  // expected-error@-1{{invalid operand of type 'int' where 'bool' or a vector 
of such type is required}}
+}

spall wrote:

add newline at the of the file

https://github.com/llvm/llvm-project/pull/128979
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] Hlsl or intrinsic (PR #128979)

2025-02-26 Thread Sarah Spall via cfe-commits


@@ -0,0 +1,85 @@
+// RUN: %clang_cc1 -finclude-default-header -triple \
+// RUN:   dxil-pc-shadermodel6.3-library %s \
+// RUN:   -emit-llvm -O1 -o - | FileCheck %s
+
+//CHECK-LABEL: define noundef i1 @_Z12test_or_boolbb(
+//CHECK-SAME: i1 noundef [[X:%.*]], i1 noundef [[Y:%.*]]) local_unnamed_addr 
#[[ATTR0:[0-9]+]] {
+//CHECK-NEXT:  [[ENTRY:.*:]]
+//CHECK-NEXT:[[HLSL_OR:%.*]] = or i1 [[x]], [[y]]
+//CHECK-NEXT:ret i1 [[HLSL_OR]]
+//CHECK_NEXT:  }
+bool test_or_bool(bool x, bool y)
+{
+return or(x, y);
+
+}
+
+//CHECK-LABEL: define noundef <2 x i1> @_Z13test_or_bool2Dv2_bS_(
+//CHECK-SAME: <2 x i1> noundef [[X:%.*]], <2 x i1> noundef [[Y:%.*]]) 
local_unnamed_addr #[[ATTR0]] {
+//CHECK-NEXT:  [[ENTRY:.*:]]
+//CHECK-NEXT:[[HLSL_OR:%.*]] = or <2 xi1> [[x]], [[y]]
+//CHECK-NEXT:ret <2 x i1> [[HLSL_OR]]
+//CHECK_NEXT:  }
+bool2 test_or_bool2(bool2 x, bool2 y)
+{
+return or(x, y);
+}
+
+//CHECK-LABEL: define noundef <3 x i1> @_Z13test_or_bool3Dv3_bS_(
+//CHECK-SAME: <3 x i1> noundef [[X:%.*]], <3 x i1> noundef [[Y:%.*]]) 
local_unnamed_addr #[[ATTR0]] {
+//CHECK-NEXT:  [[ENTRY:.*:]]
+//CHECK-NEXT:[[HLSL_OR:%.*]] = or <3 xi1> [[x]], [[y]]
+//CHECK-NEXT:ret <3 x i1> [[HLSL_OR]]
+//CHECK_NEXT:  }
+bool3 test_or_bool3(bool3 x, bool3 y)
+{
+return or(x, y);
+}
+
+//CHECK-LABEL: define noundef <4 x i1> @_Z13test_or_bool4Dv4_bS_(
+//CHECK-SAME: <4 x i1> noundef [[X:%.*]], <4 x i1> noundef [[Y:%.*]]) 
local_unnamed_addr #[[ATTR0]] {
+//CHECK-NEXT:  [[ENTRY:.*:]]
+//CHECK-NEXT:[[HLSL_OR:%.*]] = or <4 xi1> [[x]], [[y]]
+//CHECK-NEXT:ret <4 x i1> [[HLSL_OR]]
+//CHECK_NEXT:  }
+bool4 test_or_bool4(bool4 x, bool4 y)
+{
+return or(x, y);
+}
+
+//CHECK-LABEL: define noundef i1 @_Z11test_or_intii(
+//CHECK-SAME: i32 noundef [[X:%.*]], i32 noundef [[Y:%.*]]) local_unnamed_addr 
#[[ATTR0]] {
+//CHECK-NEXT:  [[ENTRY:.*:]]
+//CHECK_NEXT:[[0:%.*]] = or i32 [[y]], [[x]]
+//CHECK-NEXT:[[HLSL_OR:%.*]] = icmp ne i32 [[0]], 0
+//CHECK-NEXT:ret i1 [[HLSL_OR]]
+//CHECK_NEXT:  }
+bool test_or_int(int x, int y)
+{
+return or(x, y);
+}
+
+//CHECK-LABEL: define noundef <4 x i1> @_Z12test_or_int4Dv4_iS_(
+//CHECK-SAME: <4 x i32> noundef [[X:%.*]], <4 x i32> noundef [[Y:%.*]]) 
local_unnamed_addr #[[ATTR0]] {
+//CHECK-NEXT:  [[ENTRY:.*:]]
+//CHECK_NEXT:[[0:%.*]] = or <4 x i32> [[y]], [[x]]
+//CHECK-NEXT:[[HLSL_OR:%.*]] = icmp ne <4 x i32> [[0]], zeroinitializer
+//CHECK-NEXT:ret <4 x i1> [[HLSL_OR]]
+//CHECK_NEXT:  }
+bool4 test_or_int4(int4 x, int4 y)
+{
+return or(x, y);
+}
+
+//CHECK-LABEL: noundef <4 x i1> @_Z14test_or_float4Dv4_fS_(
+//CHECK-SAME: <4 x float> noundef nofpclass(nan inf) [[X:%.*]], <4 x float> 
noundef nofpclass(nan inf) [[Y:%.*]]) local_unnamed_addr #[[ATTR0]] {
+//CHECK-NEXT:  [[ENTRY:.*:]]
+//CHECK-NEXT:[[TOBOOL:%.*]] = fcmp reassoc nnan ninf nsz arcp afn une <4 x 
float> [[X]], zeroinitializer
+//CHECK-NEXT:[[TOBOOL1:%.*]] = fcmp reassoc nnan ninf nsz arcp afn une <4 
x float> [[Y]], zeroinitializer
+//CHECK-NEXT:[[HLSL_OR:%.*]] = or <4 x i1> [[TOBOOL]], [[TOBOOL1]]
+//CHECK-NEXT:ret <4 x i1> [[HLSL_OR]]
+//CHECK_NEXT:  }
+bool4 test_or_float4(float4 x, float4 y)
+{
+return or(x, y);
+}

spall wrote:

add a newline at the end

https://github.com/llvm/llvm-project/pull/128979
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] Add clang atomic control options and attribute (PR #114841)

2025-02-26 Thread Yaxun Liu via cfe-commits


@@ -5442,6 +5442,155 @@ third argument, can only occur at file scope.
 a = b[i] * c[i] + e;
   }
 
+Extensions for controlling atomic code generation
+=
+
+The ``[[clang::atomic]]`` statement attribute enables users to control how
+atomic operations are lowered in LLVM IR by conveying additional metadata to
+the backend. The primary goal is to allow users to specify certain options,
+like whether atomic operations may be performed on specific types of memory or
+whether to ignore denormal mode correctness in floating-point operations,
+without affecting the correctness of code that does not rely on these 
behaviors.
+
+In LLVM, lowering of atomic operations (e.g., ``atomicrmw``) can differ based
+on the target's capabilities. Some backends support native atomic instructions
+only for certain operation types or alignments, or only in specific memory
+regions. Likewise, floating-point atomic instructions may or may not respect
+IEEE denormal requirements. When the user is unconcerned about denormal-mode
+compliance (for performance reasons) or knows that certain atomic operations
+will not be performed on a particular type of memory, extra hints are needed to
+tell the backend how to proceed.
+
+A classic example is an architecture where floating-point atomic add does not
+fully conform to IEEE denormal-mode handling. If the user does not mind 
ignoring
+that aspect, they would prefer to still emit a faster hardware atomic 
instruction,
+rather than a fallback or CAS loop. Conversely, on certain GPUs (e.g., AMDGPU),
+memory accessed via PCIe may only support a subset of atomic operations. To 
ensure
+correct and efficient lowering, the compiler must know whether the user wants 
to
+allow atomic operations on that type of memory.
+
+The allowed atomic attribute values are now ``remote_memory``, 
``fine_grained_memory``,
+and ``ignore_denormal_mode``, each optionally prefixed with ``no_``. The 
meanings
+are as follows:
+
+- ``remote_memory`` means atomic operations may be performed on remote memory.
+  Prefixing with ``no_`` (i.e. ``no_remote_memory``) indicates that atomic
+  operations should not be performed on remote memory.
+- ``fine_grained_memory`` means atomic operations may be performed on 
fine-grained

yxsamliu wrote:

will do

https://github.com/llvm/llvm-project/pull/114841
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 5066d7b - [RISCV] Add Xqccmp 0.1 Assembly Support (#128731)

2025-02-26 Thread via cfe-commits

Author: Sam Elliott
Date: 2025-02-26T20:03:02-08:00
New Revision: 5066d7b60186fe0d557223493a17c3aa9a06f58f

URL: 
https://github.com/llvm/llvm-project/commit/5066d7b60186fe0d557223493a17c3aa9a06f58f
DIFF: 
https://github.com/llvm/llvm-project/commit/5066d7b60186fe0d557223493a17c3aa9a06f58f.diff

LOG: [RISCV] Add Xqccmp 0.1 Assembly Support (#128731)

Xqccmp is a new spec by Qualcomm that makes a vendor-specific effort to
solve the push/pop + frame pointers issue. Broadly, it takes the Zcmp
instructions and reverse the order they push/pop registers in, which
ends up matching the frame pointer convention.

This extension adds a new instruction not present in Zcmp,
`qc.cm.pushfp`, which will set `fp` to the incoming `sp` value after it
has pushed the registers.

This change duplicates the Zcmp implementation, with minor changes to
mnemonics (for the `qc.` prefix), predicates, and the addition of
`qc.cm.pushfp`. There is also new logic to prevent combining Xqccmp and
Zcmp. Xqccmp is kept separate to Xqci for decoding/encoding etc, as the
specs are separate today.

Specification:
https://github.com/quic/riscv-unified-db/releases/tag/Xqccmp_extension-0.1.0

Added: 
llvm/lib/Target/RISCV/RISCVInstrInfoXqccmp.td
llvm/test/MC/RISCV/rv32xqccmp-invalid.s
llvm/test/MC/RISCV/rv32xqccmp-valid.s
llvm/test/MC/RISCV/rv64e-xqccmp-valid.s
llvm/test/MC/RISCV/rv64xqccmp-invalid.s
llvm/test/MC/RISCV/rv64xqccmp-valid.s

Modified: 
clang/test/Driver/print-supported-extensions-riscv.c
llvm/docs/RISCVUsage.rst
llvm/docs/ReleaseNotes.md
llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
llvm/lib/Target/RISCV/Disassembler/RISCVDisassembler.cpp
llvm/lib/Target/RISCV/RISCVFeatures.td
llvm/lib/Target/RISCV/RISCVInstrInfo.td
llvm/lib/Target/RISCV/RISCVInstrInfoZc.td
llvm/lib/TargetParser/RISCVISAInfo.cpp
llvm/test/CodeGen/RISCV/attributes.ll
llvm/unittests/TargetParser/RISCVISAInfoTest.cpp

Removed: 




diff  --git a/clang/test/Driver/print-supported-extensions-riscv.c 
b/clang/test/Driver/print-supported-extensions-riscv.c
index 40f4ee8d2c89a..4d6e112f4e387 100644
--- a/clang/test/Driver/print-supported-extensions-riscv.c
+++ b/clang/test/Driver/print-supported-extensions-riscv.c
@@ -193,6 +193,7 @@
 // CHECK-NEXT: smctr1.0   'Smctr' (Control Transfer 
Records Machine Level)
 // CHECK-NEXT: ssctr1.0   'Ssctr' (Control Transfer 
Records Supervisor Level)
 // CHECK-NEXT: svukte   0.3   'Svukte' 
(Address-Independent Latency of User-Mode Faults to Supervisor Addresses)
+// CHECK-NEXT: xqccmp   0.1   'Xqccmp' (Qualcomm 16-bit 
Push/Pop and Double Moves)
 // CHECK-NEXT: xqcia0.4   'Xqcia' (Qualcomm uC 
Arithmetic Extension)
 // CHECK-NEXT: xqciac   0.3   'Xqciac' (Qualcomm uC 
Load-Store Address Calculation Extension)
 // CHECK-NEXT: xqcicli  0.2   'Xqcicli' (Qualcomm uC 
Conditional Load Immediate Extension)

diff  --git a/llvm/docs/RISCVUsage.rst b/llvm/docs/RISCVUsage.rst
index 50d642e841185..63185fe67440c 100644
--- a/llvm/docs/RISCVUsage.rst
+++ b/llvm/docs/RISCVUsage.rst
@@ -429,6 +429,9 @@ The current vendor extensions supported are:
 ``Xwchc``
   LLVM implements `the custom compressed opcodes present in some QingKe cores` 
by WCH / Nanjing Qinheng Microelectronics. The vendor refers to these opcodes 
by the name "XW".
 
+``experimental-Xqccmp``
+  LLVM implements `version 0.1 of the 16-bit Push/Pop instructions and 
double-moves extension specification 
`__
 by Qualcomm. All instructions are prefixed with `qc.` as described in the 
specification.
+
 ``experimental-Xqcia``
   LLVM implements `version 0.4 of the Qualcomm uC Arithmetic extension 
specification `__ by 
Qualcomm.  All instructions are prefixed with `qc.` as described in the 
specification. These instructions are only available for riscv32.
 

diff  --git a/llvm/docs/ReleaseNotes.md b/llvm/docs/ReleaseNotes.md
index 2a617901a1146..12dd09ad41135 100644
--- a/llvm/docs/ReleaseNotes.md
+++ b/llvm/docs/ReleaseNotes.md
@@ -109,6 +109,8 @@ Changes to the RISC-V Backend
 
 * Adds experimental assembler support for the Qualcomm uC 'Xqcilia` (Large 
Immediate Arithmetic)
   extension.
+* Adds experimental assembler support for the Qualcomm 'Xqccmp' extension, 
which
+  is a frame-pointer convention compatible version of Zcmp.
 
 Changes to the WebAssembly Backend
 --

diff  --git a/llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp 
b/llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
index 650ad48e50de0..36e2fa0262f9d 100644
--- a/llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
+++ b/llvm/lib/Target/RISCV/AsmPars

[clang] [llvm] [RISCV] Add Xqccmp Assembly Support (PR #128731)

2025-02-26 Thread Sam Elliott via cfe-commits

https://github.com/lenary closed 
https://github.com/llvm/llvm-project/pull/128731
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [llvm] [WIP] Correct lowering of `fp128` intrinsics (PR #76558)

2025-02-26 Thread Trevor Gross via cfe-commits

https://github.com/tgross35 updated 
https://github.com/llvm/llvm-project/pull/76558

>From f110337467d5a2b1f624eab507daa2bc854def17 Mon Sep 17 00:00:00 2001
From: Trevor Gross 
Date: Fri, 11 Aug 2023 22:16:01 -0400
Subject: [PATCH 1/4] [IR] Add an xpassing test for `f128` intrinsic lowering
 (nfc)

`f128` intrinsic functions lower to incorrect libc calls. Add a test
showing current behavior.
---
 .../CodeGen/Generic/f128-math-lowering.ll | 610 ++
 1 file changed, 610 insertions(+)
 create mode 100644 llvm/test/CodeGen/Generic/f128-math-lowering.ll

diff --git a/llvm/test/CodeGen/Generic/f128-math-lowering.ll 
b/llvm/test/CodeGen/Generic/f128-math-lowering.ll
new file mode 100644
index 0..8a70786d97fe6
--- /dev/null
+++ b/llvm/test/CodeGen/Generic/f128-math-lowering.ll
@@ -0,0 +1,610 @@
+
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py 
UTC_ARGS: --version 2
+;
+; RUN: llc < %s -mtriple=aarch64-unknown-unknown -verify-machineinstrs | 
FileCheck %s --check-prefix=CHECK-AARCH64
+; RUN: llc < %s -mtriple=riscv32-unknown-unknown -verify-machineinstrs | 
FileCheck %s --check-prefix=CHECK-RISCV32
+; RUN: llc < %s -mtriple=s390x-unknown-unknown -verify-machineinstrs | 
FileCheck %s --check-prefix=CHECK-S390X
+; RUN: llc < %s -mtriple=i686-unknown-unknown   -verify-machineinstrs | 
FileCheck %s --check-prefix=CHECK-X86
+; RUN: llc < %s -mtriple=x86_64-unknown-unknown -verify-machineinstrs | 
FileCheck %s --check-prefix=CHECK-X64
+;
+; Verify that fp128 intrinsics only lower to `long double` calls on platforms
+; where `f128` and `long double` have the same layout.
+;
+; We test on x86 and x64 which have 80-bit ld, as well as aarch64 (ld == f128),
+; riscv32 (ld == f64), and s380x (ld == f128 with different alignment from
+; x64/aarch64 f128).
+;
+; FIXME: these emit calls to long double functions but should emit f128 calls
+
+define fp128 @test_cbrtf128(fp128 %a) {
+; CHECK-LABEL:  test_cbrtf128:
+; CHECK-AARCH64:b llvm.cbrt.f128
+; CHECK-RISCV32:call llvm.cbrt.f128@plt
+; CHECK-S390X:  brasl {{%.*}} llvm.cbrt.f128@PLT
+; CHECK-X64:jmp llvm.cbrt.f128@PLT # TAILCALL
+; CHECK-X86:calll llvm.cbrt.f128@PLT
+start:
+  %0 = tail call fp128 @llvm.cbrt.f128(fp128 %a)
+  ret fp128 %0
+}
+
+declare fp128 @llvm.cbrt.f128(fp128)
+
+
+define fp128 @test_ceilf128(fp128 %a) {
+; CHECK-LABEL:  test_ceilf128:
+; CHECK-AARCH64:b ceill
+; CHECK-RISCV32:call ceill@plt
+; CHECK-S390X:  brasl {{%.*}} ceill@PLT
+; CHECK-X64:jmp ceill@PLT
+; CHECK-X86:calll ceill
+start:
+  %0 = tail call fp128 @llvm.ceil.f128(fp128 %a)
+  ret fp128 %0
+}
+
+declare fp128 @llvm.ceil.f128(fp128)
+
+
+define fp128 @test_copysignf128(fp128 %a, fp128 %b) {
+; No math library call here, so make sure the assembly does the correct thing.
+; This test is autogenerated
+; CHECK-LABEL:test_copysignf128:
+; CHECK-AARCH64-LABEL: test_copysignf128:
+; CHECK-AARCH64:   // %bb.0: // %start
+; CHECK-AARCH64-NEXT:stp q0, q1, [sp, #-32]!
+; CHECK-AARCH64-NEXT:.cfi_def_cfa_offset 32
+; CHECK-AARCH64-NEXT:ldrb w8, [sp, #15]
+; CHECK-AARCH64-NEXT:ldrb w9, [sp, #31]
+; CHECK-AARCH64-NEXT:bfxil w9, w8, #0, #7
+; CHECK-AARCH64-NEXT:strb w9, [sp, #15]
+; CHECK-AARCH64-NEXT:ldr q0, [sp], #32
+; CHECK-AARCH64-NEXT:ret
+;
+; CHECK-RISCV32-LABEL: test_copysignf128:
+; CHECK-RISCV32:   # %bb.0: # %start
+; CHECK-RISCV32-NEXT:lw a3, 0(a1)
+; CHECK-RISCV32-NEXT:lw a4, 4(a1)
+; CHECK-RISCV32-NEXT:lw a2, 12(a2)
+; CHECK-RISCV32-NEXT:lw a5, 12(a1)
+; CHECK-RISCV32-NEXT:lw a1, 8(a1)
+; CHECK-RISCV32-NEXT:lui a6, 524288
+; CHECK-RISCV32-NEXT:and a2, a2, a6
+; CHECK-RISCV32-NEXT:slli a5, a5, 1
+; CHECK-RISCV32-NEXT:srli a5, a5, 1
+; CHECK-RISCV32-NEXT:or a2, a5, a2
+; CHECK-RISCV32-NEXT:sw a1, 8(a0)
+; CHECK-RISCV32-NEXT:sw a4, 4(a0)
+; CHECK-RISCV32-NEXT:sw a3, 0(a0)
+; CHECK-RISCV32-NEXT:sw a2, 12(a0)
+; CHECK-RISCV32-NEXT:ret
+;
+; CHECK-S390X-LABEL: test_copysignf128:
+; CHECK-S390X:   # %bb.0: # %start
+; CHECK-S390X-NEXT:ld %f0, 0(%r3)
+; CHECK-S390X-NEXT:ld %f2, 8(%r3)
+; CHECK-S390X-NEXT:ld %f1, 0(%r4)
+; CHECK-S390X-NEXT:ld %f3, 8(%r4)
+; CHECK-S390X-NEXT:cpsdr %f0, %f1, %f0
+; CHECK-S390X-NEXT:std %f0, 0(%r2)
+; CHECK-S390X-NEXT:std %f2, 8(%r2)
+; CHECK-S390X-NEXT:br %r14
+;
+; CHECK-X86-LABEL: test_copysignf128:
+; CHECK-X86:   # %bb.0: # %start
+; CHECK-X86-NEXT:pushl %ebx
+; CHECK-X86-NEXT:.cfi_def_cfa_offset 8
+; CHECK-X86-NEXT:pushl %edi
+; CHECK-X86-NEXT:.cfi_def_cfa_offset 12
+; CHECK-X86-NEXT:pushl %esi
+; CHECK-X86-NEXT:.cfi_def_cfa_offset 16
+; CHECK-X86-NEXT:.cfi_offset %esi, -16
+; CHECK-X86-NEXT:.cfi_offset %edi, -12
+; CHECK-X86-NEXT:.cfi_offset %ebx, -8
+; CHECK-X86-NEXT:movl {{[0-9]+}}(%esp), %eax
+; CHECK-X86-NEXT:movl {{[0-9]+}}(%esp), %ecx
+; CHECK-

[clang] Hlsl or intrinsic (PR #128979)

2025-02-26 Thread via cfe-commits

https://github.com/metkarpoonam updated 
https://github.com/llvm/llvm-project/pull/128979

>From 08e191213d3abfc6a5f2af7ba3db35055dd040eb Mon Sep 17 00:00:00 2001
From: Poonam Vilas Metkar 
Date: Wed, 26 Feb 2025 16:23:01 -0800
Subject: [PATCH 1/7] Format hlsl_intrinsics.h with clang-format

---
 clang/lib/Headers/hlsl/hlsl_intrinsics.h | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/clang/lib/Headers/hlsl/hlsl_intrinsics.h 
b/clang/lib/Headers/hlsl/hlsl_intrinsics.h
index 239d7a3f59b77..764cf671dce31 100644
--- a/clang/lib/Headers/hlsl/hlsl_intrinsics.h
+++ b/clang/lib/Headers/hlsl/hlsl_intrinsics.h
@@ -290,6 +290,24 @@ _HLSL_BUILTIN_ALIAS(__builtin_hlsl_and)
 bool4 and(bool4 x, bool4 y);
 // clang-format on
 
+//===--===//
+// or builtins
+//===--===//
+
+/// \fn T or(T x, T y)
+/// \brief Returns the bitwise OR of the two input values, \a x and \a y.
+/// \param x The first input value and y The second input value.
+///
+/// \returns The logically OR a vector and retuens bool vector.
+
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_or)
+bool or(bool, bool);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_or)
+bool2 or(bool2, bool2);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_or)
+bool3 or(bool3, bool3);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_or)
+bool4 or(bool4, bool4);
 
//===--===//
 // any builtins
 
//===--===//

>From eae4c9f114f43e314146ecd5569c631188f93bff Mon Sep 17 00:00:00 2001
From: Poonam Vilas Metkar 
Date: Wed, 26 Feb 2025 16:36:50 -0800
Subject: [PATCH 2/7] Include HLSL or_intrinsic, add codegen in CGBuiltin, and
 the corresponding tests in or.hlsl. Additionally, incorporate
 logical-operator-errors to handle both 'and' and 'or' semantic diagnostics.

---
 clang/include/clang/Basic/Builtins.td |  6 ++
 clang/lib/CodeGen/CGBuiltin.cpp   |  5 ++
 clang/lib/Sema/SemaHLSL.cpp   | 19 +
 clang/test/CodeGenHLSL/builtins/or.hlsl   | 85 +++
 .../SemaHLSL/logical-operator-errors.hlsl | 27 ++
 5 files changed, 142 insertions(+)
 create mode 100644 clang/test/CodeGenHLSL/builtins/or.hlsl
 create mode 100644 clang/test/SemaHLSL/logical-operator-errors.hlsl

diff --git a/clang/include/clang/Basic/Builtins.td 
b/clang/include/clang/Basic/Builtins.td
index 598ae171b1389..f7027331cd6c5 100644
--- a/clang/include/clang/Basic/Builtins.td
+++ b/clang/include/clang/Basic/Builtins.td
@@ -4783,6 +4783,12 @@ def HLSLAnd : LangBuiltin<"HLSL_LANG"> {
   let Prototype = "void(...)";
 }
 
+def HLSLOr : LangBuiltin<"HLSL_LANG"> {
+  let Spellings = ["__builtin_hlsl_or"];
+  let Attributes = [NoThrow, Const];
+  let Prototype = "void(...)";
+}
+
 def HLSLAny : LangBuiltin<"HLSL_LANG"> {
   let Spellings = ["__builtin_hlsl_any"];
   let Attributes = [NoThrow, Const];
diff --git a/clang/lib/CodeGen/CGBuiltin.cpp b/clang/lib/CodeGen/CGBuiltin.cpp
index 65fac01d58362..599e05819ec7c 100644
--- a/clang/lib/CodeGen/CGBuiltin.cpp
+++ b/clang/lib/CodeGen/CGBuiltin.cpp
@@ -19492,6 +19492,11 @@ Value *CodeGenFunction::EmitHLSLBuiltinExpr(unsigned 
BuiltinID,
 Value *Op1 = EmitScalarExpr(E->getArg(1));
 return Builder.CreateAnd(Op0, Op1, "hlsl.and");
   }
+  case Builtin::BI__builtin_hlsl_or: {
+Value *Op0 = EmitScalarExpr(E->getArg(0));
+Value *Op1 = EmitScalarExpr(E->getArg(1));
+return Builder.CreateOr(Op0, Op1, "hlsl.or");
+  }
   case Builtin::BI__builtin_hlsl_any: {
 Value *Op0 = EmitScalarExpr(E->getArg(0));
 return Builder.CreateIntrinsic(
diff --git a/clang/lib/Sema/SemaHLSL.cpp b/clang/lib/Sema/SemaHLSL.cpp
index 283a9801fc707..c48512673be58 100644
--- a/clang/lib/Sema/SemaHLSL.cpp
+++ b/clang/lib/Sema/SemaHLSL.cpp
@@ -2305,6 +2305,25 @@ bool SemaHLSL::CheckBuiltinFunctionCall(unsigned 
BuiltinID, CallExpr *TheCall) {
 TheCall->setType(ArgTyA);
 break;
   }
+  case Builtin::BI__builtin_hlsl_or: {
+if (SemaRef.checkArgCount(TheCall, 2))
+  return true;
+if (CheckVectorElementCallArgs(&SemaRef, TheCall))
+  return true;
+
+// Ensure input expr type is a scalar/vector and the same as the return 
type
+if (CheckScalarOrVector(&SemaRef, TheCall, getASTContext().BoolTy, 0))
+  return true;
+
+// Ensure input parameter type is bool
+ExprResult A = TheCall->getArg(0);
+QualType ArgTyA = A.get()->getType();
+
+// return type is the same as the input type
+TheCall->setType(ArgTyA);
+
+break;
+  }
   case Builtin::BI__builtin_hlsl_all:
   case Builtin::BI__builtin_hlsl_any: {
 if (SemaRef.checkArgCount(TheCall, 1))
diff --git a/clang/test/CodeGenHLSL/builtins/or.hlsl 
b/clang/test/CodeGenHLSL/builtins/or.hlsl
new file mode 100644
index 0..0c21973bda17c
--- /dev/null
+++ b/clang/test/CodeGenHLSL/builtins

[clang] 556eb82 - [CIR] Function type return type improvements (#128787)

2025-02-26 Thread via cfe-commits

Author: David Olsen
Date: 2025-02-26T20:58:49-08:00
New Revision: 556eb8244201a81fff7b246561a677a782b69fa0

URL: 
https://github.com/llvm/llvm-project/commit/556eb8244201a81fff7b246561a677a782b69fa0
DIFF: 
https://github.com/llvm/llvm-project/commit/556eb8244201a81fff7b246561a677a782b69fa0.diff

LOG: [CIR] Function type return type improvements (#128787)

When a C or C++ function has a return type of `void`, the function type
is now represented in MLIR as having no return type rather than having a
return type of `!cir.void`. This avoids breaking MLIR invariants that
require the number of return types and the number of return values to
match.

Change the assembly format for `cir::FuncType` from having a leading
return type to having a trailing return type. In other words, change
```
!cir.func
```
to
```
!cir.func<(!argTypes) -> !returnType)>
```
Unless the function returns `void`, in which case change
```
!cir.func
```
to
```
!cir.func<(!argTypes)>
```

Added: 


Modified: 
clang/include/clang/CIR/Dialect/IR/CIROps.td
clang/include/clang/CIR/Dialect/IR/CIRTypes.td
clang/lib/CIR/CodeGen/CIRGenTypes.cpp
clang/lib/CIR/Dialect/IR/CIRDialect.cpp
clang/lib/CIR/Dialect/IR/CIRTypes.cpp
clang/test/CIR/IR/func.cir
clang/test/CIR/IR/global.cir
clang/test/CIR/func-simple.cpp
clang/test/CIR/global-var-simple.cpp

Removed: 




diff  --git a/clang/include/clang/CIR/Dialect/IR/CIROps.td 
b/clang/include/clang/CIR/Dialect/IR/CIROps.td
index 45d39807b35c8..f9ce38588e436 100644
--- a/clang/include/clang/CIR/Dialect/IR/CIROps.td
+++ b/clang/include/clang/CIR/Dialect/IR/CIROps.td
@@ -365,12 +365,6 @@ def FuncOp : CIR_Op<"func", [
return getFunctionType().getReturnTypes();
 }
 
-/// Hook for OpTrait::FunctionOpInterfaceTrait, called after verifying that
-/// the 'type' attribute is present and checks if it holds a function type.
-/// Ensures getType, getNumFuncArguments, and getNumFuncResults can be
-/// called safely.
-llvm::LogicalResult verifyType();
-
 
//===--===//
 // SymbolOpInterface Methods
 
//===--===//

diff  --git a/clang/include/clang/CIR/Dialect/IR/CIRTypes.td 
b/clang/include/clang/CIR/Dialect/IR/CIRTypes.td
index fc8edbcf3e166..a78e5eae08e33 100644
--- a/clang/include/clang/CIR/Dialect/IR/CIRTypes.td
+++ b/clang/include/clang/CIR/Dialect/IR/CIRTypes.td
@@ -287,32 +287,44 @@ def CIR_BoolType :
 def CIR_FuncType : CIR_Type<"Func", "func"> {
   let summary = "CIR function type";
   let description = [{
-The `!cir.func` is a function type. It consists of a single return type, a
-list of parameter types and can optionally be variadic.
+The `!cir.func` is a function type. It consists of an optional return type,
+a list of parameter types and can optionally be variadic.
 
 Example:
 
 ```mlir
-!cir.func
-!cir.func
-!cir.func
+!cir.func<()>
+!cir.func<() -> bool>
+!cir.func<(!s8i, !s8i)>
+!cir.func<(!s8i, !s8i) -> !s32i>
+!cir.func<(!s32i, ...) -> !s32i>
 ```
   }];
 
   let parameters = (ins ArrayRefParameter<"mlir::Type">:$inputs,
-"mlir::Type":$returnType, "bool":$varArg);
+OptionalParameter<"mlir::Type">:$optionalReturnType,
+"bool":$varArg);
+  // Use a custom parser to handle argument types with variadic elipsis.
   let assemblyFormat = [{
-`<` $returnType ` ` `(` custom($inputs, $varArg) `>`
+`<` custom($inputs, $varArg)  (`->` $optionalReturnType^)? 
`>`
   }];
 
   let builders = [
+// Create a FuncType, converting the return type from C-style to
+// MLIR-style.  If the given return type is `cir::VoidType`, ignore it
+// and create the FuncType with no return type, which is how MLIR
+// represents function types.
 TypeBuilderWithInferredContext<(ins
   "llvm::ArrayRef":$inputs, "mlir::Type":$returnType,
   CArg<"bool", "false">:$isVarArg), [{
-  return $_get(returnType.getContext(), inputs, returnType, isVarArg);
+return $_get(returnType.getContext(), inputs,
+ mlir::isa(returnType) ? nullptr : 
returnType,
+ isVarArg);
 }]>
   ];
 
+  let genVerifyDecl = 1;
+
   let extraClassDeclaration = [{
 /// Returns whether the function is variadic.
 bool isVarArg() const { return getVarArg(); }
@@ -323,12 +335,17 @@ def CIR_FuncType : CIR_Type<"Func", "func"> {
 /// Returns the number of arguments to the function.
 unsigned getNumInputs() const { return getInputs().size(); }
 
-/// Returns the result type of the function as an ArrayRef, enabling better
-/// integration with generic MLIR utilities.
+/// Get the C-style return type of the function, which is !cir.void if the
+///

[clang] [CIR] Function type return type improvements (PR #128787)

2025-02-26 Thread David Olsen via cfe-commits

https://github.com/dkolsen-pgi closed 
https://github.com/llvm/llvm-project/pull/128787
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] Hlsl or intrinsic (PR #128979)

2025-02-26 Thread Damyan Pepper via cfe-commits


@@ -290,6 +290,24 @@ _HLSL_BUILTIN_ALIAS(__builtin_hlsl_and)
 bool4 and(bool4 x, bool4 y);
 // clang-format on
 
+//===--===//
+// or builtins
+//===--===//
+
+/// \fn T or(T x, T y)
+/// \brief Returns the bitwise OR of the two input values, \a x and \a y.
+/// \param x The first input value and y The second input value.
+///
+/// \returns The logically OR a vector and retuens bool vector.

damyanp wrote:

Any reason not to just follow the same pattern as the comment for "and" above?

https://github.com/llvm/llvm-project/pull/128979
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] Hlsl or intrinsic (PR #128979)

2025-02-26 Thread Damyan Pepper via cfe-commits


@@ -0,0 +1,85 @@
+// RUN: %clang_cc1 -finclude-default-header -triple \
+// RUN:   dxil-pc-shadermodel6.3-library %s \
+// RUN:   -emit-llvm -O1 -o - | FileCheck %s
+
+//CHECK-LABEL: define noundef i1 @_Z12test_or_boolbb(
+//CHECK-SAME: i1 noundef [[X:%.*]], i1 noundef [[Y:%.*]]) local_unnamed_addr 
#[[ATTR0:[0-9]+]] {
+//CHECK-NEXT:  [[ENTRY:.*:]]
+//CHECK-NEXT:[[HLSL_OR:%.*]] = or i1 [[x]], [[y]]
+//CHECK-NEXT:ret i1 [[HLSL_OR]]
+//CHECK_NEXT:  }
+bool test_or_bool(bool x, bool y)

damyanp wrote:

Suggest naming this `test_or_scalar` to be consistent with `and.hlsl`.

https://github.com/llvm/llvm-project/pull/128979
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] Hlsl or intrinsic (PR #128979)

2025-02-26 Thread Damyan Pepper via cfe-commits


@@ -290,6 +290,24 @@ _HLSL_BUILTIN_ALIAS(__builtin_hlsl_and)
 bool4 and(bool4 x, bool4 y);
 // clang-format on
 
+//===--===//
+// or builtins
+//===--===//
+
+/// \fn T or(T x, T y)
+/// \brief Returns the bitwise OR of the two input values, \a x and \a y.
+/// \param x The first input value and y The second input value.
+///
+/// \returns The logically OR a vector and retuens bool vector.
+
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_or)
+bool or(bool, bool);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_or)
+bool2 or(bool2, bool2);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_or)
+bool3 or(bool3, bool3);
+_HLSL_BUILTIN_ALIAS(__builtin_hlsl_or)
+bool4 or(bool4, bool4);

damyanp wrote:

Does clang-format get confused by this in the same that it does for `and` 
above?  If so, this may need to have clang-format disabled around it.

https://github.com/llvm/llvm-project/pull/128979
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] Hlsl or intrinsic (PR #128979)

2025-02-26 Thread Damyan Pepper via cfe-commits


@@ -2305,6 +2305,25 @@ bool SemaHLSL::CheckBuiltinFunctionCall(unsigned 
BuiltinID, CallExpr *TheCall) {
 TheCall->setType(ArgTyA);
 break;
   }
+  case Builtin::BI__builtin_hlsl_or: {
+if (SemaRef.checkArgCount(TheCall, 2))
+  return true;
+if (CheckVectorElementCallArgs(&SemaRef, TheCall))
+  return true;
+
+// Ensure input expr type is a scalar/vector and the same as the return 
type
+if (CheckScalarOrVector(&SemaRef, TheCall, getASTContext().BoolTy, 0))
+  return true;
+
+// Ensure input parameter type is bool

damyanp wrote:

> `// Ensure input parameter type is bool`

That's what the code above was doing.  This is just getting the type of the 
first argument, and then setting the return type of the entire expression to 
match that.



https://github.com/llvm/llvm-project/pull/128979
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] Hlsl or intrinsic (PR #128979)

2025-02-26 Thread Damyan Pepper via cfe-commits


@@ -0,0 +1,27 @@
+// RUN: %clang_cc1 -finclude-default-header -triple 
dxil-pc-shadermodel6.6-library %s -verify -DTEST_FUNC=__builtin_hlsl_or
+// RUN: %clang_cc1 -finclude-default-header -triple 
dxil-pc-shadermodel6.6-library %s -verify -DTEST_FUNC=__builtin_hlsl_and

damyanp wrote:

Neat!

https://github.com/llvm/llvm-project/pull/128979
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] Hlsl or intrinsic (PR #128979)

2025-02-26 Thread Damyan Pepper via cfe-commits

https://github.com/damyanp edited 
https://github.com/llvm/llvm-project/pull/128979
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] Hlsl or intrinsic (PR #128979)

2025-02-26 Thread Damyan Pepper via cfe-commits


@@ -2305,6 +2305,25 @@ bool SemaHLSL::CheckBuiltinFunctionCall(unsigned 
BuiltinID, CallExpr *TheCall) {
 TheCall->setType(ArgTyA);
 break;
   }
+  case Builtin::BI__builtin_hlsl_or: {
+if (SemaRef.checkArgCount(TheCall, 2))
+  return true;
+if (CheckVectorElementCallArgs(&SemaRef, TheCall))
+  return true;
+
+// Ensure input expr type is a scalar/vector and the same as the return 
type

damyanp wrote:

Can you help me understand what the "same as the return type" part means here? 

I don't really know this code but after reading the rest of the file I think:

```c++

// Check that there's two arguments to the function
if (SemaRef.checkArgCount(TheCall, 2))
return true;

// Check that the arguments are all the the same "size" (ie all scalars, 
// or all vectors of the same length), and the are the same type. But this 
function
// takes into account type promotions and things for you.
if (CheckVectorElementCallArgs(&SemaRef, TheCall))
  return true;

// Check that that type is either a scalar bool or a vector of bools.  Only the 
first 
// argument needs to be checked because the earlier checks validate that the
// arguments are the same.
 if (CheckScalarOrVector(&SemaRef, TheCall, getASTContext().BoolTy, 0))
return true;
```

I don't think these checks do anything with the return type.

Anyway, I think that readers of this file are expected to understand what these 
functions do, so I think adding comments here doesn't help much.

https://github.com/llvm/llvm-project/pull/128979
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] Hlsl or intrinsic (PR #128979)

2025-02-26 Thread Damyan Pepper via cfe-commits

https://github.com/damyanp edited 
https://github.com/llvm/llvm-project/pull/128979
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] Hlsl or intrinsic (PR #128979)

2025-02-26 Thread Damyan Pepper via cfe-commits

https://github.com/damyanp commented:

Please be sure to tag the issue that this is addressing in the PR description 
(something like "Closes #".)  Or at least make sure that it is linked in 
the "Development" section.

(Oops, I had two tabs open and confused github and myself)

https://github.com/llvm/llvm-project/pull/128979
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] Hlsl or intrinsic (PR #128979)

2025-02-26 Thread Damyan Pepper via cfe-commits

https://github.com/damyanp commented:

Congrats on getting your first change in!  Some notes, mainly around comments, 
although we probably also want to fix the clang-format issue (if there is one).

https://github.com/llvm/llvm-project/pull/128979
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [Clang] Treat constexpr-unknown value as invalid in `EvaluateAsInitializer` (PR #128409)

2025-02-26 Thread Yingwei Zheng via cfe-commits

https://github.com/dtcxzyw updated 
https://github.com/llvm/llvm-project/pull/128409

>From 83248eb164ff53442ad6d0c9d1be20027519bac1 Mon Sep 17 00:00:00 2001
From: Yingwei Zheng 
Date: Tue, 18 Feb 2025 01:26:26 +0800
Subject: [PATCH 1/6] [Clang][CodeGen] Bail out on constexpr unknown values in
 ConstantEmitter

---
 clang/lib/CodeGen/CGExprConstant.cpp|  6 --
 clang/test/CodeGenCXX/cxx23-p2280r4.cpp | 13 +
 2 files changed, 17 insertions(+), 2 deletions(-)
 create mode 100644 clang/test/CodeGenCXX/cxx23-p2280r4.cpp

diff --git a/clang/lib/CodeGen/CGExprConstant.cpp 
b/clang/lib/CodeGen/CGExprConstant.cpp
index ee5874b26f534..075f3f435ad74 100644
--- a/clang/lib/CodeGen/CGExprConstant.cpp
+++ b/clang/lib/CodeGen/CGExprConstant.cpp
@@ -1883,8 +1883,10 @@ llvm::Constant 
*ConstantEmitter::tryEmitPrivateForVarInit(const VarDecl &D) {
 
   // Try to emit the initializer.  Note that this can allow some things that
   // are not allowed by tryEmitPrivateForMemory alone.
-  if (APValue *value = D.evaluateValue())
-return tryEmitPrivateForMemory(*value, destType);
+  if (APValue *value = D.evaluateValue()) {
+if (!value->allowConstexprUnknown())
+  return tryEmitPrivateForMemory(*value, destType);
+  }
 
   return nullptr;
 }
diff --git a/clang/test/CodeGenCXX/cxx23-p2280r4.cpp 
b/clang/test/CodeGenCXX/cxx23-p2280r4.cpp
new file mode 100644
index 0..bb9a90ba18ece
--- /dev/null
+++ b/clang/test/CodeGenCXX/cxx23-p2280r4.cpp
@@ -0,0 +1,13 @@
+// RUN: %clang_cc1 -triple %itanium_abi_triple -std=c++23 %s -emit-llvm -o - | 
FileCheck %s
+
+extern int& s;
+
+// CHECK: @_Z4testv()
+// CHECK-NEXT: entry:
+// CHECK-NEXT: [[I:%.*]] = alloca ptr, align {{.*}}
+// CHECK-NEXT: [[X:%.*]] = load ptr, ptr @s, align {{.*}}
+// CHECK-NEXT: store ptr [[X]], ptr [[I]], align {{.*}}
+int& test() {
+  auto &i = s;
+  return i;
+}

>From ac2bd210ffed3d882be2569a415d7c4bbcbba3e9 Mon Sep 17 00:00:00 2001
From: Yingwei Zheng 
Date: Tue, 18 Feb 2025 19:20:39 +0800
Subject: [PATCH 2/6] Address review comments. NFC.

---
 clang/test/CodeGenCXX/cxx23-p2280r4.cpp | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/clang/test/CodeGenCXX/cxx23-p2280r4.cpp 
b/clang/test/CodeGenCXX/cxx23-p2280r4.cpp
index bb9a90ba18ece..d5409be451df0 100644
--- a/clang/test/CodeGenCXX/cxx23-p2280r4.cpp
+++ b/clang/test/CodeGenCXX/cxx23-p2280r4.cpp
@@ -1,4 +1,6 @@
 // RUN: %clang_cc1 -triple %itanium_abi_triple -std=c++23 %s -emit-llvm -o - | 
FileCheck %s
+// RUN: %clang_cc1 -triple %itanium_abi_triple -std=c++20 %s -emit-llvm -o - | 
FileCheck %s
+// RUN: %clang_cc1 -triple %itanium_abi_triple -std=c++17 %s -emit-llvm -o - | 
FileCheck %s
 
 extern int& s;
 

>From 1cea7d422c31b5065c76d9fb4a251955b2bea8e6 Mon Sep 17 00:00:00 2001
From: Yingwei Zheng 
Date: Fri, 21 Feb 2025 12:15:29 +0800
Subject: [PATCH 3/6] [Clang][CodeGen] Address review comments. NFC.

---
 clang/lib/CodeGen/CGExprConstant.cpp | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/clang/lib/CodeGen/CGExprConstant.cpp 
b/clang/lib/CodeGen/CGExprConstant.cpp
index 075f3f435ad74..7d44a9f583eca 100644
--- a/clang/lib/CodeGen/CGExprConstant.cpp
+++ b/clang/lib/CodeGen/CGExprConstant.cpp
@@ -1883,10 +1883,10 @@ llvm::Constant 
*ConstantEmitter::tryEmitPrivateForVarInit(const VarDecl &D) {
 
   // Try to emit the initializer.  Note that this can allow some things that
   // are not allowed by tryEmitPrivateForMemory alone.
-  if (APValue *value = D.evaluateValue()) {
-if (!value->allowConstexprUnknown())
-  return tryEmitPrivateForMemory(*value, destType);
-  }
+  // Bail out on constexpr-unknown values since they are invalid in CodeGen.
+  if (APValue *value = D.evaluateValue();
+  value && !value->allowConstexprUnknown())
+return tryEmitPrivateForMemory(*value, destType);
 
   return nullptr;
 }

>From bc24bde52b664ca4b3bcbbbdd48a5a14be37a278 Mon Sep 17 00:00:00 2001
From: Yingwei Zheng 
Date: Sun, 23 Feb 2025 17:04:03 +0800
Subject: [PATCH 4/6] [Clang] Treat constexpr-unknown value as invalid in
 `evaluateValue`

---
 clang/lib/AST/Decl.cpp   | 3 +++
 clang/lib/AST/ExprConstant.cpp   | 2 --
 clang/lib/CodeGen/CGExprConstant.cpp | 6 --
 clang/test/SemaCXX/constant-expression-cxx11.cpp | 4 ++--
 4 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/clang/lib/AST/Decl.cpp b/clang/lib/AST/Decl.cpp
index 5a3be1690f335..f6cf75ed96aca 100644
--- a/clang/lib/AST/Decl.cpp
+++ b/clang/lib/AST/Decl.cpp
@@ -2587,6 +2587,9 @@ APValue 
*VarDecl::evaluateValueImpl(SmallVectorImpl &Notes,
   !Notes.empty())
 Result = false;
 
+  if (Eval->Evaluated.allowConstexprUnknown())
+Result = false;
+
   // Ensure the computed APValue is cleaned up later if evaluation succeeded,
   // or that it's empty (so that there's nothing to clean up) if evaluation
   // failed.
diff --git a/clang/lib/AST/ExprConstant.cpp b/clang/lib/AST/ExprConstant.cpp
index 6ccb6e23f8d2f..5e6

[clang] Hlsl or intrinsic (PR #128979)

2025-02-26 Thread Damyan Pepper via cfe-commits

https://github.com/damyanp edited 
https://github.com/llvm/llvm-project/pull/128979
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [llvm] APFloat: Fix maxnum and minnum with sNaN (PR #112854)

2025-02-26 Thread YunQiang Su via cfe-commits

https://github.com/wzssyqa edited 
https://github.com/llvm/llvm-project/pull/112854
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [CIR] Function type return type improvements (PR #128787)

2025-02-26 Thread LLVM Continuous Integration via cfe-commits

llvm-ci wrote:

LLVM Buildbot has detected a new failure on builder `lldb-remote-linux-win` 
running on `as-builder-10` while building `clang` at step 17 
"test-check-lldb-api".

Full details are available at: 
https://lab.llvm.org/buildbot/#/builders/197/builds/2526


Here is the relevant piece of the build log for the reference

```
Step 17 (test-check-lldb-api) failure: Test just built components: 
check-lldb-api completed (failure)
 TEST 'lldb-api :: 
functionalities/thread/exit_during_step/TestExitDuringStep.py' FAILED 

Script:
--
C:/Python312/python.exe 
C:/buildbot/as-builder-10/lldb-x-aarch64/llvm-project/lldb\test\API\dotest.py 
-u CXXFLAGS -u CFLAGS --env 
LLVM_LIBS_DIR=C:/buildbot/as-builder-10/lldb-x-aarch64/build/./lib --env 
LLVM_INCLUDE_DIR=C:/buildbot/as-builder-10/lldb-x-aarch64/build/include --env 
LLVM_TOOLS_DIR=C:/buildbot/as-builder-10/lldb-x-aarch64/build/./bin --arch 
aarch64 --build-dir 
C:/buildbot/as-builder-10/lldb-x-aarch64/build/lldb-test-build.noindex 
--lldb-module-cache-dir 
C:/buildbot/as-builder-10/lldb-x-aarch64/build/lldb-test-build.noindex/module-cache-lldb\lldb-api
 --clang-module-cache-dir 
C:/buildbot/as-builder-10/lldb-x-aarch64/build/lldb-test-build.noindex/module-cache-clang\lldb-api
 --executable C:/buildbot/as-builder-10/lldb-x-aarch64/build/./bin/lldb.exe 
--compiler C:/buildbot/as-builder-10/lldb-x-aarch64/build/./bin/clang.exe 
--dsymutil C:/buildbot/as-builder-10/lldb-x-aarch64/build/./bin/dsymutil.exe 
--make C:/ninja/make.exe --llvm-tools-dir 
C:/buildbot/as-builder-10/lldb-x-aarch64/build/./bin --lldb-obj-root 
C:/buildbot/as-builder-10/lldb-x-aarch64/build/tools/lldb --lldb-libs-dir 
C:/buildbot/as-builder-10/lldb-x-aarch64/build/./lib --platform-url 
connect://jetson-agx-0086.lab.llvm.org:1234 --platform-working-dir 
/home/ubuntu/lldb-tests --sysroot c:/buildbot/fs/jetson-agx-ubuntu --env 
ARCH_CFLAGS=-mcpu=cortex-a78 --platform-name remote-linux 
--skip-category=lldb-server 
C:\buildbot\as-builder-10\lldb-x-aarch64\llvm-project\lldb\test\API\functionalities\thread\exit_during_step
 -p TestExitDuringStep.py
--
Exit Code: 1

Command Output (stdout):
--
lldb version 21.0.0git (https://github.com/llvm/llvm-project.git revision 
556eb8244201a81fff7b246561a677a782b69fa0)
  clang revision 556eb8244201a81fff7b246561a677a782b69fa0
  llvm revision 556eb8244201a81fff7b246561a677a782b69fa0
Setting up remote platform 'remote-linux'

Connecting to remote platform 'remote-linux' at 
'connect://jetson-agx-0086.lab.llvm.org:1234'...

Connected.

Setting remote platform working directory to '/home/ubuntu/lldb-tests'...

Skipping the following test categories: ['lldb-server', 'dsym', 'gmodules', 
'debugserver', 'objc', 'lldb-dap']


--
Command Output (stderr):
--
UNSUPPORTED: LLDB 
(C:\buildbot\as-builder-10\lldb-x-aarch64\build\bin\clang.exe-aarch64) :: 
test_dsym (TestExitDuringStep.ExitDuringStepTestCase.test_dsym) (test case does 
not fall in any category of interest for this run) 

PASS: LLDB 
(C:\buildbot\as-builder-10\lldb-x-aarch64\build\bin\clang.exe-aarch64) :: 
test_dwarf (TestExitDuringStep.ExitDuringStepTestCase.test_dwarf)

PASS: LLDB 
(C:\buildbot\as-builder-10\lldb-x-aarch64\build\bin\clang.exe-aarch64) :: 
test_dwo (TestExitDuringStep.ExitDuringStepTestCase.test_dwo)

UNSUPPORTED: LLDB 
(C:\buildbot\as-builder-10\lldb-x-aarch64\build\bin\clang.exe-aarch64) :: 
test_step_in_dsym (TestExitDuringStep.ExitDuringStepTestCase.test_step_in_dsym) 
(test case does not fall in any category of interest for this run) 

PASS: LLDB 
(C:\buildbot\as-builder-10\lldb-x-aarch64\build\bin\clang.exe-aarch64) :: 
test_step_in_dwarf 
(TestExitDuringStep.ExitDuringStepTestCase.test_step_in_dwarf)

FAIL: LLDB 
(C:\buildbot\as-builder-10\lldb-x-aarch64\build\bin\clang.exe-aarch64) :: 
test_step_in_dwo (TestExitDuringStep.ExitDuringStepTestCase.test_step_in_dwo)

UNSUPPORTED: LLDB 
(C:\buildbot\as-builder-10\lldb-x-aarch64\build\bin\clang.exe-aarch64) :: 
test_step_over_dsym 
(TestExitDuringStep.ExitDuringStepTestCase.test_step_over_dsym) (test case does 
not fall in any category of interest for this run) 

PASS: LLDB 
(C:\buildbot\as-builder-10\lldb-x-aarch64\build\bin\clang.exe-aarch64) :: 
test_step_over_dwarf 
(TestExitDuringStep.ExitDuringStepTestCase.test_step_over_dwarf)

PASS: LLDB 
(C:\buildbot\as-builder-10\lldb-x-aarch64\build\bin\clang.exe-aarch64) :: 
test_step_over_dwo 
(TestExitDuringStep.ExitDuringStepTestCase.test_step_over_dwo)

==

FAIL: test_step_in_dwo 
(TestExitDuringStep.ExitDuringStepTestCase.test_step_in_dwo)

   Test thread exit during step-in handling.

...

```



https://github.com/llvm/llvm-project/pull/128787
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [Clang] Treat constexpr-unknown value as invalid in `EvaluateAsInitializer` (PR #128409)

2025-02-26 Thread Yingwei Zheng via cfe-commits


@@ -17000,6 +16998,18 @@ bool Expr::EvaluateAsInitializer(APValue &Value, const 
ASTContext &Ctx,
 
 if (!Info.discardCleanups())
   llvm_unreachable("Unhandled cleanup; missing full expression marker?");
+
+if (Value.allowConstexprUnknown()) {
+  assert(Value.isLValue() && "Expected an lvalue");
+  auto Base = Value.getLValueBase();
+  const auto *NewVD = Base.dyn_cast();
+  if (!NewVD)
+NewVD = VD;
+  Info.FFDiag(getExprLoc(), diag::note_constexpr_var_init_non_constant, 1)

dtcxzyw wrote:

> If you need more information to generate a good diagnostic, you could pass 
> that information to createConstexprUnknownAPValues, and store it in the 
> APValue itself, I guess. Computing the whole diagnostic in advance seems like 
> it would be too expensive, though.

That is what the current implementation does.


https://github.com/llvm/llvm-project/pull/128409
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [ARM] Introduce -mtp=auto and make it the default (PR #128728)

2025-02-26 Thread Simon Tatham via cfe-commits

statham-arm wrote:

> It is fine to add `fixes https://github.com/llvm/llvm-project/issues/123864` 
> to the Description so that the issue is automatically closed.

Yes, good point! When I suggested an improved description, I left out that 
part, which is the one thing @Zhenhang1213 _didn't_ forget in the original. 
Sorry.

https://github.com/llvm/llvm-project/pull/128728
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] Mark union member destructors referenced (PR #128866)

2025-02-26 Thread Maurice Heumann via cfe-commits

https://github.com/momo5502 updated 
https://github.com/llvm/llvm-project/pull/128866

>From 484ff7a53ab700fda30ee90f739bb2573f41c851 Mon Sep 17 00:00:00 2001
From: Maurice Heumann 
Date: Wed, 26 Feb 2025 08:37:04 +0100
Subject: [PATCH 1/2] Mark union member destructors referenced

---
 clang/lib/Sema/SemaDeclCXX.cpp | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/clang/lib/Sema/SemaDeclCXX.cpp b/clang/lib/Sema/SemaDeclCXX.cpp
index 664d48ccbc382..ce7927dedd96b 100644
--- a/clang/lib/Sema/SemaDeclCXX.cpp
+++ b/clang/lib/Sema/SemaDeclCXX.cpp
@@ -5764,7 +5764,7 @@ 
Sema::MarkBaseAndMemberDestructorsReferenced(SourceLocation Location,
  CXXRecordDecl *ClassDecl) {
   // Ignore dependent contexts. Also ignore unions, since their members never
   // have destructors implicitly called.
-  if (ClassDecl->isDependentContext() || ClassDecl->isUnion())
+  if (ClassDecl->isDependentContext() /*|| ClassDecl->isUnion()*/)
 return;
 
   // FIXME: all the access-control diagnostics are positioned on the
@@ -5793,8 +5793,10 @@ 
Sema::MarkBaseAndMemberDestructorsReferenced(SourceLocation Location,
 if (FieldClassDecl->hasIrrelevantDestructor())
   continue;
 // The destructor for an implicit anonymous union member is never invoked.
-if (FieldClassDecl->isUnion() && 
FieldClassDecl->isAnonymousStructOrUnion())
+if (FieldClassDecl->isUnion() && 
FieldClassDecl->isAnonymousStructOrUnion()) {
+  MarkBaseAndMemberDestructorsReferenced(Location, FieldClassDecl);
   continue;
+}
 
 CXXDestructorDecl *Dtor = LookupDestructor(FieldClassDecl);
 // Dtor might still be missing, e.g because it's invalid.

>From 448d01dc91a4cb79250efd43f52da5caa18ed6b5 Mon Sep 17 00:00:00 2001
From: Maurice Heumann 
Date: Wed, 26 Feb 2025 14:31:47 +0100
Subject: [PATCH 2/2] Only instantiate destructors via a constructor

---
 clang/include/clang/Sema/Sema.h | 2 +-
 clang/lib/Sema/SemaDecl.cpp | 2 +-
 clang/lib/Sema/SemaDeclCXX.cpp  | 8 
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/clang/include/clang/Sema/Sema.h b/clang/include/clang/Sema/Sema.h
index 476abe86cb2d2..c2e6006c06a77 100644
--- a/clang/include/clang/Sema/Sema.h
+++ b/clang/include/clang/Sema/Sema.h
@@ -5430,7 +5430,7 @@ class Sema final : public SemaBase {
   /// mark all the non-trivial destructors of its members and bases as
   /// referenced.
   void MarkBaseAndMemberDestructorsReferenced(SourceLocation Loc,
-  CXXRecordDecl *Record);
+  CXXRecordDecl *Record, bool 
AllowUnionMembers);
 
   /// Mark destructors of virtual bases of this class referenced. In the 
Itanium
   /// C++ ABI, this is done when emitting a destructor for any non-abstract
diff --git a/clang/lib/Sema/SemaDecl.cpp b/clang/lib/Sema/SemaDecl.cpp
index 285bd27a35a76..d546acb238583 100644
--- a/clang/lib/Sema/SemaDecl.cpp
+++ b/clang/lib/Sema/SemaDecl.cpp
@@ -16464,7 +16464,7 @@ Decl *Sema::ActOnFinishFunctionBody(Decl *dcl, Stmt 
*Body,
   CheckDestructor(Destructor);
 
 MarkBaseAndMemberDestructorsReferenced(Destructor->getLocation(),
-   Destructor->getParent());
+   Destructor->getParent(), false);
   }
 
   // If any errors have occurred, clear out any temporaries that may have
diff --git a/clang/lib/Sema/SemaDeclCXX.cpp b/clang/lib/Sema/SemaDeclCXX.cpp
index ce7927dedd96b..a9f17f1981b33 100644
--- a/clang/lib/Sema/SemaDeclCXX.cpp
+++ b/clang/lib/Sema/SemaDeclCXX.cpp
@@ -5454,7 +5454,7 @@ bool Sema::SetCtorInitializers(CXXConstructorDecl 
*Constructor, bool AnyErrors,
 // Constructors implicitly reference the base and member
 // destructors.
 MarkBaseAndMemberDestructorsReferenced(Constructor->getLocation(),
-   Constructor->getParent());
+   Constructor->getParent(), true);
   }
 
   return HadError;
@@ -5761,7 +5761,7 @@ void Sema::ActOnMemInitializers(Decl *ConstructorDecl,
 
 void
 Sema::MarkBaseAndMemberDestructorsReferenced(SourceLocation Location,
- CXXRecordDecl *ClassDecl) {
+ CXXRecordDecl *ClassDecl, bool 
AllowUnionMembers) {
   // Ignore dependent contexts. Also ignore unions, since their members never
   // have destructors implicitly called.
   if (ClassDecl->isDependentContext() /*|| ClassDecl->isUnion()*/)
@@ -5794,7 +5794,7 @@ 
Sema::MarkBaseAndMemberDestructorsReferenced(SourceLocation Location,
   continue;
 // The destructor for an implicit anonymous union member is never invoked.
 if (FieldClassDecl->isUnion() && 
FieldClassDecl->isAnonymousStructOrUnion()) {
-  MarkBaseAndMemberDestructorsReferenced(Location, FieldClassDecl);
+  MarkBaseAndMemberDestructorsR

[clang] [ARM] Introduce -mtp=auto and make it the default (PR #128728)

2025-02-26 Thread Peter Smith via cfe-commits

smithp35 wrote:

A couple of things I forgot to mention:
* Please can you update the in progress ReleaseNotes in 
https://github.com/llvm/llvm-project/blob/main/clang/docs/ReleaseNotes.rst as 
this is a potentially breaking change.
* It is fine to add `fixes https://github.com/llvm/llvm-project/issues/123864` 
to the Description so that the issue is automatically closed.

https://github.com/llvm/llvm-project/pull/128728
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [Clang] Add BuiltinTemplates.td to generate code for builtin templates (PR #123736)

2025-02-26 Thread Erich Keane via cfe-commits

https://github.com/erichkeane approved this pull request.


https://github.com/llvm/llvm-project/pull/123736
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang][CodeGen] Additional fixes for #114062 (PR #128166)

2025-02-26 Thread Alex Voicu via cfe-commits


@@ -2352,6 +2353,22 @@ Value *ScalarExprEmitter::VisitCastExpr(CastExpr *CE) {
 Value *Src = Visit(const_cast(E));
 llvm::Type *SrcTy = Src->getType();
 llvm::Type *DstTy = ConvertType(DestTy);
+
+// FIXME: this is a gross but seemingly necessary workaround for an issue
+// manifesting when a target uses a non-default AS for indirect sret args,
+// but the source HLL is generic, wherein a valid C-cast or 
reinterpret_cast
+// on the address of a local struct that gets returned by value yields an
+// invalid bitcast from the a pointer to the IndirectAS to a pointer to the
+// DefaultAS. We can only do this subversive thing because sret args are
+// manufactured and them residing in the IndirectAS is a target specific
+// detail, and doing an AS cast here still retains the semantics the user
+// expects. It is desirable to remove this iff a better solution is found.
+if (SrcTy != DstTy && isa(Src) &&
+cast(Src)->hasStructRetAttr())

AlexVlx wrote:

> The C++17 thing is slowly but surely spreading to be the canonical way to do 
> this (needs A && A->hasStructRetAttr())

Oh, that's cool to hear, I'll rewrite it then, cheers.

https://github.com/llvm/llvm-project/pull/128166
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang] Update SVE load and store intrinsics to have FP8 variants (PR #126726)

2025-02-26 Thread via cfe-commits


@@ -19,7 +19,7 @@ include "arm_sve_sme_incl.td"
 // Loads

Lukacma wrote:

You missed some intrinsics in here I think: 
 Line 2044: MultiVecLoad class should also support fp8.
Same for MultiVecStore on line 2069


https://github.com/llvm/llvm-project/pull/126726
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] Match .exe on Windows (PR #128894)

2025-02-26 Thread via cfe-commits

llvmbot wrote:




@llvm/pr-subscribers-clang

Author: Chris B (llvm-beanz)


Changes

If you have zlib (not standard) on Windows, this test runs, and it was missing 
a match for the file extension on lld.

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


1 Files Affected:

- (modified) clang/test/Driver/hip-gz-options.hip (+1-1) 


``diff
diff --git a/clang/test/Driver/hip-gz-options.hip 
b/clang/test/Driver/hip-gz-options.hip
index 7425d5fa847b3..bdef24e052ffb 100644
--- a/clang/test/Driver/hip-gz-options.hip
+++ b/clang/test/Driver/hip-gz-options.hip
@@ -9,6 +9,6 @@
 // RUN:   -ggdb -gz=zlib 2>&1 | FileCheck %s
 
 // CHECK-DAG: {{".*clang.*" .* "--compress-debug-sections=zlib"}}
-// CHECK-DAG: {{".*lld" .* "--compress-debug-sections=zlib"}}
+// CHECK-DAG: {{".*lld.*" .* "--compress-debug-sections=zlib"}}
 // CHECK-DAG: {{".*clang.*" .* "--compress-debug-sections=zlib"}}
 // CHECK: "--compress-debug-sections=zlib"

``




https://github.com/llvm/llvm-project/pull/128894
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [Clang][analyzer] replace Stmt* with ConstCFGElementRef in SymbolConjured (PR #128251)

2025-02-26 Thread via cfe-commits


@@ -151,10 +153,13 @@ SValBuilder::getRegionValueSymbolVal(const 
TypedValueRegion *region) {
   return nonloc::SymbolVal(sym);
 }
 
-DefinedOrUnknownSVal SValBuilder::conjureSymbolVal(const void *SymbolTag,
-   const Expr *Ex,
-   const LocationContext *LCtx,
-   unsigned Count) {
+/// When using this overload, the \p elemRef provided must be a \p CFGStmt.
+DefinedOrUnknownSVal
+SValBuilder::conjureSymbolVal(const void *SymbolTag,
+  const CFGBlock::ConstCFGElementRef elemRef,
+  const LocationContext *LCtx, unsigned Count) {
+  const Expr *Ex = cast(elemRef->getAs()->getStmt());

isuckatcs wrote:

```suggestion
  const Expr *Ex = dyn_cast(elemRef->getAs()->getStmt());
```

https://github.com/llvm/llvm-project/pull/128251
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [ARM] Introduce -mtp=auto and make it the default (PR #128728)

2025-02-26 Thread via cfe-commits

https://github.com/Zhenhang1213 updated 
https://github.com/llvm/llvm-project/pull/128728

>From 019e9432080f21ceef3c5fa0465705c090ead33a Mon Sep 17 00:00:00 2001
From: Austin 
Date: Tue, 25 Feb 2025 01:24:24 +0800
Subject: [PATCH] [ARM] Introduce -mtp=auto and make it the default

This adds a new value auto to the possible values of the existing -mtp= clang 
option which controls how the thread pointer is found. auto means the same as 
soft if the target architecture doesn't support a hardware thread pointer at 
all; otherwise it means the same as cp15.

This behavior is the default in gcc version 7.3.0 and later. The new auto 
option is therefore also the default in clang, so this change aligns clang with 
gcc.
---
 clang/include/clang/Driver/Options.td| 2 +-
 clang/lib/Driver/ToolChains/Arch/ARM.cpp | 6 +-
 clang/lib/Driver/ToolChains/Arch/ARM.h   | 1 +
 clang/test/Driver/arm-thread-pointer.c   | 6 +-
 4 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index e521cbf678d93..2bd6076bea5d4 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -4711,7 +4711,7 @@ def mexecute_only : Flag<["-"], "mexecute-only">, 
Group,
 def mno_execute_only : Flag<["-"], "mno-execute-only">, 
Group,
   HelpText<"Allow generation of data access to code sections (ARM only)">;
 let Flags = [TargetSpecific] in {
-def mtp_mode_EQ : Joined<["-"], "mtp=">, Group, 
Values<"soft,cp15,tpidrurw,tpidruro,tpidrprw,el0,el1,el2,el3,tpidr_el0,tpidr_el1,tpidr_el2,tpidr_el3,tpidrro_el0">,
+def mtp_mode_EQ : Joined<["-"], "mtp=">, Group, 
Values<"soft,cp15,tpidrurw,tpidruro,tpidrprw,el0,el1,el2,el3,tpidr_el0,tpidr_el1,tpidr_el2,tpidr_el3,tpidrro_el0,auto">,
   HelpText<"Thread pointer access method. "
"For AArch32: 'soft' uses a function call, or 'tpidrurw', 
'tpidruro' or 'tpidrprw' use the three CP15 registers. 'cp15' is an alias for 
'tpidruro'. "
"For AArch64: 'tpidr_el0', 'tpidr_el1', 'tpidr_el2', 'tpidr_el3' or 
'tpidrro_el0' use the five system registers. 'elN' is an alias for 
'tpidr_elN'.">;
diff --git a/clang/lib/Driver/ToolChains/Arch/ARM.cpp 
b/clang/lib/Driver/ToolChains/Arch/ARM.cpp
index 3aee540d501be..ec0be8f9dc587 100644
--- a/clang/lib/Driver/ToolChains/Arch/ARM.cpp
+++ b/clang/lib/Driver/ToolChains/Arch/ARM.cpp
@@ -223,6 +223,7 @@ arm::ReadTPMode arm::getReadTPMode(const Driver &D, const 
ArgList &Args,
 .Case("tpidruro", ReadTPMode::TPIDRURO)
 .Case("tpidrprw", ReadTPMode::TPIDRPRW)
 .Case("soft", ReadTPMode::Soft)
+.Case("auto", ReadTPMode::Auto)
 .Default(ReadTPMode::Invalid);
 if ((ThreadPointer == ReadTPMode::TPIDRURW ||
  ThreadPointer == ReadTPMode::TPIDRURO ||
@@ -239,7 +240,7 @@ arm::ReadTPMode arm::getReadTPMode(const Driver &D, const 
ArgList &Args,
   D.Diag(diag::err_drv_invalid_mtp) << A->getAsString(Args);
 return ReadTPMode::Invalid;
   }
-  return ReadTPMode::Soft;
+  return ReadTPMode::Auto;
 }
 
 void arm::setArchNameInTriple(const Driver &D, const ArgList &Args,
@@ -580,6 +581,9 @@ llvm::ARM::FPUKind arm::getARMTargetFeatures(const Driver 
&D,
 Features.push_back("+read-tp-tpidruro");
   if (getReadTPMode(D, Args, Triple, ForAS) == ReadTPMode::TPIDRPRW)
 Features.push_back("+read-tp-tpidrprw");
+  if (getReadTPMode(D, Args, Triple, ForAS) == ReadTPMode::Auto &&
+  isHardTPSupported(Triple) && !ForAS)
+Features.push_back("+read-tp-tpidruro");
 
   const Arg *ArchArg = Args.getLastArg(options::OPT_march_EQ);
   const Arg *CPUArg = Args.getLastArg(options::OPT_mcpu_EQ);
diff --git a/clang/lib/Driver/ToolChains/Arch/ARM.h 
b/clang/lib/Driver/ToolChains/Arch/ARM.h
index a23a8793a89e2..622383cf0025d 100644
--- a/clang/lib/Driver/ToolChains/Arch/ARM.h
+++ b/clang/lib/Driver/ToolChains/Arch/ARM.h
@@ -41,6 +41,7 @@ enum class ReadTPMode {
   TPIDRURW,
   TPIDRURO,
   TPIDRPRW,
+  Auto,
 };
 
 enum class FloatABI {
diff --git a/clang/test/Driver/arm-thread-pointer.c 
b/clang/test/Driver/arm-thread-pointer.c
index 5521e1865b276..985c5046f6d26 100644
--- a/clang/test/Driver/arm-thread-pointer.c
+++ b/clang/test/Driver/arm-thread-pointer.c
@@ -42,4 +42,8 @@
 
 // RUN: %clang --target=armv7-linux -### -S %s 2>&1 | \
 // RUN: FileCheck -check-prefix=ARMv7_THREAD_POINTER_NON %s
-// ARMv7_THREAD_POINTER_NON-NOT: "-target-feature" "+read-tp-tpidruro"
+// ARMv7_THREAD_POINTER_NON: "-target-feature" "+read-tp-tpidruro"
+
+// RUN: %clang --target=armv7-linux -mtp=auto -### -S %s 2>&1 | \
+// RUN: FileCheck -check-prefix=ARMv7_THREAD_POINTER_Auto %s
+// ARMv7_THREAD_POINTER_Auto: "-target-feature" "+read-tp-tpidruro"

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [lld] [llvm] Integrated Distributed ThinLTO (DTLTO): Initial support (PR #126654)

2025-02-26 Thread via cfe-commits

https://github.com/bd1976bris edited 
https://github.com/llvm/llvm-project/pull/126654
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [llvm] [RISCV][MC] Add assembler support for XRivosVisni (PR #128773)

2025-02-26 Thread Philip Reames via cfe-commits

https://github.com/preames updated 
https://github.com/llvm/llvm-project/pull/128773

>From 7eab3c685c23c477cbeb3df13fb9e01eacf2378c Mon Sep 17 00:00:00 2001
From: Philip Reames 
Date: Tue, 25 Feb 2025 11:16:41 -0800
Subject: [PATCH 1/3] [RISCV][MC] Add assembler support for XRivosVisni

This implements assembler support for the XRivosVisni custom/vendor
extension from Rivos Inc. which is defined in:
https://github.com/rivosinc/rivos-custom-extensions (See
src/xrivosvisni.adoc)

Codegen support will follow in a separate change.
---
 .../Driver/print-supported-extensions-riscv.c |  1 +
 llvm/docs/RISCVUsage.rst  |  3 +
 .../RISCV/Disassembler/RISCVDisassembler.cpp  |  9 ++-
 llvm/lib/Target/RISCV/RISCVFeatures.td|  7 ++
 llvm/lib/Target/RISCV/RISCVInstrInfoXRivos.td | 64 +++
 llvm/test/MC/RISCV/xrivosvisni-valid.s| 40 
 .../TargetParser/RISCVISAInfoTest.cpp |  1 +
 7 files changed, 122 insertions(+), 3 deletions(-)
 create mode 100644 llvm/test/MC/RISCV/xrivosvisni-valid.s

diff --git a/clang/test/Driver/print-supported-extensions-riscv.c 
b/clang/test/Driver/print-supported-extensions-riscv.c
index fcd820464e2d1..fbb86d39f4df1 100644
--- a/clang/test/Driver/print-supported-extensions-riscv.c
+++ b/clang/test/Driver/print-supported-extensions-riscv.c
@@ -204,6 +204,7 @@
 // CHECK-NEXT: xqcilo   0.2   'Xqcilo' (Qualcomm uC Large 
Offset Load Store Extension)
 // CHECK-NEXT: xqcilsm  0.2   'Xqcilsm' (Qualcomm uC Load 
Store Multiple Extension)
 // CHECK-NEXT: xqcisls  0.2   'Xqcisls' (Qualcomm uC 
Scaled Load Store Extension)
+// CHECK-NEXT: xrivosvisni  0.1   'XRivosVisni' (Rivos Vector 
Small Integer New)
 // CHECK-NEXT: xrivosvizip  0.1   'XRivosVizip' (Rivos Vector 
Register Zips)
 // CHECK-EMPTY:
 // CHECK-NEXT: Supported Profiles
diff --git a/llvm/docs/RISCVUsage.rst b/llvm/docs/RISCVUsage.rst
index 051eaf6999edb..d368ec4809838 100644
--- a/llvm/docs/RISCVUsage.rst
+++ b/llvm/docs/RISCVUsage.rst
@@ -468,6 +468,9 @@ The current vendor extensions supported are:
 ``Xmipslsp``
   LLVM implements load/store pair instructions for the `p8700 processor 
` by MIPS.
 
+``experimental-XRivosVisni``
+  LLVM implements `version 0.1 of the Rivos Vector Integer Small New 
Instructions extension specification 
`__.
+
 ``experimental-XRivosVizip``
   LLVM implements `version 0.1 of the Rivos Vector Register Zips extension 
specification `__.
 
diff --git a/llvm/lib/Target/RISCV/Disassembler/RISCVDisassembler.cpp 
b/llvm/lib/Target/RISCV/Disassembler/RISCVDisassembler.cpp
index 1025b57369f4a..bd26254d89af0 100644
--- a/llvm/lib/Target/RISCV/Disassembler/RISCVDisassembler.cpp
+++ b/llvm/lib/Target/RISCV/Disassembler/RISCVDisassembler.cpp
@@ -622,6 +622,10 @@ void RISCVDisassembler::addSPOperands(MCInst &MI) const {
 #define TRY_TO_DECODE_FEATURE_ANY(FEATURES, DECODER_TABLE, DESC)   
\
   TRY_TO_DECODE((STI.getFeatureBits() & (FEATURES)).any(), DECODER_TABLE, DESC)
 
+static constexpr FeatureBitset XRivosFeatureGroup = {
+RISCV::FeatureVendorXRivosVisni, RISCV::FeatureVendorXRivosVizip,
+};
+
 static constexpr FeatureBitset XqciFeatureGroup = {
 RISCV::FeatureVendorXqcia,   RISCV::FeatureVendorXqciac,
 RISCV::FeatureVendorXqcicli, RISCV::FeatureVendorXqcicm,
@@ -717,12 +721,11 @@ DecodeStatus RISCVDisassembler::getInstruction32(MCInst 
&MI, uint64_t &Size,
 "CORE-V SIMD extensions");
   TRY_TO_DECODE_FEATURE(RISCV::FeatureVendorXCVbi, DecoderTableXCVbi32,
 "CORE-V Immediate Branching");
-
   TRY_TO_DECODE_FEATURE_ANY(XqciFeatureGroup, DecoderTableXqci32,
 "Qualcomm uC Extensions");
 
-  TRY_TO_DECODE_FEATURE(RISCV::FeatureVendorXRivosVizip, DecoderTableXRivos32,
-"Rivos");
+  TRY_TO_DECODE_FEATURE_ANY(XRivosFeatureGroup, DecoderTableXRivos32,
+"Rivos");
 
   TRY_TO_DECODE(true, DecoderTable32, "RISCV32");
 
diff --git a/llvm/lib/Target/RISCV/RISCVFeatures.td 
b/llvm/lib/Target/RISCV/RISCVFeatures.td
index 1a93371a4d92f..1a11da9f97261 100644
--- a/llvm/lib/Target/RISCV/RISCVFeatures.td
+++ b/llvm/lib/Target/RISCV/RISCVFeatures.td
@@ -1376,6 +1376,13 @@ def HasVendorXqcilo
 
 // Rivos Extension(s)
 
+def FeatureVendorXRivosVisni
+:  RISCVExperimentalExtension<0, 1, "Rivos Vector Small Integer New">;
+def HasVendorXRivosVisni
+: Predicate<"Subtarget->hasVendorXRivosVisni()">,
+  AssemblerPredicate<(all_of FeatureVendorXRivosVisni),
+ "'XRivosVizisni' (Rivos Vector Small Integer New)">;
+
 def FeatureVendorXRivosVizip
 :  RISCVExperimentalExtension<0, 1, "Rivos Vector Register Zips">;
 def HasVendorXRivosVizip
diff --git a/llvm/li

[clang] Match .exe on Windows (PR #128894)

2025-02-26 Thread Chris B via cfe-commits

https://github.com/llvm-beanz created 
https://github.com/llvm/llvm-project/pull/128894

If you have zlib (not standard) on Windows, this test runs, and it was missing 
a match for the file extension on lld.

>From da4f0de19daaed0a30b3dfe985e6920e89a07c7d Mon Sep 17 00:00:00 2001
From: Chris B 
Date: Wed, 26 Feb 2025 09:44:47 -0600
Subject: [PATCH] Match .exe on Windows

If you have zlib (not standard) on Windows, this test runs, and it was
missing a match for the file extension on lld.
---
 clang/test/Driver/hip-gz-options.hip | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/clang/test/Driver/hip-gz-options.hip 
b/clang/test/Driver/hip-gz-options.hip
index 7425d5fa847b3..bdef24e052ffb 100644
--- a/clang/test/Driver/hip-gz-options.hip
+++ b/clang/test/Driver/hip-gz-options.hip
@@ -9,6 +9,6 @@
 // RUN:   -ggdb -gz=zlib 2>&1 | FileCheck %s
 
 // CHECK-DAG: {{".*clang.*" .* "--compress-debug-sections=zlib"}}
-// CHECK-DAG: {{".*lld" .* "--compress-debug-sections=zlib"}}
+// CHECK-DAG: {{".*lld.*" .* "--compress-debug-sections=zlib"}}
 // CHECK-DAG: {{".*clang.*" .* "--compress-debug-sections=zlib"}}
 // CHECK: "--compress-debug-sections=zlib"

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [Clang][analyzer] replace Stmt* with ConstCFGElementRef in SymbolConjured (PR #128251)

2025-02-26 Thread via cfe-commits


@@ -93,9 +76,8 @@ ProgramStateRef getWidenedLoopState(ProgramStateRef PrevState,
  RegionAndSymbolInvalidationTraits::TK_PreserveContents);
   }
 
-  return PrevState->invalidateRegions(Regions, getLoopCondition(LoopStmt),
-  BlockCount, LCtx, true, nullptr, nullptr,
-  &ITraits);
+  return PrevState->invalidateRegions(Regions, ElemRef, BlockCount, LCtx, true,

isuckatcs wrote:

Does `ElemRef` point to the loop condition?

https://github.com/llvm/llvm-project/pull/128251
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [Clang][analyzer] replace Stmt* with ConstCFGElementRef in SymbolConjured (PR #128251)

2025-02-26 Thread via cfe-commits


@@ -695,6 +695,21 @@ class CFGBlock {
 void dump() const {
   dumpToStream(llvm::errs());
 }
+
+void Profile(llvm::FoldingSetNodeID &ID) const {
+  ID.AddPointer(Parent);
+  ID.AddInteger(Index);
+}
+
+int64_t getID() const {

isuckatcs wrote:

IIUC, this ID is only used when dumping a conjured symbol. How about removing 
it completely?

https://github.com/llvm/llvm-project/pull/128251
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [Clang][analyzer] replace Stmt* with ConstCFGElementRef in SymbolConjured (PR #128251)

2025-02-26 Thread via cfe-commits


@@ -29,6 +31,18 @@ class SValExplainer : public FullSValVisitor {
   ASTContext &ACtx;
   ProgramStateRef State;
 
+  std::string printCFGElementRef(const CFGBlock::ConstCFGElementRef ElemRef) {
+std::string Str;
+llvm::raw_string_ostream OS(Str);
+ElemRef->dumpToStream(OS);
+// HACK: `CFGBlock::ConstCFGElementRef::dumpToStream` contains a new line
+// character in the end of the string, we don't want it so we remove it 
here.
+while (!Str.empty() && std::isspace(Str.back())) {

isuckatcs wrote:

`std::isspace` is dependant on the local, so I would advise against using it.

Also don't we have a builtin `trim()` function in LLVM, which can be used here?

https://github.com/llvm/llvm-project/pull/128251
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [Clang][analyzer] replace Stmt* with ConstCFGElementRef in SymbolConjured (PR #128251)

2025-02-26 Thread via cfe-commits


@@ -165,8 +167,9 @@ void STLAlgorithmModeling::Find(CheckerContext &C, const 
CallExpr *CE,
   // FIXME: Reverse iterators
   Pos = getIteratorPosition(State, Param);
   if (Pos) {
-StateFound = createIteratorPosition(StateFound, RetVal, 
Pos->getContainer(),
-CE, LCtx, C.blockCount());
+StateFound =
+createIteratorPosition(StateFound, RetVal, Pos->getContainer(),
+   C.getCFGElementRef(), LCtx, C.blockCount());

isuckatcs wrote:

Isn't this element ref different from the element ref of `CE`?

https://github.com/llvm/llvm-project/pull/128251
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [Clang][analyzer] replace Stmt* with ConstCFGElementRef in SymbolConjured (PR #128251)

2025-02-26 Thread via cfe-commits

https://github.com/isuckatcs requested changes to this pull request.

Can you please add a testcase with the snippetin the issue that used to crash?

https://github.com/llvm/llvm-project/pull/128251
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [llvm] [RISCV][MC] Add assembler support for XRivosVisni (PR #128773)

2025-02-26 Thread Philip Reames via cfe-commits


@@ -25,3 +65,27 @@ defm RI_VZIP2B_V : VALU_IV_V<"ri.vzip2b", 0b010100>;
 defm RI_VUNZIP2A_V : VALU_IV_V<"ri.vunzip2a", 0b001000>;
 defm RI_VUNZIP2B_V : VALU_IV_V<"ri.vunzip2b", 0b011000>;
 }
+
+//===--===//
+// XRivosVisni
+//===--===//
+
+let Predicates = [HasVendorXRivosVisni], DecoderNamespace = "XRivos",
+  Inst<6-0> = OPC_CUSTOM_2.Value, mayLoad = false, mayStore = false,
+  hasSideEffects = false in {
+
+let isReMaterializable = 1, isAsCheapAsAMove = 1, vm = 0, vs2=0 in
+def RI_VZERO : RVInstV<0b00, 0b0, OPCFG, (outs VR:$vd),
+ (ins), "ri.vzero", "$vd">;

preames wrote:

Fixed, thanks.  I copied this from a downstream change from before we'd 
finalized the naming in that spec.

https://github.com/llvm/llvm-project/pull/128773
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [Clang][analyzer] replace Stmt* with ConstCFGElementRef in SymbolConjured (PR #128251)

2025-02-26 Thread via cfe-commits


@@ -151,10 +153,13 @@ SValBuilder::getRegionValueSymbolVal(const 
TypedValueRegion *region) {
   return nonloc::SymbolVal(sym);
 }
 
-DefinedOrUnknownSVal SValBuilder::conjureSymbolVal(const void *SymbolTag,
-   const Expr *Ex,
-   const LocationContext *LCtx,
-   unsigned Count) {
+/// When using this overload, the \p elemRef provided must be a \p CFGStmt.

isuckatcs wrote:

This is asserted. The comment is not necessary I think.

https://github.com/llvm/llvm-project/pull/128251
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [Clang][analyzer] replace Stmt* with ConstCFGElementRef in SymbolConjured (PR #128251)

2025-02-26 Thread via cfe-commits


@@ -282,8 +284,9 @@ void ContainerModeling::handleEnd(CheckerContext &C, const 
Expr *CE,
   auto State = C.getState();
   auto EndSym = getContainerEnd(State, ContReg);
   if (!EndSym) {
-State = createContainerEnd(State, ContReg, CE, C.getASTContext().LongTy,
-   C.getLocationContext(), C.blockCount());
+State = createContainerEnd(State, ContReg, C.getCFGElementRef(),

isuckatcs wrote:

Here we used to pass `CE`, not `C`. Also, this change makes `CE` an unused 
parameter.

Please try to indentify and remove them all.

https://github.com/llvm/llvm-project/pull/128251
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [Clang][analyzer] replace Stmt* with ConstCFGElementRef in SymbolConjured (PR #128251)

2025-02-26 Thread via cfe-commits

https://github.com/isuckatcs edited 
https://github.com/llvm/llvm-project/pull/128251
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [llvm] [RISCV][MC] Add assembler support for XRivosVisni (PR #128773)

2025-02-26 Thread Philip Reames via cfe-commits


@@ -1376,6 +1376,13 @@ def HasVendorXqcilo
 
 // Rivos Extension(s)
 
+def FeatureVendorXRivosVisni
+:  RISCVExperimentalExtension<0, 1, "Rivos Vector Small Integer New">;
+def HasVendorXRivosVisni
+: Predicate<"Subtarget->hasVendorXRivosVisni()">,
+  AssemblerPredicate<(all_of FeatureVendorXRivosVisni),
+ "'XRivosVizisni' (Rivos Vector Small Integer New)">;

preames wrote:

Fixed both - these were just typos on my part.  Thanks.

https://github.com/llvm/llvm-project/pull/128773
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [llvm] [RISCV][MC] Add assembler support for XRivosVisni (PR #128773)

2025-02-26 Thread Philip Reames via cfe-commits


@@ -10,6 +10,46 @@
 //
 
//===--===//
 
+class RVInstVXI funct6, RISCVVFormat opv, dag outs, dag ins,
+string opcodestr, string argstr>
+: RVInst {
+  bits<5> imm;
+  bits<5> rs1;
+  bits<5> vd;
+  bit vm;
+
+  let Inst{31-26} = funct6;
+  let Inst{25} = vm;
+  let Inst{24-20} = imm;
+  let Inst{19-15} = rs1;
+  let Inst{14-12} = opv.Value;
+  let Inst{11-7} = vd;
+  let Inst{6-0} = OPC_OP_V.Value;

preames wrote:

If you look at the instruction definitions which use these classes, they 
override this.  However, that's maybe a code smell of it's own.  I'd originally 
written these classes modeling RVInst ones, thinking we might have a 
standardized example eventually, and I'd kill off the custom ones.  However, 
since we don't, maybe I should rename and specialize them for the custom user 
here?  

Any preference?  It looks like SiFive specialized the custom ones, and avoided 
the generic sounding naming, so maybe we should do that here?  

https://github.com/llvm/llvm-project/pull/128773
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [Clang][analyzer] replace Stmt* with ConstCFGElementRef in SymbolConjured (PR #128251)

2025-02-26 Thread Fangyi Zhou via cfe-commits


@@ -695,6 +695,21 @@ class CFGBlock {
 void dump() const {
   dumpToStream(llvm::errs());
 }
+
+void Profile(llvm::FoldingSetNodeID &ID) const {
+  ID.AddPointer(Parent);
+  ID.AddInteger(Index);
+}
+
+int64_t getID() const {

fangyi-zhou wrote:

Any suggestion for replacement?

https://github.com/llvm/llvm-project/pull/128251
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] a955426 - [clang][bytecode] Handle UsingDirectiveDecls (#128888)

2025-02-26 Thread via cfe-commits

Author: Timm Baeder
Date: 2025-02-26T16:55:15+01:00
New Revision: a955426a16bcbb9bf05eb0e3894663dff4983b00

URL: 
https://github.com/llvm/llvm-project/commit/a955426a16bcbb9bf05eb0e3894663dff4983b00
DIFF: 
https://github.com/llvm/llvm-project/commit/a955426a16bcbb9bf05eb0e3894663dff4983b00.diff

LOG: [clang][bytecode] Handle UsingDirectiveDecls (#12)

By ignoring them.

Added: 


Modified: 
clang/lib/AST/ByteCode/Compiler.cpp
clang/test/AST/ByteCode/literals.cpp

Removed: 




diff  --git a/clang/lib/AST/ByteCode/Compiler.cpp 
b/clang/lib/AST/ByteCode/Compiler.cpp
index de0ce8b2644d3..4cf6a48edd5e0 100644
--- a/clang/lib/AST/ByteCode/Compiler.cpp
+++ b/clang/lib/AST/ByteCode/Compiler.cpp
@@ -5107,7 +5107,7 @@ template 
 bool Compiler::visitDeclStmt(const DeclStmt *DS) {
   for (const auto *D : DS->decls()) {
 if (isa(D))
+FunctionDecl, NamespaceAliasDecl, UsingDirectiveDecl>(D))
   continue;
 
 const auto *VD = dyn_cast(D);

diff  --git a/clang/test/AST/ByteCode/literals.cpp 
b/clang/test/AST/ByteCode/literals.cpp
index a80ee7ad84fc7..f206f020ecb47 100644
--- a/clang/test/AST/ByteCode/literals.cpp
+++ b/clang/test/AST/ByteCode/literals.cpp
@@ -1330,3 +1330,14 @@ void localConstexpr() {
   static_assert(a == 0, ""); // both-error {{not an integral constant 
expression}} \
  // both-note {{initializer of 'a' is not a 
constant expression}}
 }
+
+namespace Foo {
+  namespace Bar {
+constexpr int FB = 10;
+  }
+}
+constexpr int usingDirectiveDecl() {
+  using namespace Foo::Bar;
+  return FB;
+}
+static_assert(usingDirectiveDecl() == 10, "");



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang][bytecode] Handle UsingDirectiveDecls (PR #128888)

2025-02-26 Thread Timm Baeder via cfe-commits

https://github.com/tbaederr closed 
https://github.com/llvm/llvm-project/pull/12
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [llvm] [CaptureTracking][FunctionAttrs] Add support for CaptureInfo (PR #125880)

2025-02-26 Thread Nikita Popov via cfe-commits

nikic wrote:

Confirmed that check-clang for a two-stage Windows build with ThinLTO works 
with the additional changes on https://github.com/llvm/llvm-project/pull/128020.

https://github.com/llvm/llvm-project/pull/125880
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [Clang][analyzer] replace Stmt* with ConstCFGElementRef in SymbolConjured (PR #128251)

2025-02-26 Thread via cfe-commits


@@ -207,7 +207,7 @@ void InvalidPtrChecker::postPreviousReturnInvalidatingCall(
 
   // Function call will return a pointer to the new symbolic region.
   DefinedOrUnknownSVal RetVal = C.getSValBuilder().conjureSymbolVal(
-  CE, LCtx, CE->getType(), C.blockCount());
+  C.getCFGElementRef(), LCtx, CE->getType(), C.blockCount());

isuckatcs wrote:

Same question here regarding different references.

https://github.com/llvm/llvm-project/pull/128251
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [ARM] Introduce -mtp=auto and make it the default (PR #128728)

2025-02-26 Thread via cfe-commits

https://github.com/Zhenhang1213 closed 
https://github.com/llvm/llvm-project/pull/128728
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] fix kcfi doesn't take effect when callee function has no input parameter (PR #106677)

2025-02-26 Thread via cfe-commits

https://github.com/Zhenhang1213 closed 
https://github.com/llvm/llvm-project/pull/106677
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[libclc] [libclc] Remove clspv-specific clc conversions (PR #128500)

2025-02-26 Thread Romaric Jodin via cfe-commits

rjodinchr wrote:

In fact, I missed that I had to modify some build files in Google infra for 
that change. So it's all good.

Also, would you have a 15min slot in the coming days to talk about all your 
libclc work? 

https://github.com/llvm/llvm-project/pull/128500
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [Clang][analyzer] replace Stmt* with ConstCFGElementRef in SymbolConjured (PR #128251)

2025-02-26 Thread via cfe-commits


@@ -695,6 +695,21 @@ class CFGBlock {
 void dump() const {
   dumpToStream(llvm::errs());
 }
+
+void Profile(llvm::FoldingSetNodeID &ID) const {
+  ID.AddPointer(Parent);
+  ID.AddInteger(Index);
+}
+
+int64_t getID() const {

isuckatcs wrote:

Why do we want to print the ID in the first place? It probably doesn't hold a 
value to our users anyway.

Either print a stament if there is any, or a source location, etc. The CFG is 
essentially the statements in the source file in execution order, so I imagine 
we always have a statement.

https://github.com/llvm/llvm-project/pull/128251
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [verify] Improve the error messages with multiple active prefixes (PR #126068)

2025-02-26 Thread Fangrui Song via cfe-commits

https://github.com/MaskRay approved this pull request.


https://github.com/llvm/llvm-project/pull/126068
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang-tools-extra] [clang-tidy] Fix performance-move-const-arg false negative in ternary… (PR #128402)

2025-02-26 Thread David Rivera via cfe-commits

https://github.com/RiverDave updated 
https://github.com/llvm/llvm-project/pull/128402

>From 5eef2a52de7de53b0fb24781f40a7b02b55025b9 Mon Sep 17 00:00:00 2001
From: Riverdave 
Date: Sat, 22 Feb 2025 03:57:35 -0500
Subject: [PATCH] [clang-tidy] Fix performance-move-const-arg false negative in
 ternary operators

---
 .../performance/MoveConstArgCheck.cpp | 11 +++--
 clang-tools-extra/docs/ReleaseNotes.rst   |  4 
 .../checkers/performance/move-const-arg.cpp   | 23 +++
 3 files changed, 36 insertions(+), 2 deletions(-)

diff --git a/clang-tools-extra/clang-tidy/performance/MoveConstArgCheck.cpp 
b/clang-tools-extra/clang-tidy/performance/MoveConstArgCheck.cpp
index 421ce003975bc..553c1d20cbf1d 100644
--- a/clang-tools-extra/clang-tidy/performance/MoveConstArgCheck.cpp
+++ b/clang-tools-extra/clang-tidy/performance/MoveConstArgCheck.cpp
@@ -44,6 +44,10 @@ void MoveConstArgCheck::registerMatchers(MatchFinder 
*Finder) {
unless(isInTemplateInstantiation()))
   .bind("call-move");
 
+  // Match ternary expressions where either branch contains std::move
+  auto TernaryWithMoveMatcher =
+  conditionalOperator(hasDescendant(MoveCallMatcher));
+
   Finder->addMatcher(
   expr(anyOf(
   castExpr(hasSourceExpression(MoveCallMatcher)),
@@ -58,13 +62,16 @@ void MoveConstArgCheck::registerMatchers(MatchFinder 
*Finder) {
   qualType(rValueReferenceType()).bind("invocation-parm-type");
   // Matches respective ParmVarDecl for a CallExpr or CXXConstructExpr.
   auto ArgumentWithParamMatcher = forEachArgumentWithParam(
-  MoveCallMatcher, parmVarDecl(anyOf(hasType(ConstTypeParmMatcher),
+  anyOf(MoveCallMatcher, TernaryWithMoveMatcher),
+  parmVarDecl(anyOf(hasType(ConstTypeParmMatcher),
  hasType(RValueTypeParmMatcher)))
.bind("invocation-parm"));
   // Matches respective types of arguments for a CallExpr or CXXConstructExpr
   // and it works on calls through function pointers as well.
   auto ArgumentWithParamTypeMatcher = forEachArgumentWithParamType(
-  MoveCallMatcher, anyOf(ConstTypeParmMatcher, RValueTypeParmMatcher));
+  anyOf(MoveCallMatcher, TernaryWithMoveMatcher),
+  anyOf(ConstTypeParmMatcher, RValueTypeParmMatcher));
+
 
   Finder->addMatcher(
   invocation(anyOf(ArgumentWithParamMatcher, ArgumentWithParamTypeMatcher))
diff --git a/clang-tools-extra/docs/ReleaseNotes.rst 
b/clang-tools-extra/docs/ReleaseNotes.rst
index 41ff1c1016f25..2eb65d61f5e78 100644
--- a/clang-tools-extra/docs/ReleaseNotes.rst
+++ b/clang-tools-extra/docs/ReleaseNotes.rst
@@ -115,6 +115,10 @@ Changes in existing checks
   ` check by providing additional
   examples and fixing some macro related false positives.
 
+- Improved :doc:`performance-move-const-arg
+  ` check by fixing false 
negatives
+  on ternary operators calling ``std::move``.
+
 Removed checks
 ^^
 
diff --git 
a/clang-tools-extra/test/clang-tidy/checkers/performance/move-const-arg.cpp 
b/clang-tools-extra/test/clang-tidy/checkers/performance/move-const-arg.cpp
index 8e325b0ae6ca3..e616cbe78bc3a 100644
--- a/clang-tools-extra/test/clang-tidy/checkers/performance/move-const-arg.cpp
+++ b/clang-tools-extra/test/clang-tidy/checkers/performance/move-const-arg.cpp
@@ -560,3 +560,26 @@ struct Result {
   // CHECK-MESSAGES: :[[@LINE-1]]:{{[0-9]+}}: warning: passing result of 
std::move() as a const reference argument; no move will actually happen 
[performance-move-const-arg]
 };
 } // namespace GH111450
+
+namespace GH126515 {
+
+struct TernaryMoveCall {
+TernaryMoveCall();
+TernaryMoveCall(const TernaryMoveCall&);
+TernaryMoveCall operator=(const TernaryMoveCall&);
+
+void TernaryCheckTriviallyCopyable(const char * c) {}
+
+void testTernaryMove() {
+  TernaryMoveCall t1;
+  TernaryMoveCall other(false ? TernaryMoveCall() : 
TernaryMoveCall(std::move(t1)) );
+  // CHECK-MESSAGES: :[[@LINE-1]]:69: warning: passing result of std::move() 
as a const reference argument; no move will actually happen 
[performance-move-const-arg]
+  // CHECK-MESSAGES: :[[@LINE-11]]:8: note: 'TernaryMoveCall' is not move 
assignable/constructible
+
+  const char* a = "a";
+  TernaryCheckTriviallyCopyable(true ? std::move(a) : "" );
+  // CHECK-MESSAGES: :[[@LINE-1]]:40: warning: std::move of the variable 'a' 
of the trivially-copyable type 'const char *' has no effect; remove std::move() 
[performance-move-const-arg]
+}
+
+};
+} // namespace GH126515

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 8039f8e - [RISCV][MC] Add assembler support for XRivosVisni (#128773)

2025-02-26 Thread via cfe-commits

Author: Philip Reames
Date: 2025-02-26T08:55:35-08:00
New Revision: 8039f8e139aa52561d3482d61328fe7f370056e7

URL: 
https://github.com/llvm/llvm-project/commit/8039f8e139aa52561d3482d61328fe7f370056e7
DIFF: 
https://github.com/llvm/llvm-project/commit/8039f8e139aa52561d3482d61328fe7f370056e7.diff

LOG: [RISCV][MC] Add assembler support for XRivosVisni (#128773)

This implements assembler support for the XRivosVisni custom/vendor
extension from Rivos Inc. which is defined in:
https://github.com/rivosinc/rivos-custom-extensions (See
src/xrivosvisni.adoc)

Codegen support will follow in separate changes.

Added: 
llvm/test/MC/RISCV/xrivosvisni-valid.s

Modified: 
clang/test/Driver/print-supported-extensions-riscv.c
llvm/docs/RISCVUsage.rst
llvm/lib/Target/RISCV/Disassembler/RISCVDisassembler.cpp
llvm/lib/Target/RISCV/RISCVFeatures.td
llvm/lib/Target/RISCV/RISCVInstrInfoXRivos.td
llvm/unittests/TargetParser/RISCVISAInfoTest.cpp

Removed: 




diff  --git a/clang/test/Driver/print-supported-extensions-riscv.c 
b/clang/test/Driver/print-supported-extensions-riscv.c
index e0f917d30b979..40f4ee8d2c89a 100644
--- a/clang/test/Driver/print-supported-extensions-riscv.c
+++ b/clang/test/Driver/print-supported-extensions-riscv.c
@@ -204,6 +204,7 @@
 // CHECK-NEXT: xqcilo   0.2   'Xqcilo' (Qualcomm uC Large 
Offset Load Store Extension)
 // CHECK-NEXT: xqcilsm  0.2   'Xqcilsm' (Qualcomm uC Load 
Store Multiple Extension)
 // CHECK-NEXT: xqcisls  0.2   'Xqcisls' (Qualcomm uC 
Scaled Load Store Extension)
+// CHECK-NEXT: xrivosvisni  0.1   'XRivosVisni' (Rivos Vector 
Integer Small New)
 // CHECK-NEXT: xrivosvizip  0.1   'XRivosVizip' (Rivos Vector 
Register Zips)
 // CHECK-EMPTY:
 // CHECK-NEXT: Supported Profiles

diff  --git a/llvm/docs/RISCVUsage.rst b/llvm/docs/RISCVUsage.rst
index 46588d983c81c..5229d87c0fa0e 100644
--- a/llvm/docs/RISCVUsage.rst
+++ b/llvm/docs/RISCVUsage.rst
@@ -468,6 +468,9 @@ The current vendor extensions supported are:
 ``Xmipslsp``
   LLVM implements load/store pair instructions for the `p8700 processor 
` by MIPS.
 
+``experimental-XRivosVisni``
+  LLVM implements `version 0.1 of the Rivos Vector Integer Small New 
Instructions extension specification 
`__.
+
 ``experimental-XRivosVizip``
   LLVM implements `version 0.1 of the Rivos Vector Register Zips extension 
specification `__.
 

diff  --git a/llvm/lib/Target/RISCV/Disassembler/RISCVDisassembler.cpp 
b/llvm/lib/Target/RISCV/Disassembler/RISCVDisassembler.cpp
index 9b3104e86a8da..08e0cfee809bc 100644
--- a/llvm/lib/Target/RISCV/Disassembler/RISCVDisassembler.cpp
+++ b/llvm/lib/Target/RISCV/Disassembler/RISCVDisassembler.cpp
@@ -622,6 +622,11 @@ void RISCVDisassembler::addSPOperands(MCInst &MI) const {
 #define TRY_TO_DECODE_FEATURE_ANY(FEATURES, DECODER_TABLE, DESC)   
\
   TRY_TO_DECODE((STI.getFeatureBits() & (FEATURES)).any(), DECODER_TABLE, DESC)
 
+static constexpr FeatureBitset XRivosFeatureGroup = {
+RISCV::FeatureVendorXRivosVisni,
+RISCV::FeatureVendorXRivosVizip,
+};
+
 static constexpr FeatureBitset XqciFeatureGroup = {
 RISCV::FeatureVendorXqcia,   RISCV::FeatureVendorXqciac,
 RISCV::FeatureVendorXqcicli, RISCV::FeatureVendorXqcicm,
@@ -710,12 +715,10 @@ DecodeStatus RISCVDisassembler::getInstruction32(MCInst 
&MI, uint64_t &Size,
 "CORE-V SIMD extensions");
   TRY_TO_DECODE_FEATURE(RISCV::FeatureVendorXCVbi, DecoderTableXCVbi32,
 "CORE-V Immediate Branching");
-
   TRY_TO_DECODE_FEATURE_ANY(XqciFeatureGroup, DecoderTableXqci32,
 "Qualcomm uC Extensions");
 
-  TRY_TO_DECODE_FEATURE(RISCV::FeatureVendorXRivosVizip, DecoderTableXRivos32,
-"Rivos");
+  TRY_TO_DECODE_FEATURE_ANY(XRivosFeatureGroup, DecoderTableXRivos32, "Rivos");
 
   TRY_TO_DECODE(true, DecoderTable32, "RISCV32");
 

diff  --git a/llvm/lib/Target/RISCV/RISCVFeatures.td 
b/llvm/lib/Target/RISCV/RISCVFeatures.td
index b675c5670ceed..a8c36052da2d0 100644
--- a/llvm/lib/Target/RISCV/RISCVFeatures.td
+++ b/llvm/lib/Target/RISCV/RISCVFeatures.td
@@ -1376,6 +1376,13 @@ def HasVendorXqcilo
 
 // Rivos Extension(s)
 
+def FeatureVendorXRivosVisni
+:  RISCVExperimentalExtension<0, 1, "Rivos Vector Integer Small New">;
+def HasVendorXRivosVisni
+: Predicate<"Subtarget->hasVendorXRivosVisni()">,
+  AssemblerPredicate<(all_of FeatureVendorXRivosVisni),
+ "'XRivosVisni' (Rivos Vector Integer Small New)">;
+
 def FeatureVendorXRivosVizip
 :  RISCVExperimentalExtension<0, 1, "Rivos Vector Register Zips">;
 def HasVendorXRivosVizip

diff  --git a/llvm/lib/Target/RIS

[clang] [llvm] [RISCV][MC] Add assembler support for XRivosVisni (PR #128773)

2025-02-26 Thread Philip Reames via cfe-commits

https://github.com/preames closed 
https://github.com/llvm/llvm-project/pull/128773
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [llvm] [RISCV] Add Qualcomm uC Xqcisim (Simulation Hint) extension (PR #128833)

2025-02-26 Thread Craig Topper via cfe-commits


@@ -485,6 +498,43 @@ let hasSideEffects = 0, mayLoad = 0, mayStore = 0 in {
 } // hasSideEffects = 0, mayLoad = 0, mayStore = 0
 } // Predicates = [HasVendorXqcilia, IsRV32]
 
+let Predicates = [HasVendorXqcisim, IsRV32] in {
+let mayLoad = 0, mayStore = 0, hasSideEffects = 1 in {
+  def QC_PSYSCALLI : RVInstI<0b010, OPC_OP_IMM, (outs),
+  (ins uimm10:$imm10), "qc.psyscalli",
+  "$imm10"> {
+bits<10> imm10;
+
+let rs1 = 0;
+let rd = 0;
+let imm12 = {0b00, imm10};
+  }
+
+  def QC_PPUTCI : RVInstI<0b010, OPC_OP_IMM, (outs), (ins uimm8:$imm8),
+   "qc.pputci", "$imm8"> {

topperc wrote:

too much indentation

https://github.com/llvm/llvm-project/pull/128833
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [llvm] [RISCV] Add Qualcomm uC Xqcisim (Simulation Hint) extension (PR #128833)

2025-02-26 Thread Craig Topper via cfe-commits


@@ -485,6 +498,43 @@ let hasSideEffects = 0, mayLoad = 0, mayStore = 0 in {
 } // hasSideEffects = 0, mayLoad = 0, mayStore = 0
 } // Predicates = [HasVendorXqcilia, IsRV32]
 
+let Predicates = [HasVendorXqcisim, IsRV32] in {
+let mayLoad = 0, mayStore = 0, hasSideEffects = 1 in {
+  def QC_PSYSCALLI : RVInstI<0b010, OPC_OP_IMM, (outs),
+  (ins uimm10:$imm10), "qc.psyscalli",

topperc wrote:

too much indentation

https://github.com/llvm/llvm-project/pull/128833
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [llvm] [RISCV] Add Qualcomm uC Xqcisim (Simulation Hint) extension (PR #128833)

2025-02-26 Thread Craig Topper via cfe-commits


@@ -485,6 +498,43 @@ let hasSideEffects = 0, mayLoad = 0, mayStore = 0 in {
 } // hasSideEffects = 0, mayLoad = 0, mayStore = 0
 } // Predicates = [HasVendorXqcilia, IsRV32]
 
+let Predicates = [HasVendorXqcisim, IsRV32] in {
+let mayLoad = 0, mayStore = 0, hasSideEffects = 1 in {
+  def QC_PSYSCALLI : RVInstI<0b010, OPC_OP_IMM, (outs),
+  (ins uimm10:$imm10), "qc.psyscalli",
+  "$imm10"> {
+bits<10> imm10;
+
+let rs1 = 0;
+let rd = 0;
+let imm12 = {0b00, imm10};
+  }
+
+  def QC_PPUTCI : RVInstI<0b010, OPC_OP_IMM, (outs), (ins uimm8:$imm8),
+   "qc.pputci", "$imm8"> {
+bits<8> imm8;
+
+let rs1 = 0;
+let rd = 0;
+let imm12 = {0b0100, imm8};
+  }
+
+  def QC_PCOREDUMP : QCISim_NONE<0b0110, "qc.pcoredump">;
+  def QC_PPREGS : QCISim_NONE<0b0111, "qc.ppregs">;
+  def QC_PPREG : QCISim_RS1<0b1000, "qc.ppreg">;
+  def QC_PPUTC : QCISim_RS1<0b1001, "qc.pputc">;
+  def QC_PPUTS : QCISim_RS1<0b1010, "qc.pputs">;
+  def QC_PEXIT : QCISim_RS1<0b1011, "qc.pexit">;
+  def QC_PSYSCALL : QCISim_RS1<0b1100, "qc.psyscall">;
+
+  def QC_C_PTRACE : RVInst16CI<0b000, 0b10, (outs), (ins), "qc.c.ptrace", ""> {
+let rd = 0;
+let imm = 0;
+let Inst{6-2} = 0;

topperc wrote:

This `Inst{6-2}` line isn't needed. `Inst{6-2}` defaults to `imm{4-0}`. That 
change was made in 6829f30883fa7e71e3b7af022916003a82f0216d so it may have been 
necessary when this was written in your downstream.

https://github.com/llvm/llvm-project/pull/128833
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang modules] Setting `DebugCompilationDir` when it is safe to ignore current working directory (PR #128446)

2025-02-26 Thread Qiongsi Wu via cfe-commits

qiongsiwu wrote:

Ping for review. Thanks so much! 

https://github.com/llvm/llvm-project/pull/128446
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [memprof] Export __memprof_default_options_str on Darwin (PR #128920)

2025-02-26 Thread via cfe-commits

llvmbot wrote:



@llvm/pr-subscribers-clang

@llvm/pr-subscribers-clang-driver

Author: Ellis Hoag (ellishg)


Changes

The `-memprof-runtime-default-options` LLVM flag introduced in 
https://github.com/llvm/llvm-project/pull/118874 creates the 
`__memprof_default_options_str` symbol with `WeakAnyLinkage` on Darwin.

https://github.com/ellishg/llvm-project/blob/fa0202169af23419c4bcbf66eabd1beb6b6e8e34/llvm/lib/Transforms/Instrumentation/MemProfiler.cpp#L573-L576

This ensures Darwin passes `-exported_symbol ___memprof_default_options_str` to 
the linker so that the runtime library has visibility into this symbol.

This will replace the earlier PR 
https://github.com/llvm/llvm-project/pull/128615

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


2 Files Affected:

- (modified) clang/lib/Driver/ToolChains/Darwin.cpp (+4) 
- (modified) clang/test/Driver/fmemprof.cpp (+8) 


``diff
diff --git a/clang/lib/Driver/ToolChains/Darwin.cpp 
b/clang/lib/Driver/ToolChains/Darwin.cpp
index 75f126965e0ac..a2aeef4c4c475 100644
--- a/clang/lib/Driver/ToolChains/Darwin.cpp
+++ b/clang/lib/Driver/ToolChains/Darwin.cpp
@@ -1617,6 +1617,10 @@ void DarwinClang::AddLinkRuntimeLibArgs(const ArgList 
&Args,
 }
   }
 
+  if (Sanitize.needsMemProfRt())
+if (hasExportSymbolDirective(Args))
+  addExportedSymbol(CmdArgs, "___memprof_default_options_str");
+
   const XRayArgs &XRay = getXRayArgs();
   if (XRay.needsXRayRt()) {
 AddLinkRuntimeLib(Args, CmdArgs, "xray");
diff --git a/clang/test/Driver/fmemprof.cpp b/clang/test/Driver/fmemprof.cpp
index 5165c4452fd57..b464320e58a94 100644
--- a/clang/test/Driver/fmemprof.cpp
+++ b/clang/test/Driver/fmemprof.cpp
@@ -17,3 +17,11 @@
 
 // RUN: not %clangxx --target=x86_64-linux-gnu -fprofile-generate 
-fmemory-profile-use=foo %s -### 2>&1 | FileCheck %s 
--check-prefix=CONFLICTWITHPGOINSTR
 // CONFLICTWITHPGOINSTR: error: invalid argument '-fmemory-profile-use=foo' 
not allowed with '-fprofile-generate'
+
+// Test that we export the __memprof_default_options_str on Darwin because it 
has WeakAnyLinkage
+// RUN: %clangxx --target=arm64-apple-ios -fmemory-profile %s -### 2>&1 | 
FileCheck %s -check-prefix=EXPORT-BASE --implicit-check-not=exported_symbol
+// RUN: %clangxx --target=x86_64-linux-gnu -fmemory-profile %s -### 2>&1 | 
FileCheck %s -check-prefix=EXPORT-BASE --implicit-check-not=exported_symbol
+// RUN: %clangxx --target=arm64-apple-ios -fmemory-profile 
-exported_symbols_list /dev/null %s -### 2>&1 | FileCheck %s 
--check-prefixes=EXPORT-BASE,EXPORT
+// FIXME: Darwin needs to link in the runtime, then we can use the regular 
CHECK prefix
+// EXPORT-BASE: "-cc1" {{.*}} "-fmemory-profile"
+// EXPORT: "-exported_symbol" "___memprof_default_options_str"

``




https://github.com/llvm/llvm-project/pull/128920
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [memprof] Export __memprof_default_options_str on Darwin (PR #128920)

2025-02-26 Thread Ellis Hoag via cfe-commits

https://github.com/ellishg created 
https://github.com/llvm/llvm-project/pull/128920

The `-memprof-runtime-default-options` LLVM flag introduced in 
https://github.com/llvm/llvm-project/pull/118874 creates the 
`__memprof_default_options_str` symbol with `WeakAnyLinkage` on Darwin.

https://github.com/ellishg/llvm-project/blob/fa0202169af23419c4bcbf66eabd1beb6b6e8e34/llvm/lib/Transforms/Instrumentation/MemProfiler.cpp#L573-L576

This ensures Darwin passes `-exported_symbol ___memprof_default_options_str` to 
the linker so that the runtime library has visibility into this symbol.

This will replace the earlier PR 
https://github.com/llvm/llvm-project/pull/128615

>From 2e1946730f7ae2473a4fc94f8918eb3d9d225d17 Mon Sep 17 00:00:00 2001
From: Ellis Hoag 
Date: Wed, 26 Feb 2025 09:48:46 -0800
Subject: [PATCH] [memprof] Export __memprof_default_options_str on Darwin

---
 clang/lib/Driver/ToolChains/Darwin.cpp | 4 
 clang/test/Driver/fmemprof.cpp | 8 
 2 files changed, 12 insertions(+)

diff --git a/clang/lib/Driver/ToolChains/Darwin.cpp 
b/clang/lib/Driver/ToolChains/Darwin.cpp
index 75f126965e0ac..a2aeef4c4c475 100644
--- a/clang/lib/Driver/ToolChains/Darwin.cpp
+++ b/clang/lib/Driver/ToolChains/Darwin.cpp
@@ -1617,6 +1617,10 @@ void DarwinClang::AddLinkRuntimeLibArgs(const ArgList 
&Args,
 }
   }
 
+  if (Sanitize.needsMemProfRt())
+if (hasExportSymbolDirective(Args))
+  addExportedSymbol(CmdArgs, "___memprof_default_options_str");
+
   const XRayArgs &XRay = getXRayArgs();
   if (XRay.needsXRayRt()) {
 AddLinkRuntimeLib(Args, CmdArgs, "xray");
diff --git a/clang/test/Driver/fmemprof.cpp b/clang/test/Driver/fmemprof.cpp
index 5165c4452fd57..b464320e58a94 100644
--- a/clang/test/Driver/fmemprof.cpp
+++ b/clang/test/Driver/fmemprof.cpp
@@ -17,3 +17,11 @@
 
 // RUN: not %clangxx --target=x86_64-linux-gnu -fprofile-generate 
-fmemory-profile-use=foo %s -### 2>&1 | FileCheck %s 
--check-prefix=CONFLICTWITHPGOINSTR
 // CONFLICTWITHPGOINSTR: error: invalid argument '-fmemory-profile-use=foo' 
not allowed with '-fprofile-generate'
+
+// Test that we export the __memprof_default_options_str on Darwin because it 
has WeakAnyLinkage
+// RUN: %clangxx --target=arm64-apple-ios -fmemory-profile %s -### 2>&1 | 
FileCheck %s -check-prefix=EXPORT-BASE --implicit-check-not=exported_symbol
+// RUN: %clangxx --target=x86_64-linux-gnu -fmemory-profile %s -### 2>&1 | 
FileCheck %s -check-prefix=EXPORT-BASE --implicit-check-not=exported_symbol
+// RUN: %clangxx --target=arm64-apple-ios -fmemory-profile 
-exported_symbols_list /dev/null %s -### 2>&1 | FileCheck %s 
--check-prefixes=EXPORT-BASE,EXPORT
+// FIXME: Darwin needs to link in the runtime, then we can use the regular 
CHECK prefix
+// EXPORT-BASE: "-cc1" {{.*}} "-fmemory-profile"
+// EXPORT: "-exported_symbol" "___memprof_default_options_str"

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [memprof] Export __memprof_default_options_str on Darwin (PR #128920)

2025-02-26 Thread Ellis Hoag via cfe-commits


@@ -1617,6 +1617,10 @@ void DarwinClang::AddLinkRuntimeLibArgs(const ArgList 
&Args,
 }
   }
 
+  if (Sanitize.needsMemProfRt())
+if (hasExportSymbolDirective(Args))
+  addExportedSymbol(CmdArgs, "___memprof_default_options_str");

ellishg wrote:

@teresajohnson I know you asked for this to be refactored into a constexpr 
string in a header, but I don't think `Darwin.cpp` and `MemProfiler.cpp` share 
any headers in common, so I don't know where I would put it. I don't think I 
can add `MemProfiler.h` to `Darwin.cpp` because it doesn't link in the 
`Instrumentation` component

https://github.com/llvm/llvm-project/pull/128920
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [CUDA][HIP] fix virtual dtor host/device attr (PR #128926)

2025-02-26 Thread via cfe-commits

llvmbot wrote:




@llvm/pr-subscribers-clang

Author: Yaxun (Sam) Liu (yxsamliu)


Changes

Currently if CUDA/HIP users use template class with virtual dtor and 
std::string data member with C++20 and MSVC. When the template class is 
explicitly instantiated, they encounter unresolved symbols in linker.

It was caused by clang inferring host/device attributes for default dtors. 
Since all dtors of member and parent classes have implicit host device attrs, 
clang infers the virtual dtor have implicit host and device attrs. Since 
virtual dtor of explicitly instantiated template class must be emitted, this 
causes constexpr dtor of std::string emitted, which calls a host function which 
was note emitted on device side.

This is a serious issue since it prevents users from using std::string with 
C++20 on Windows.

There are two issues revealed:

1. The deferred diag failed to diagnose calling of host function in host device 
function in device compilation. this can be further divided into two issuse:

1a. the deferred diag visitor does not visit dtor of member
 when visiting dtor, which it should

1b. the deferred diag visitor does not visit dtor of explicit template class 
instantiation, which it should

By fixing this issue, clang will diag the issue in compilation instead of 
linking.

2. When inferring host device attr of virtual dtor of explicit template class 
instantiation, clang should be conservative since it is sure to be emitted. 
Since an implicit host device function may call a host function, clang cannot 
assume it is always available on device. This guarantees dtors that may call 
host functions not to have implicit device attr, therefore will not be emitted 
on device side.

Fixes: https://github.com/llvm/llvm-project/issues/108548

Fixes: SWDEV-517435

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


6 Files Affected:

- (modified) clang/docs/HIPSupport.rst (+20) 
- (modified) clang/include/clang/Sema/Sema.h (+1-1) 
- (modified) clang/lib/Sema/Sema.cpp (+58) 
- (modified) clang/lib/Sema/SemaCUDA.cpp (+21-2) 
- (modified) clang/lib/Sema/SemaDecl.cpp (+15) 
- (added) clang/test/SemaCUDA/dtor.cu (+104) 


``diff
diff --git a/clang/docs/HIPSupport.rst b/clang/docs/HIPSupport.rst
index 481ed39230813..8f473c21e1918 100644
--- a/clang/docs/HIPSupport.rst
+++ b/clang/docs/HIPSupport.rst
@@ -286,6 +286,26 @@ Example Usage
   basePtr->virtualFunction(); // Allowed since obj is constructed in 
device code
}
 
+Host and Device Attributes of Default Destructors
+===
+
+If a default destructor does not have explicit host or device attributes,
+clang infers these attributes based on the destructors of its data members
+and base classes. If any conflicts are detected among these destructors,
+clang diagnoses the issue. Otherwise, clang adds an implicit host or device
+attribute according to whether the data members's and base classes's
+destructors can execute on the host or device side.
+
+For explicit template classes with virtual destructors, which must be emitted,
+the inference adopts a conservative approach. In this case, implicit host or
+device attributes from member and base class destructors are ignored. This
+precaution is necessary because, although a constexpr destructor carries
+implicit host or device attributes, a constexpr function may call a
+non-constexpr function, which is by default a host function.
+
+Users can override the inferred host and device attributes of default
+destructors by adding explicit host and device attributes to them.
+
 C++ Standard Parallelism Offload Support: Compiler And Runtime
 ==
 
diff --git a/clang/include/clang/Sema/Sema.h b/clang/include/clang/Sema/Sema.h
index ebdbc69384efb..3b2be86a88e82 100644
--- a/clang/include/clang/Sema/Sema.h
+++ b/clang/include/clang/Sema/Sema.h
@@ -4392,11 +4392,11 @@ class Sema final : public SemaBase {
   // Whether the callee should be ignored in CUDA/HIP/OpenMP host/device check.
   bool shouldIgnoreInHostDeviceCheck(FunctionDecl *Callee);
 
-private:
   /// Function or variable declarations to be checked for whether the deferred
   /// diagnostics should be emitted.
   llvm::SmallSetVector DeclsToCheckForDeferredDiags;
 
+private:
   /// Map of current shadowing declarations to shadowed declarations. Warn if
   /// it looks like the user is trying to modify the shadowing declaration.
   llvm::DenseMap ShadowingDecls;
diff --git a/clang/lib/Sema/Sema.cpp b/clang/lib/Sema/Sema.cpp
index c699e92985156..fa9e6db62a3a0 100644
--- a/clang/lib/Sema/Sema.cpp
+++ b/clang/lib/Sema/Sema.cpp
@@ -1798,6 +1798,62 @@ class DeferredDiagnosticsEmitter
   Inherited::visitUsedDecl(Loc, D);
   }
 
+  // Visitor member and parent dtors called by this dtor.
+  void VisitCalledDestructors(CXXDestructorDecl *DD) {
+const CXXRecordDecl *RD = DD->getParent();
+
+// Visit the dtors of all member

[clang] [CUDA][HIP] fix virtual dtor host/device attr (PR #128926)

2025-02-26 Thread Yaxun Liu via cfe-commits

https://github.com/yxsamliu created 
https://github.com/llvm/llvm-project/pull/128926

Currently if CUDA/HIP users use template class with virtual dtor and 
std::string data member with C++20 and MSVC. When the template class is 
explicitly instantiated, they encounter unresolved symbols in linker.

It was caused by clang inferring host/device attributes for default dtors. 
Since all dtors of member and parent classes have implicit host device attrs, 
clang infers the virtual dtor have implicit host and device attrs. Since 
virtual dtor of explicitly instantiated template class must be emitted, this 
causes constexpr dtor of std::string emitted, which calls a host function which 
was note emitted on device side.

This is a serious issue since it prevents users from using std::string with 
C++20 on Windows.

There are two issues revealed:

1. The deferred diag failed to diagnose calling of host function in host device 
function in device compilation. this can be further divided into two issuse:

1a. the deferred diag visitor does not visit dtor of member
 when visiting dtor, which it should

1b. the deferred diag visitor does not visit dtor of explicit template class 
instantiation, which it should

By fixing this issue, clang will diag the issue in compilation instead of 
linking.

2. When inferring host device attr of virtual dtor of explicit template class 
instantiation, clang should be conservative since it is sure to be emitted. 
Since an implicit host device function may call a host function, clang cannot 
assume it is always available on device. This guarantees dtors that may call 
host functions not to have implicit device attr, therefore will not be emitted 
on device side.

Fixes: https://github.com/llvm/llvm-project/issues/108548

Fixes: SWDEV-517435

>From c5f38234554a6bcfdb530d7e04776eb30b36ed38 Mon Sep 17 00:00:00 2001
From: "Yaxun (Sam) Liu" 
Date: Wed, 26 Feb 2025 11:43:28 -0500
Subject: [PATCH] [CUDA][HIP] fix virtual dtor host/device attr

Currently if CUDA/HIP users use template class with virtual dtor
and std::string data member with C++20 and MSVC. When the template
class is explicitly instantiated, they encounter unresolved
symbols in linker.

It was caused by clang inferring host/device attributes for
default dtors. Since all dtors of member and parent classes
have implicit host device attrs, clang infers the virtual dtor have
implicit host and device attrs. Since virtual dtor of
explicitly instantiated template class must be emitted,
this causes constexpr dtor of std::string emitted, which
calls a host function which was note emitted on device side.

This is a serious issue since it prevents users from
using std::string with C++20 on Windows.

There are two issues revealed:

1. The deferred diag failed to diagnose calling of host
function in host device function in device compilation. this can be
further divided into two issuse:

1a. the deferred diag visitor does not visit dtor of member
 when visiting dtor, which it should

1b. the deferred diag visitor does not visit dtor of explicit
template class instantiation, which it should

By fixing this issue, clang will diag the issue in compilation
instead of linking.

2. When inferring host device attr of virtual dtor of explicit
template class instantiation, clang should be conservative
since it is sure to be emitted. Since an implicit host device
function may call a host function, clang cannot assume it is
always available on device. This guarantees dtors that
may call host functions not to have implicit device attr,
therefore will not be emitted on device side.

Fixes: https://github.com/llvm/llvm-project/issues/108548

Fixes: SWDEV-517435
---
 clang/docs/HIPSupport.rst   |  20 ++
 clang/include/clang/Sema/Sema.h |   2 +-
 clang/lib/Sema/Sema.cpp |  58 ++
 clang/lib/Sema/SemaCUDA.cpp |  23 ++-
 clang/lib/Sema/SemaDecl.cpp |  15 +
 clang/test/SemaCUDA/dtor.cu | 104 
 6 files changed, 219 insertions(+), 3 deletions(-)
 create mode 100644 clang/test/SemaCUDA/dtor.cu

diff --git a/clang/docs/HIPSupport.rst b/clang/docs/HIPSupport.rst
index 481ed39230813..8f473c21e1918 100644
--- a/clang/docs/HIPSupport.rst
+++ b/clang/docs/HIPSupport.rst
@@ -286,6 +286,26 @@ Example Usage
   basePtr->virtualFunction(); // Allowed since obj is constructed in 
device code
}
 
+Host and Device Attributes of Default Destructors
+===
+
+If a default destructor does not have explicit host or device attributes,
+clang infers these attributes based on the destructors of its data members
+and base classes. If any conflicts are detected among these destructors,
+clang diagnoses the issue. Otherwise, clang adds an implicit host or device
+attribute according to whether the data members's and base classes's
+destructors can execute on the host or device side.
+
+For explicit template classes with virtual destructors, which mus

[clang] [clang] Fix UEFI Target info (PR #127290)

2025-02-26 Thread via cfe-commits

https://github.com/Prabhuk updated 
https://github.com/llvm/llvm-project/pull/127290

>From 3e6122744f355954edb6a5450ae4220ba39bc9c1 Mon Sep 17 00:00:00 2001
From: prabhukr 
Date: Fri, 14 Feb 2025 16:53:33 -0800
Subject: [PATCH 1/2] [clang] Fix UEFI Target info

For X64 UEFI targets, making the integer size and va_list kind fixes.
---
 clang/include/clang/Basic/TargetOSMacros.def |  3 +++
 clang/lib/Basic/Targets/X86.h| 16 +++-
 2 files changed, 14 insertions(+), 5 deletions(-)

diff --git a/clang/include/clang/Basic/TargetOSMacros.def 
b/clang/include/clang/Basic/TargetOSMacros.def
index 58dce330f9c8f..f4f3276ad1c25 100644
--- a/clang/include/clang/Basic/TargetOSMacros.def
+++ b/clang/include/clang/Basic/TargetOSMacros.def
@@ -53,4 +53,7 @@ TARGET_OS(TARGET_OS_NANO, Triple.isWatchOS())
 TARGET_OS(TARGET_IPHONE_SIMULATOR, Triple.isSimulatorEnvironment())
 TARGET_OS(TARGET_OS_UIKITFORMAC, Triple.isMacCatalystEnvironment())
 
+// UEFI target.
+TARGET_OS(TARGET_OS_UEFI, Triple.isUEFI())
+
 #undef TARGET_OS
diff --git a/clang/lib/Basic/Targets/X86.h b/clang/lib/Basic/Targets/X86.h
index 205edcab9ccb3..20fcb25defba2 100644
--- a/clang/lib/Basic/Targets/X86.h
+++ b/clang/lib/Basic/Targets/X86.h
@@ -835,16 +835,22 @@ class LLVM_LIBRARY_VISIBILITY UEFIX86_64TargetInfo
 public:
   UEFIX86_64TargetInfo(const llvm::Triple &Triple, const TargetOptions &Opts)
   : UEFITargetInfo(Triple, Opts) {
+LongWidth = LongAlign = 32;
+DoubleAlign = LongLongAlign = 64;
+IntMaxType = SignedLongLong;
+Int64Type = SignedLongLong;
+SizeType = UnsignedLongLong;
+PtrDiffType = SignedLongLong;
+IntPtrType = SignedLongLong;
+LongDoubleWidth = LongDoubleAlign = 64;
+LongDoubleFormat = &llvm::APFloat::IEEEdouble();
+WCharType = UnsignedShort;
+WIntType = UnsignedShort;
 this->TheCXXABI.set(TargetCXXABI::Microsoft);
-this->MaxTLSAlign = 8192u * this->getCharWidth();
 this->resetDataLayout("e-m:w-p270:32:32-p271:32:32-p272:64:64-"
   "i64:64-i128:128-f80:128-n8:16:32:64-S128");
   }
 
-  BuiltinVaListKind getBuiltinVaListKind() const override {
-return TargetInfo::CharPtrBuiltinVaList;
-  }
-
   CallingConvCheckResult checkCallingConvention(CallingConv CC) const override 
{
 switch (CC) {
 case CC_C:

>From fa23204cb0eb6826f8866e497ff4d6ed96dbb8df Mon Sep 17 00:00:00 2001
From: prabhukr 
Date: Wed, 26 Feb 2025 09:59:47 -0800
Subject: [PATCH 2/2] More cleanups. Add test.

---
 clang/lib/Basic/Targets/X86.h  | 10 --
 clang/test/Preprocessor/init.c |  1 +
 2 files changed, 1 insertion(+), 10 deletions(-)

diff --git a/clang/lib/Basic/Targets/X86.h b/clang/lib/Basic/Targets/X86.h
index 20fcb25defba2..be07ae05f326c 100644
--- a/clang/lib/Basic/Targets/X86.h
+++ b/clang/lib/Basic/Targets/X86.h
@@ -851,16 +851,6 @@ class LLVM_LIBRARY_VISIBILITY UEFIX86_64TargetInfo
   "i64:64-i128:128-f80:128-n8:16:32:64-S128");
   }
 
-  CallingConvCheckResult checkCallingConvention(CallingConv CC) const override 
{
-switch (CC) {
-case CC_C:
-case CC_Win64:
-  return CCCR_OK;
-default:
-  return CCCR_Warning;
-}
-  }
-
   TargetInfo::CallingConvKind
   getCallingConvKind(bool ClangABICompat4) const override {
 return CCK_MicrosoftWin64;
diff --git a/clang/test/Preprocessor/init.c b/clang/test/Preprocessor/init.c
index 1ac325d444662..4c8d519c2b664 100644
--- a/clang/test/Preprocessor/init.c
+++ b/clang/test/Preprocessor/init.c
@@ -2835,6 +2835,7 @@
 // RISCV64-LINUX: #define unix 1
 
 // RUN: %clang_cc1 -dM -triple=x86_64-uefi -E /dev/null | FileCheck 
-match-full-lines -check-prefix UEFI %s
+// RUN: %clang_cc1 -dM -triple=x86_64-unknown-uefi -E /dev/null | FileCheck 
-match-full-lines -check-prefix UEFI %s
 
 // UEFI: #define __UEFI__ 1
 

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [CIR] Upstream basic alloca and load support (PR #128792)

2025-02-26 Thread Andy Kaylor via cfe-commits


@@ -117,6 +117,24 @@ static void 
printOmittedTerminatorRegion(mlir::OpAsmPrinter &printer,
   /*printBlockTerminators=*/!omitRegionTerm(region));
 }
 
+//===--===//
+// AllocaOp
+//===--===//
+
+void cir::AllocaOp::build(::mlir::OpBuilder &odsBuilder,

andykaylor wrote:

Oh! I misunderstood your original comment. This appears to be an MLIR style 
thing. Maybe @bcardosolopes or @lanza can provide more insight into the history 
of this. I don't think it's necessary.

https://github.com/llvm/llvm-project/pull/128792
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


  1   2   3   4   5   >