date:20240129

[clang] [C++20] [Modules] Introduce -fskip-odr-check-in-gmf (PR #79959)

2024-01-29 Thread via cfe-commits


llvmbot wrote:




@llvm/pr-subscribers-clang-modules

Author: Chuanqi Xu (ChuanqiXu9)


Changes

Close https://github.com/llvm/llvm-project/issues/79240

Cite the comment from @mizvekov in
//github.com/llvm/llvm-project/issues/79240:

 There are two kinds of bugs / issues relevant here:

 Clang bugs that this change hides
 Here we can add a Frontend flag that disables the GMF ODR check, just
 so
 we can keep tracking, testing and fixing these issues.
 The Driver would just always pass that flag.
 We could add that flag in this current issue.
 Bugs in user code:
 I don't think it's worth adding a corresponding Driver flag for
 controlling the above Frontend flag, since we intend it's behavior to
 become default as we fix the problems, and users interested in testing
 the more strict behavior can just use the Frontend flag directly.

This patch follows the suggestion:
- Introduce the CC1 flag `-fskip-odr-check-in-gmf` which is by default off, so 
that the every existing test will still be tested with checking ODR violations.
- Passing `-fskip-odr-check-in-gmf` in the driver to keep the behavior we 
intended.
- Edit the document to tell the users who are still interested in more strict 
checks can use `-Xclang -fno-skip-odr-check-in-gmf` to get the existing 
behavior.

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


15 Files Affected:

- (modified) clang/docs/ReleaseNotes.rst (+2-1) 
- (modified) clang/docs/StandardCPlusPlusModules.rst (+22) 
- (modified) clang/include/clang/Basic/LangOptions.def (+1) 
- (modified) clang/include/clang/Driver/Options.td (+8) 
- (modified) clang/include/clang/Serialization/ASTReader.h (+3-2) 
- (modified) clang/lib/Driver/ToolChains/Clang.cpp (+8) 
- (modified) clang/lib/Serialization/ASTReader.cpp (+1-1) 
- (modified) clang/lib/Serialization/ASTReaderDecl.cpp (+7-7) 
- (modified) clang/lib/Serialization/ASTWriter.cpp (+1-1) 
- (modified) clang/lib/Serialization/ASTWriterDecl.cpp (+4-4) 
- (added) clang/test/Driver/modules-skip-odr-check-in-gmf.cpp (+10) 
- (modified) clang/test/Modules/concept.cppm (+16-7) 
- (modified) clang/test/Modules/polluted-operator.cppm (+15-3) 
- (modified) clang/test/Modules/pr76638.cppm (+13-3) 
- (added) clang/test/Modules/skip-odr-check-in-gmf.cppm (+56) 


``diff
diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index bac6c7162a45b..44344ba330c5d 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -64,7 +64,8 @@ C++20 Feature Support
 
 - Clang won't perform ODR checks for decls in the global module fragment any
   more to ease the implementation and improve the user's using experience.
-  This follows the MSVC's behavior.
+  This follows the MSVC's behavior. Users interested in testing the more strict
+  behavior use the flag '-Xclang -fno-skip-odr-check-in-gmf'.
   (`#79240 `_).
 
 C++23 Feature Support
diff --git a/clang/docs/StandardCPlusPlusModules.rst 
b/clang/docs/StandardCPlusPlusModules.rst
index 4e853990a7338..c3d0c702a44c9 100644
--- a/clang/docs/StandardCPlusPlusModules.rst
+++ b/clang/docs/StandardCPlusPlusModules.rst
@@ -457,6 +457,28 @@ Note that **currently** the compiler doesn't consider 
inconsistent macro definit
 Currently Clang would accept the above example. But it may produce surprising 
results if the
 debugging code depends on consistent use of ``NDEBUG`` also in other 
translation units.
 
+Definitions consistency
+^^^
+
+The C++ language defines that same declarations in different translation units 
should have
+the same definition, as known as ODR (One Definition Rule). Prior to modules, 
the translation
+units don't dependent on each other and the compiler itself don't and can't 
perform a strong
+ODR violation check. Sometimes it is the linker does some jobs related to ODR, 
where the
+higher level semantics are missing. With the introduction of modules, now the 
compiler have
+the chance to perform ODR violations with language semantics across 
translation units.
+
+However, in the practice we found the existing ODR checking mechanism may be 
too aggressive.
+In the many issue reports about ODR violation diagnostics, most of them are 
false positive
+ODR violations and the true positive ODR violations are rarely reported. Also 
MSVC don't
+perform ODR check for declarations in the global module fragment.
+
+So in order to get better user experience, saving the time checking ODR and 
keep consistent
+behavior with MSVC, we disabled the ODR check for the declarations in the 
global module
+fragment by default. Users who want more strict check can still use the
+``-Xclang -fno-skip-odr-check-in-gmf`` flag to get the ODR check enabled. It 
is also
+encouraged to report issues if users find false positive ODR violations or 
false negative ODR
+violations with the flag enabled.
+
 ABI Impacts
 ---
 
diff --git a/clang/include/clang/Basic/LangOptions.def

[clang] [C++20] [Modules] Introduce -fskip-odr-check-in-gmf (PR #79959)

2024-01-29 Thread Chuanqi Xu via cfe-commits


https://github.com/ChuanqiXu9 created 
https://github.com/llvm/llvm-project/pull/79959

Close https://github.com/llvm/llvm-project/issues/79240

Cite the comment from @mizvekov in
//github.com/llvm/llvm-project/issues/79240:

> There are two kinds of bugs / issues relevant here:
>
> Clang bugs that this change hides
> Here we can add a Frontend flag that disables the GMF ODR check, just
> so
> we can keep tracking, testing and fixing these issues.
> The Driver would just always pass that flag.
> We could add that flag in this current issue.
> Bugs in user code:
> I don't think it's worth adding a corresponding Driver flag for
> controlling the above Frontend flag, since we intend it's behavior to
> become default as we fix the problems, and users interested in testing
> the more strict behavior can just use the Frontend flag directly.

This patch follows the suggestion:
- Introduce the CC1 flag `-fskip-odr-check-in-gmf` which is by default off, so 
that the every existing test will still be tested with checking ODR violations.
- Passing `-fskip-odr-check-in-gmf` in the driver to keep the behavior we 
intended.
- Edit the document to tell the users who are still interested in more strict 
checks can use `-Xclang -fno-skip-odr-check-in-gmf` to get the existing 
behavior.

>From 046ec7d3e8f509d830e2e6081d697415859811c2 Mon Sep 17 00:00:00 2001
From: Chuanqi Xu 
Date: Tue, 30 Jan 2024 15:57:35 +0800
Subject: [PATCH] [C++20] [Modules] Introduce -fskip-odr-check-in-gmf

Close https://github.com/llvm/llvm-project/issues/79240

Cite the comment from @mizvekov in
//github.com/llvm/llvm-project/issues/79240:

> There are two kinds of bugs / issues relevant here:
>
> Clang bugs that this change hides
> Here we can add a Frontend flag that disables the GMF ODR check, just
> so
> we can keep tracking, testing and fixing these issues.
> The Driver would just always pass that flag.
> We could add that flag in this current issue.
> Bugs in user code:
> I don't think it's worth adding a corresponding Driver flag for
> controlling the above Frontend flag, since we intend it's behavior to
> become default as we fix the problems, and users interested in testing
> the more strict behavior can just use the Frontend flag directly.

This patch follows the suggestion:
- Introduce the CC1 flag `-fskip-odr-check-in-gmf` which is by default
  off,
  so that the every existing test will still be tested with checking ODR
  violations.
- Passing `-fskip-odr-check-in-gmf` in the driver to keep the behavior
  we intended.
- Edit the document to tell the users who are still interested in more
  strict checks can use `-Xclang -fno-skip-odr-check-in-gmf` to get the
  existing behavior.
---
 clang/docs/ReleaseNotes.rst   |  3 +-
 clang/docs/StandardCPlusPlusModules.rst   | 22 
 clang/include/clang/Basic/LangOptions.def |  1 +
 clang/include/clang/Driver/Options.td |  8 +++
 clang/include/clang/Serialization/ASTReader.h |  5 +-
 clang/lib/Driver/ToolChains/Clang.cpp |  8 +++
 clang/lib/Serialization/ASTReader.cpp |  2 +-
 clang/lib/Serialization/ASTReaderDecl.cpp | 14 ++---
 clang/lib/Serialization/ASTWriter.cpp |  2 +-
 clang/lib/Serialization/ASTWriterDecl.cpp |  8 +--
 .../Driver/modules-skip-odr-check-in-gmf.cpp  | 10 
 clang/test/Modules/concept.cppm   | 23 +---
 clang/test/Modules/polluted-operator.cppm | 18 +-
 clang/test/Modules/pr76638.cppm   | 16 +-
 clang/test/Modules/skip-odr-check-in-gmf.cppm | 56 +++
 15 files changed, 167 insertions(+), 29 deletions(-)
 create mode 100644 clang/test/Driver/modules-skip-odr-check-in-gmf.cpp
 create mode 100644 clang/test/Modules/skip-odr-check-in-gmf.cppm

diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index bac6c7162a45b..44344ba330c5d 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -64,7 +64,8 @@ C++20 Feature Support
 
 - Clang won't perform ODR checks for decls in the global module fragment any
   more to ease the implementation and improve the user's using experience.
-  This follows the MSVC's behavior.
+  This follows the MSVC's behavior. Users interested in testing the more strict
+  behavior use the flag '-Xclang -fno-skip-odr-check-in-gmf'.
   (`#79240 `_).
 
 C++23 Feature Support
diff --git a/clang/docs/StandardCPlusPlusModules.rst 
b/clang/docs/StandardCPlusPlusModules.rst
index 4e853990a7338..c3d0c702a44c9 100644
--- a/clang/docs/StandardCPlusPlusModules.rst
+++ b/clang/docs/StandardCPlusPlusModules.rst
@@ -457,6 +457,28 @@ Note that **currently** the compiler doesn't consider 
inconsistent macro definit
 Currently Clang would accept the above example. But it may produce surprising 
results if the
 debugging code depends on consistent use of ``NDEBUG`` also in other 
translation units.
 
+Definitions consistency
+^^^
+
+The C++

[llvm] [clang] [HLSL] Implementation of tan intrinsic (PR #79948)

2024-01-29 Thread Eli Friedman via cfe-commits



@@ -1010,6 +1010,7 @@ let IntrProperties = [IntrNoMem, IntrSpeculatable, 
IntrWillReturn] in {
   def int_powi : DefaultAttrsIntrinsic<[llvm_anyfloat_ty], [LLVMMatchType<0>, 
llvm_anyint_ty]>;
   def int_sin  : DefaultAttrsIntrinsic<[llvm_anyfloat_ty], [LLVMMatchType<0>]>;
   def int_cos  : DefaultAttrsIntrinsic<[llvm_anyfloat_ty], [LLVMMatchType<0>]>;
+  def int_tan  : DefaultAttrsIntrinsic<[llvm_anyfloat_ty], [LLVMMatchType<0>]>;

efriedma-quic wrote:

(Sorry, accidentally wrote Discord instead of Discourse initially.)

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

[llvm] [clang] [HLSL] Implementation of tan intrinsic (PR #79948)

2024-01-29 Thread Eli Friedman via cfe-commits


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

[llvm] [clang] [HLSL] Implementation of tan intrinsic (PR #79948)

2024-01-29 Thread Eli Friedman via cfe-commits



@@ -1010,6 +1010,7 @@ let IntrProperties = [IntrNoMem, IntrSpeculatable, 
IntrWillReturn] in {
   def int_powi : DefaultAttrsIntrinsic<[llvm_anyfloat_ty], [LLVMMatchType<0>, 
llvm_anyint_ty]>;
   def int_sin  : DefaultAttrsIntrinsic<[llvm_anyfloat_ty], [LLVMMatchType<0>]>;
   def int_cos  : DefaultAttrsIntrinsic<[llvm_anyfloat_ty], [LLVMMatchType<0>]>;
+  def int_tan  : DefaultAttrsIntrinsic<[llvm_anyfloat_ty], [LLVMMatchType<0>]>;

efriedma-quic wrote:

Adding `@llvm.tan` is a significant change; if you need this, please post a 
proposal on Discord explaining what you're adding an why.

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

[llvm] [clang] [HLSL] Implementation of tan intrinsic (PR #79948)

2024-01-29 Thread Eli Friedman via cfe-commits


https://github.com/efriedma-quic requested changes to this pull request.


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

[llvm] [clang] [HLSL] Implementation of tan intrinsic (PR #79948)

2024-01-29 Thread Eli Friedman via cfe-commits


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

[llvm] [clang-tools-extra] [clang] [CLANG] Add warning when INF or NAN are used in a binary operation or as function argument in fast math mode. (PR #76873)

2024-01-29 Thread via cfe-commits


mikaelholmen wrote:

> > > Is this expected and wanted?
> > 
> > 
> > Good catch! I would not expect that diagnostic; we should silence the 
> > diagnostic if it's used in a `#ifdef`, `#elifdef`, or `defined` because the 
> > value isn't necessary. Perhaps we should also silence something like 
> > `sizeof(INFINITY)` because it's unevaluated?
> 
> Thanks @mikaelholmen and @AaronBallman. I will take a look and create a PR to 
> fix the issue.

Hi @zahiraam !
Did you get anywhere with this?

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

[llvm] [mlir] [clang] [flang] [mlir][complex] Prevent underflow in complex.abs (PR #79786)

2024-01-29 Thread Matthias Springer via cfe-commits


https://github.com/matthias-springer approved this pull request.


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

[clang] [Sema] Restructure and extend the testing of template pack deduction (PR #79881)

2024-01-29 Thread via cfe-commits


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


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

[llvm] [clang] [Sema] Implement support for -Wformat-signedness (PR #74440)

2024-01-29 Thread Karl-Johan Karlsson via cfe-commits


karka228 wrote:

Ping.

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

[flang] [llvm] [libc] [lldb] [libcxx] [compiler-rt] [lld] [clang] [ASan][AMDGPU] Fix Assertion Failure. (PR #79795)

2024-01-29 Thread via cfe-commits


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

[clang] [mlir] [flang] [llvm] [mlir][complex] Prevent underflow in complex.abs (PR #79786)

2024-01-29 Thread Kai Sasaki via cfe-commits


https://github.com/Lewuathe commented:

@joker-eph @matthias-springer I've fixed a bug in the previous PR that caused 
the integration test failure in the previous change. Could you review this 
change when you get a chance?

https://github.com/llvm/llvm-project/pull/76316

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

[clang] [llvm] [Clang][CMake] Add CSSPGO support to LLVM_BUILD_INSTRUMENTED (PR #79942)

2024-01-29 Thread Aiden Grossman via cfe-commits

boomanaiden154 wrote:

> In general, CSSPGO is meant as a more practical alternative for IRPGO thanks 
> to i) the use of sampled profile, ii) context-sensitivity. However, IRPGO is 
> still expected to provide better performance in all cases where it's 
> applicable thanks to accurate profile information.
Due to that, I don't think it makes sense to apply CSSPGO on top of IRPGO, and 
CMake automation would not permit mixing the two (both implemented as 
LLVM_BUILD_INSTRUMENTED exclusive options).

Ah. Might've been getting this confused with another technique (maybe 
IRPGO+instrumented context sensitive PGO?). I remember Google saying in 
https://discourse.llvm.org/t/practical-compiler-optimizations-for-wsc-workshop-us-llvm-dev-meeting-2023/73998
 that a valid pipeline was doing two rounds of profiling with different levels 
of instrumentation.

Thanks for the link to the existing performance results.

> With CMake stuff implemented in this diff, it's expected that the amount of 
> profile information collected would be miniscule (in-tree perf-training only 
> has a single hello world source file) and inadequate for getting much perf 
> boost with CSSPGO (it even prints the warning that it needs 6985000.0x more 
> profile).

Right. Not sure if you've seen https://github.com/llvm/llvm-project/pull/78879, 
but that should allow making that pretty easy to do. There's also 
https://github.com/llvm/llvm-project/pull/77347 proposing to change the 
default, but there hasn't really been a consensus on that one.

Thank you for the additional information. Sorry for the derailment/noise.

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

[clang] [Docs] Add release note about Clang-defined target OS macros (PR #79879)

2024-01-29 Thread Ian Anderson via cfe-commits


https://github.com/ian-twilightcoder approved this pull request.


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

[clang] [llvm] [RISCV] Relax march string order constraint (PR #78120)

2024-01-29 Thread Piyou Chen via cfe-commits


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

[clang] d09082f - [RISCV] Relax march string order constraint (#78120)

2024-01-29 Thread via cfe-commits


Author: Piyou Chen
Date: 2024-01-30T14:33:52+08:00
New Revision: d09082f6fd517759e5c0874a2e73bddd550de299

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

LOG: [RISCV] Relax march string order constraint (#78120)

Follow
https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/14 by
dropping the order requirement of `-march`.

1. single-letter extension can be arbitrary order
- march=rv32iamdf 
2. single-letter extension and multi-letter extension can be mixed
- march=rv32i_zihintntl_m_a_f_d_svinval
3. multi-letter extension need seperate the following extension by
underscore, otherwise it will be intreprete as one extension.
- march=rv32i_zbam -> i,zbam
- march=rv32i_zba_m -> i,zba,m

Added: 


Modified: 
clang/test/Driver/riscv-arch.c
llvm/lib/Support/RISCVISAInfo.cpp
llvm/unittests/Support/RISCVISAInfoTest.cpp

Removed: 




diff  --git a/clang/test/Driver/riscv-arch.c b/clang/test/Driver/riscv-arch.c
index 0ac81ea982f1b..c9e984e07cbea 100644
--- a/clang/test/Driver/riscv-arch.c
+++ b/clang/test/Driver/riscv-arch.c
@@ -156,9 +156,8 @@
 // RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32L %s
 // RV32L: error: invalid arch name 'rv32l'
 
-// RUN: not %clang --target=riscv32-unknown-elf -march=rv32imadf -### %s \
-// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32IMADF %s
-// RV32IMADF: error: invalid arch name 'rv32imadf'
+// RUN: %clang --target=riscv32-unknown-elf -march=rv32imadf -### %s \
+// RUN:   -fsyntax-only 2>&1 | FileCheck %s
 
 // RUN: not %clang --target=riscv32-unknown-elf -march=rv32imm -### %s \
 // RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32IMM %s
@@ -184,9 +183,8 @@
 // RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV64L %s
 // RV64L: error: invalid arch name 'rv64l'
 
-// RUN: not %clang --target=riscv64-unknown-elf -march=rv64imadf -### %s \
-// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV64IMADF %s
-// RV64IMADF: error: invalid arch name 'rv64imadf'
+// RUN: %clang --target=riscv64-unknown-elf -march=rv64imadf -### %s \
+// RUN:   -fsyntax-only 2>&1 | FileCheck %s
 
 // RUN: not %clang --target=riscv64-unknown-elf -march=rv64imm -### %s \
 // RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV64IMM %s
@@ -216,7 +214,7 @@
 // RUN: not %clang --target=riscv32-unknown-elf -march=rv32imcq -### %s \
 // RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-ORDER %s
 // RV32-ORDER: error: invalid arch name 'rv32imcq',
-// RV32-ORDER: standard user-level extension not given in canonical order 'q'
+// RV32-ORDER: unsupported standard user-level extension 'q'
 
 // RUN: not %clang --target=riscv32-unknown-elf -march=rv32izvl64b -### %s \
 // RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-ZVL64B-ER %s
@@ -318,7 +316,7 @@
 // RUN: not %clang --target=riscv32-unknown-elf -march=rv32ixabc_a -### %s \
 // RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-PREFIX %s
 // RV32-PREFIX: error: invalid arch name 'rv32ixabc_a',
-// RV32-PREFIX: invalid extension prefix 'a'
+// RV32-PREFIX: unsupported non-standard user-level extension 'xabc'
 
 // RUN: not %clang --target=riscv32-unknown-elf -march=rv32ixdef_sabc -### %s \
 // RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-X-ORDER %s

diff  --git a/llvm/lib/Support/RISCVISAInfo.cpp 
b/llvm/lib/Support/RISCVISAInfo.cpp
index c46d76da962c6..050253f78399e 100644
--- a/llvm/lib/Support/RISCVISAInfo.cpp
+++ b/llvm/lib/Support/RISCVISAInfo.cpp
@@ -7,6 +7,7 @@
 
//===--===//
 
 #include "llvm/Support/RISCVISAInfo.h"
+#include "llvm/ADT/MapVector.h"
 #include "llvm/ADT/STLExtras.h"
 #include "llvm/ADT/SetVector.h"
 #include "llvm/ADT/StringExtras.h"
@@ -703,6 +704,106 @@ RISCVISAInfo::parseNormalizedArchString(StringRef Arch) {
   return std::move(ISAInfo);
 }
 
+static Error splitExtsByUnderscore(StringRef Exts,
+   std::vector ) {
+  SmallVector Split;
+  if (Exts.empty())
+return Error::success();
+
+  Exts.split(Split, "_");
+
+  for (auto Ext : Split) {
+if (Ext.empty())
+  return createStringError(errc::invalid_argument,
+   "extension name missing after separator '_'");
+
+SplitExts.push_back(Ext.str());
+  }
+  return Error::success();
+}
+
+static Error processMultiLetterExtension(
+StringRef RawExt,
+MapVector> ,
+bool IgnoreUnknown, bool EnableExperimentalExtension,
+bool ExperimentalExtensionVersionCheck) {
+  StringRef Type = getExtensionType(RawExt);
+  StringRef Desc = getExtensionTypeDesc(RawExt);
+  auto Pos = findLastNonVersionCharacter(RawExt) + 1;
+  StringRef Name(RawExt.substr(0, Pos));
+  StringRef Vers(RawExt.substr(Pos));
+
+  if (Type.empty()) {
+if

[llvm] [clang] [HLSL] Implementation of tan intrinsic (PR #79948)

2024-01-29 Thread Farzon Lotfi via cfe-commits


farzonl wrote:

Test results:
```
Total Discovered Tests: 93648
  Skipped  :56 (0.06%)
  Unsupported  :  2502 (2.67%)
  Passed   : 90779 (96.94%)
  Expectedly Failed:   204 (0.22%)
  Failed   :   107 (0.11%)
```

Of the test I added all are passing:
https://github.com/llvm/llvm-project/assets/1802579/83e15c37-d2ae-4cf8-bd18-316b56da1c8d;>


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

[lld] [llvm] [clang] [AMDGPU] Rename COV module flag to amdhsa_code_object_version (PR #79905)

2024-01-29 Thread Matt Arsenault via cfe-commits


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


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

[clang] [clang-tools-extra] [llvm] [AArch64] Implement -fno-plt for SelectionDAG/GlobalISel (PR #78890)

2024-01-29 Thread Fangrui Song via cfe-commits


MaskRay wrote:

> It looks like some of the tests might be failing? Or does it need a rebase?

Sorry about it. The last minute `FastISel` change caused some failures. 
`Addr.getGlobalValue()` could be null. I have simplified `AArch64FastISel.cpp` 
to just check `"RtLibUseGOT"` (added by `-fno-plt`) and fixed the failures.

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

[clang] [clang-tools-extra] [llvm] [AArch64] Implement -fno-plt for SelectionDAG/GlobalISel (PR #78890)

2024-01-29 Thread Fangrui Song via cfe-commits


https://github.com/MaskRay updated 
https://github.com/llvm/llvm-project/pull/78890

>From 549e4ea5b292e558e085d881abd4c93f29352029 Mon Sep 17 00:00:00 2001
From: Fangrui Song 
Date: Sun, 21 Jan 2024 00:25:34 -0800
Subject: [PATCH] =?UTF-8?q?[=F0=9D=98=80=F0=9D=97=BD=F0=9D=97=BF]=20initia?=
 =?UTF-8?q?l=20version?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Created using spr 1.3.4
---
 llvm/lib/CodeGen/GlobalISel/CallLowering.cpp  | 13 ++-
 llvm/lib/Target/AArch64/AArch64FastISel.cpp   |  7 ++
 .../Target/AArch64/AArch64ISelLowering.cpp|  9 ++-
 llvm/lib/Target/AArch64/AArch64Subtarget.cpp  | 11 +--
 .../AArch64/GISel/AArch64CallLowering.cpp | 13 ++-
 .../GISel/AArch64InstructionSelector.cpp  | 16 +++-
 .../AArch64/GISel/AArch64LegalizerInfo.cpp|  3 +
 llvm/test/CodeGen/AArch64/nonlazybind.ll  | 81 +--
 8 files changed, 93 insertions(+), 60 deletions(-)

diff --git a/llvm/lib/CodeGen/GlobalISel/CallLowering.cpp 
b/llvm/lib/CodeGen/GlobalISel/CallLowering.cpp
index ccd9b13d730b6..d3484e5229e70 100644
--- a/llvm/lib/CodeGen/GlobalISel/CallLowering.cpp
+++ b/llvm/lib/CodeGen/GlobalISel/CallLowering.cpp
@@ -144,9 +144,16 @@ bool CallLowering::lowerCall(MachineIRBuilder , 
const CallBase ,
   // Try looking through a bitcast from one function type to another.
   // Commonly happens with calls to objc_msgSend().
   const Value *CalleeV = CB.getCalledOperand()->stripPointerCasts();
-  if (const Function *F = dyn_cast(CalleeV))
-Info.Callee = MachineOperand::CreateGA(F, 0);
-  else if (isa(CalleeV) || isa(CalleeV)) {
+  if (const Function *F = dyn_cast(CalleeV)) {
+if (F->hasFnAttribute(Attribute::NonLazyBind)) {
+  auto Reg =
+  MRI.createGenericVirtualRegister(getLLTForType(*F->getType(), DL));
+  MIRBuilder.buildGlobalValue(Reg, F);
+  Info.Callee = MachineOperand::CreateReg(Reg, false);
+} else {
+  Info.Callee = MachineOperand::CreateGA(F, 0);
+}
+  } else if (isa(CalleeV) || isa(CalleeV)) {
 // IR IFuncs and Aliases can't be forward declared (only defined), so the
 // callee must be in the same TU and therefore we can direct-call it 
without
 // worrying about it being out of range.
diff --git a/llvm/lib/Target/AArch64/AArch64FastISel.cpp 
b/llvm/lib/Target/AArch64/AArch64FastISel.cpp
index e98f6c4984a75..93d6024f34c09 100644
--- a/llvm/lib/Target/AArch64/AArch64FastISel.cpp
+++ b/llvm/lib/Target/AArch64/AArch64FastISel.cpp
@@ -3202,6 +3202,13 @@ bool AArch64FastISel::fastLowerCall(CallLoweringInfo 
) {
   if (Callee && !computeCallAddress(Callee, Addr))
 return false;
 
+  // MO_GOT is not handled. -fno-plt compiled intrinsic calls do not have the
+  // nonlazybind attribute. Check "RtLibUseGOT" instead.
+  if ((Subtarget->classifyGlobalFunctionReference(Addr.getGlobalValue(), TM) !=
+   AArch64II::MO_NO_FLAG) ||
+  MF->getFunction().getParent()->getRtLibUseGOT())
+return false;
+
   // The weak function target may be zero; in that case we must use indirect
   // addressing via a stub on windows as it may be out of range for a
   // PC-relative jump.
diff --git a/llvm/lib/Target/AArch64/AArch64ISelLowering.cpp 
b/llvm/lib/Target/AArch64/AArch64ISelLowering.cpp
index 96ea692d03f56..56de890c78dec 100644
--- a/llvm/lib/Target/AArch64/AArch64ISelLowering.cpp
+++ b/llvm/lib/Target/AArch64/AArch64ISelLowering.cpp
@@ -7969,13 +7969,14 @@ AArch64TargetLowering::LowerCall(CallLoweringInfo ,
   Callee = DAG.getTargetGlobalAddress(GV, DL, PtrVT, 0, 0);
 }
   } else if (auto *S = dyn_cast(Callee)) {
-if (getTargetMachine().getCodeModel() == CodeModel::Large &&
-Subtarget->isTargetMachO()) {
-  const char *Sym = S->getSymbol();
+bool UseGot = (getTargetMachine().getCodeModel() == CodeModel::Large &&
+   Subtarget->isTargetMachO()) ||
+  MF.getFunction().getParent()->getRtLibUseGOT();
+const char *Sym = S->getSymbol();
+if (UseGot) {
   Callee = DAG.getTargetExternalSymbol(Sym, PtrVT, AArch64II::MO_GOT);
   Callee = DAG.getNode(AArch64ISD::LOADgot, DL, PtrVT, Callee);
 } else {
-  const char *Sym = S->getSymbol();
   Callee = DAG.getTargetExternalSymbol(Sym, PtrVT, 0);
 }
   }
diff --git a/llvm/lib/Target/AArch64/AArch64Subtarget.cpp 
b/llvm/lib/Target/AArch64/AArch64Subtarget.cpp
index cf57d950ae8d7..c4c6827313b5e 100644
--- a/llvm/lib/Target/AArch64/AArch64Subtarget.cpp
+++ b/llvm/lib/Target/AArch64/AArch64Subtarget.cpp
@@ -43,10 +43,10 @@ static cl::opt
 UseAddressTopByteIgnored("aarch64-use-tbi", cl::desc("Assume that top byte of "
  "an address is ignored"), cl::init(false), 
cl::Hidden);
 
-static cl::opt
-UseNonLazyBind("aarch64-enable-nonlazybind",
-   cl::desc("Call nonlazybind functions via direct GOT load"),
-   cl::init(false), cl::Hidden);
+static cl::opt MachOUseNonLazyBind(
+

[clang] [clang-tools-extra] [llvm] [AArch64] Implement -fno-plt for SelectionDAG/GlobalISel (PR #78890)

2024-01-29 Thread Fangrui Song via cfe-commits


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

[clang] [llvm] [HLSL] Implementation of tan intrinsic (PR #79948)

2024-01-29 Thread via cfe-commits


llvmbot wrote:



@llvm/pr-subscribers-hlsl

@llvm/pr-subscribers-clang

Author: Farzon Lotfi (farzonl)


Changes

HLSL has a tan builtin defined here:
https://learn.microsoft.com/en-us/windows/win32/direct3dhlsl/dx-graphics-hlsl-tan

Currently HLSL builtins redirect to clang builtins. However there is no
tan clang builtin today.

This change implements #70082 

Changes:
1. Create an llvm tan intrinsic.
2. Then expose that intrinsic to hlsl.

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


13 Files Affected:

- (modified) clang/docs/LanguageExtensions.rst (+1) 
- (modified) clang/include/clang/Basic/Builtins.td (+6) 
- (modified) clang/lib/CodeGen/CGBuiltin.cpp (+3-1) 
- (modified) clang/lib/Headers/hlsl/hlsl_intrinsics.h (+32) 
- (modified) clang/lib/Sema/SemaChecking.cpp (+1) 
- (modified) clang/test/CodeGen/builtins-elementwise-math.c (+16) 
- (modified) clang/test/CodeGen/strictfp-elementwise-bulitins.cpp (+10) 
- (added) clang/test/CodeGenHLSL/builtins/tan.hlsl (+56) 
- (modified) clang/test/Sema/aarch64-sve-vector-trig-ops.c (+6) 
- (modified) clang/test/Sema/builtins-elementwise-math.c (+21) 
- (modified) clang/test/Sema/riscv-rvv-vector-trig-ops.c (+6) 
- (modified) clang/test/SemaCXX/builtins-elementwise-math.cpp (+7) 
- (modified) llvm/include/llvm/IR/Intrinsics.td (+1) 


``diff
diff --git a/clang/docs/LanguageExtensions.rst 
b/clang/docs/LanguageExtensions.rst
index c1420079f7511..60404602c8b35 100644
--- a/clang/docs/LanguageExtensions.rst
+++ b/clang/docs/LanguageExtensions.rst
@@ -665,6 +665,7 @@ Unless specified otherwise operation(±0) = ±0 and 
operation(±infinity) = ±in
  T __builtin_elementwise_exp2(T x)   returns the base-2 exponential, 
2^x, of the specified value  floating point types
 
  T __builtin_elementwise_sqrt(T x)   return the square root of a 
floating-point numberfloating point types
+ T __builtin_elementwise_tan(T x)return the tangent of x 
interpreted as an angle in radians   floating point types
  T __builtin_elementwise_roundeven(T x)  round x to the nearest integer 
value in floating point format,   floating point types
  rounding halfway cases to even 
(that is, to the nearest value
  that is an even integer), 
regardless of the current rounding
diff --git a/clang/include/clang/Basic/Builtins.td 
b/clang/include/clang/Basic/Builtins.td
index 1af01fe0d700c..bc6b02af8ea60 100644
--- a/clang/include/clang/Basic/Builtins.td
+++ b/clang/include/clang/Basic/Builtins.td
@@ -1284,6 +1284,12 @@ def ElementwiseSqrt : Builtin {
   let Prototype = "void(...)";
 }
 
+def ElementwiseTan : Builtin {
+  let Spellings = ["__builtin_elementwise_tan"];
+  let Attributes = [NoThrow, Const, CustomTypeChecking];
+  let Prototype = "void(...)";
+}
+
 def ElementwiseTrunc : Builtin {
   let Spellings = ["__builtin_elementwise_trunc"];
   let Attributes = [NoThrow, Const, CustomTypeChecking];
diff --git a/clang/lib/CodeGen/CGBuiltin.cpp b/clang/lib/CodeGen/CGBuiltin.cpp
index f3ab5ad7b08ec..f586e16f01d3d 100644
--- a/clang/lib/CodeGen/CGBuiltin.cpp
+++ b/clang/lib/CodeGen/CGBuiltin.cpp
@@ -3682,7 +3682,9 @@ RValue CodeGenFunction::EmitBuiltinExpr(const GlobalDecl 
GD, unsigned BuiltinID,
   case Builtin::BI__builtin_elementwise_sin:
 return RValue::get(
 emitUnaryBuiltin(*this, E, llvm::Intrinsic::sin, "elt.sin"));
-
+  case Builtin::BI__builtin_elementwise_tan:
+return RValue::get(
+emitUnaryBuiltin(*this, E, llvm::Intrinsic::tan, "elt.tan"));
   case Builtin::BI__builtin_elementwise_trunc:
 return RValue::get(
 emitUnaryBuiltin(*this, E, llvm::Intrinsic::trunc, "elt.trunc"));
diff --git a/clang/lib/Headers/hlsl/hlsl_intrinsics.h 
b/clang/lib/Headers/hlsl/hlsl_intrinsics.h
index da153d8f8e034..03fcb12185042 100644
--- a/clang/lib/Headers/hlsl/hlsl_intrinsics.h
+++ b/clang/lib/Headers/hlsl/hlsl_intrinsics.h
@@ -581,6 +581,38 @@ float sqrt(float In);
 _HLSL_BUILTIN_ALIAS(__builtin_sqrt)
 double sqrt(double In);
 
+//===--===//
+// tan builtins
+//===--===//
+#ifdef __HLSL_ENABLE_16_BIT
+_HLSL_BUILTIN_ALIAS(__builtin_elementwise_tan)
+half tan(half);
+_HLSL_BUILTIN_ALIAS(__builtin_elementwise_tan)
+half2 tan(half2);
+_HLSL_BUILTIN_ALIAS(__builtin_elementwise_tan)
+half3 tan(half3);
+_HLSL_BUILTIN_ALIAS(__builtin_elementwise_tan)
+half4 tan(half4);
+#endif
+
+_HLSL_BUILTIN_ALIAS(__builtin_elementwise_tan)
+float tan(float);
+_HLSL_BUILTIN_ALIAS(__builtin_elementwise_tan)
+float2 tan(float2);
+_HLSL_BUILTIN_ALIAS(__builtin_elementwise_tan)
+float3 tan(float3);
+_HLSL_BUILTIN_ALIAS(__builtin_elementwise_tan)
+float4 tan(float4);
+
+_HLSL_BUILTIN_ALIAS(__builtin_elementwise_tan)
+double tan(double);
+_HLSL_BUILTIN_ALIAS(__builtin_elementwise_tan)
+double2

[llvm] [clang] [Clang][CMake] Add CSSPGO support to LLVM_BUILD_INSTRUMENTED (PR #79942)

2024-01-29 Thread Amir Ayupov via cfe-commits


aaupov wrote:

Linking the preprint of the paper accepted to CGO'24 which has a CSSPGO 
performance comparison with AutoFDO and Instr PGO (Fig. 6): 
https://htyu.github.io/paper/Revamping_Sampling_based_PGO_with_Context_sensitivity_and_Pseudo_instrumentation_preprint.pdf

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

[llvm] [clang] [HLSL] Implementation of tan intrinsic (PR #79948)

2024-01-29 Thread Farzon Lotfi via cfe-commits


https://github.com/farzonl created 
https://github.com/llvm/llvm-project/pull/79948

HLSL has a tan builtin defined here:
https://learn.microsoft.com/en-us/windows/win32/direct3dhlsl/dx-graphics-hlsl-tan

Currently HLSL builtins redirect to clang builtins. However there is no
tan clang builtin today.

This change implements #70082 

Changes:
1. Create an llvm tan intrinsic.
2. Then expose that intrinsic to hlsl.

>From 3f3e208428a867139f777fe49f7dd7bd648e1617 Mon Sep 17 00:00:00 2001
From: Farzon Lotfi 
Date: Mon, 29 Jan 2024 20:23:30 -0500
Subject: [PATCH] [HLSL]  Implementation of tan intrinsic HLSL has a tan
 builtin defined here:
 
https://learn.microsoft.com/en-us/windows/win32/direct3dhlsl/dx-graphics-hlsl-tan
 Currently HLSL builtins redirect to clang builtins. However there is no tan
 clang builtin today.

This change implements #70082

Changes:
1. Create an llvm tan intrinsic.
2. Then expose that intrinsic to hlsl.
---
 clang/docs/LanguageExtensions.rst |  1 +
 clang/include/clang/Basic/Builtins.td |  6 ++
 clang/lib/CodeGen/CGBuiltin.cpp   |  4 +-
 clang/lib/Headers/hlsl/hlsl_intrinsics.h  | 32 +++
 clang/lib/Sema/SemaChecking.cpp   |  1 +
 .../test/CodeGen/builtins-elementwise-math.c  | 16 ++
 .../CodeGen/strictfp-elementwise-bulitins.cpp | 10 
 clang/test/CodeGenHLSL/builtins/tan.hlsl  | 56 +++
 clang/test/Sema/aarch64-sve-vector-trig-ops.c |  6 ++
 clang/test/Sema/builtins-elementwise-math.c   | 21 +++
 clang/test/Sema/riscv-rvv-vector-trig-ops.c   |  6 ++
 .../SemaCXX/builtins-elementwise-math.cpp |  7 +++
 llvm/include/llvm/IR/Intrinsics.td|  1 +
 13 files changed, 166 insertions(+), 1 deletion(-)
 create mode 100644 clang/test/CodeGenHLSL/builtins/tan.hlsl

diff --git a/clang/docs/LanguageExtensions.rst 
b/clang/docs/LanguageExtensions.rst
index c1420079f7511..60404602c8b35 100644
--- a/clang/docs/LanguageExtensions.rst
+++ b/clang/docs/LanguageExtensions.rst
@@ -665,6 +665,7 @@ Unless specified otherwise operation(±0) = ±0 and 
operation(±infinity) = ±in
  T __builtin_elementwise_exp2(T x)   returns the base-2 exponential, 
2^x, of the specified value  floating point types
 
  T __builtin_elementwise_sqrt(T x)   return the square root of a 
floating-point numberfloating point types
+ T __builtin_elementwise_tan(T x)return the tangent of x 
interpreted as an angle in radians   floating point types
  T __builtin_elementwise_roundeven(T x)  round x to the nearest integer 
value in floating point format,   floating point types
  rounding halfway cases to even 
(that is, to the nearest value
  that is an even integer), 
regardless of the current rounding
diff --git a/clang/include/clang/Basic/Builtins.td 
b/clang/include/clang/Basic/Builtins.td
index 1af01fe0d700c..bc6b02af8ea60 100644
--- a/clang/include/clang/Basic/Builtins.td
+++ b/clang/include/clang/Basic/Builtins.td
@@ -1284,6 +1284,12 @@ def ElementwiseSqrt : Builtin {
   let Prototype = "void(...)";
 }
 
+def ElementwiseTan : Builtin {
+  let Spellings = ["__builtin_elementwise_tan"];
+  let Attributes = [NoThrow, Const, CustomTypeChecking];
+  let Prototype = "void(...)";
+}
+
 def ElementwiseTrunc : Builtin {
   let Spellings = ["__builtin_elementwise_trunc"];
   let Attributes = [NoThrow, Const, CustomTypeChecking];
diff --git a/clang/lib/CodeGen/CGBuiltin.cpp b/clang/lib/CodeGen/CGBuiltin.cpp
index f3ab5ad7b08ec..f586e16f01d3d 100644
--- a/clang/lib/CodeGen/CGBuiltin.cpp
+++ b/clang/lib/CodeGen/CGBuiltin.cpp
@@ -3682,7 +3682,9 @@ RValue CodeGenFunction::EmitBuiltinExpr(const GlobalDecl 
GD, unsigned BuiltinID,
   case Builtin::BI__builtin_elementwise_sin:
 return RValue::get(
 emitUnaryBuiltin(*this, E, llvm::Intrinsic::sin, "elt.sin"));
-
+  case Builtin::BI__builtin_elementwise_tan:
+return RValue::get(
+emitUnaryBuiltin(*this, E, llvm::Intrinsic::tan, "elt.tan"));
   case Builtin::BI__builtin_elementwise_trunc:
 return RValue::get(
 emitUnaryBuiltin(*this, E, llvm::Intrinsic::trunc, "elt.trunc"));
diff --git a/clang/lib/Headers/hlsl/hlsl_intrinsics.h 
b/clang/lib/Headers/hlsl/hlsl_intrinsics.h
index da153d8f8e034..03fcb12185042 100644
--- a/clang/lib/Headers/hlsl/hlsl_intrinsics.h
+++ b/clang/lib/Headers/hlsl/hlsl_intrinsics.h
@@ -581,6 +581,38 @@ float sqrt(float In);
 _HLSL_BUILTIN_ALIAS(__builtin_sqrt)
 double sqrt(double In);
 
+//===--===//
+// tan builtins
+//===--===//
+#ifdef __HLSL_ENABLE_16_BIT
+_HLSL_BUILTIN_ALIAS(__builtin_elementwise_tan)
+half tan(half);
+_HLSL_BUILTIN_ALIAS(__builtin_elementwise_tan)
+half2 tan(half2);
+_HLSL_BUILTIN_ALIAS(__builtin_elementwise_tan)
+half3 tan(half3);

[llvm] [clang] [Clang][CMake] Add CSSPGO support to LLVM_BUILD_INSTRUMENTED (PR #79942)

2024-01-29 Thread Amir Ayupov via cfe-commits

aaupov wrote:

> Do you have benchmarks on how well this performs relative to standard IRPGO 
> (or on top of it)?

Couple of things to untangle here:
1. In general, CSSPGO is meant as a more practical alternative for IRPGO thanks 
to i) the use of sampled profile, ii) context-sensitivity. However, IRPGO is 
still expected to provide better performance in all cases where it's applicable 
thanks to accurate profile information. 
2. Due to that, I don't think it makes sense to apply CSSPGO on top of IRPGO, 
and CMake automation would not permit mixing the two (both implemented as 
LLVM_BUILD_INSTRUMENTED exclusive options).
3. [CSSPGO 
RFC](https://lists.llvm.org/pipermail/llvm-dev/2020-August/144101.html) has 
direct perf comparison of early implementation of CSSPGO vs IRPGO on Spec06:
https://github.com/llvm/llvm-project/assets/876514/a921e324-6b5d-4660-9928-0fb0c994649a;>
4. With CMake stuff implemented in this diff, it's expected that the amount of 
profile information collected would be miniscule (in-tree perf-training only 
has a single hello world source file) and inadequate for getting much perf 
boost with CSSPGO (it even prints the warning that it needs 6985000.0x more 
profile). 
5. But I'll kick out a perf run anyway to see what's the starting point. If 
it's zero, I'll try building different targets (in-tree or from LLVM Test 
Suite) to identify a viable profiling workload, but it's outside of scope of 
this diff.

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

[clang] [RISCV][clang] Add Zvfbfmin C intrinsics support (PR #79618)

2024-01-29 Thread Jim Lin via cfe-commits



@@ -282,6 +282,9 @@ void RISCVIntrinsicManagerImpl::ConstructRVVIntrinsics(
 }
   }
 
+  if (BaseType == BasicType::BFloat16 && !TI.hasFeature("zvfbfmin"))

tclin914 wrote:

bfloat vector is only valid when zvfbfmin is enabled. So it doesn't need to 
check again.

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

[llvm] [clang] [Clang][CMake] Add CSSPGO support to LLVM_BUILD_INSTRUMENTED (PR #79942)

2024-01-29 Thread Aiden Grossman via cfe-commits


boomanaiden154 wrote:

Do you have benchmarks on how well this performs relative to standard IRPGO (or 
on top of it)?

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

[libc] [libcxx] [lld] [llvm] [mlir] [compiler-rt] [flang] [clang] [libc++][complex] P2819R2 - Add `tuple` protocol to `complex` (PR #79744)

2024-01-29 Thread Hristo Hristov via cfe-commits


https://github.com/H-G-Hristov updated 
https://github.com/llvm/llvm-project/pull/79744

>From 52cdb5a5ae4ad33bb16dfe05738d64ee568a24ce Mon Sep 17 00:00:00 2001
From: Zingam 
Date: Sat, 27 Jan 2024 21:12:16 +0200
Subject: [PATCH] [libc++][complex] P2819R2 - Add `tuple` protocol to `complex`

Implements: P2819R2 
- https://eel.is/c++draft/utilities#concept:tuple-like
- https://eel.is/c++draft/complex.syn
- https://eel.is/c++draft/complex.tuple
---
 libcxx/docs/ReleaseNotes/19.rst   |   1 +
 libcxx/docs/Status/Cxx2cPapers.csv|   2 +-
 libcxx/include/CMakeLists.txt |   1 +
 libcxx/include/__fwd/complex.h|  25 +++
 libcxx/include/__fwd/get.h|  17 +++
 libcxx/include/__tuple/tuple_like.h   |   8 +
 libcxx/include/complex| 142 ++
 libcxx/include/libcxx.imp |   1 +
 libcxx/include/module.modulemap.in|   2 +
 libcxx/modules/std/complex.inc|   7 +
 .../tuple/__tuple_like.compile.pass.cpp   |  76 ++
 .../complex.number/complex.tuple/get.pass.cpp |  87 +++
 .../complex.tuple/get.verify.cpp  |  60 
 .../tuple_element.compile.pass.cpp|  43 ++
 .../complex.tuple/tuple_element.verify.cpp|  31 
 .../complex.tuple/tuple_size.compile.pass.cpp |  39 +
 .../generate_feature_test_macro_components.py |   2 +-
 17 files changed, 542 insertions(+), 2 deletions(-)
 create mode 100644 libcxx/include/__fwd/complex.h
 create mode 100644 
libcxx/test/libcxx/utilities/tuple/__tuple_like.compile.pass.cpp
 create mode 100644 
libcxx/test/std/numerics/complex.number/complex.tuple/get.pass.cpp
 create mode 100644 
libcxx/test/std/numerics/complex.number/complex.tuple/get.verify.cpp
 create mode 100644 
libcxx/test/std/numerics/complex.number/complex.tuple/tuple_element.compile.pass.cpp
 create mode 100644 
libcxx/test/std/numerics/complex.number/complex.tuple/tuple_element.verify.cpp
 create mode 100644 
libcxx/test/std/numerics/complex.number/complex.tuple/tuple_size.compile.pass.cpp

diff --git a/libcxx/docs/ReleaseNotes/19.rst b/libcxx/docs/ReleaseNotes/19.rst
index 17a0415a8ad43..c9faa6f9d456c 100644
--- a/libcxx/docs/ReleaseNotes/19.rst
+++ b/libcxx/docs/ReleaseNotes/19.rst
@@ -38,6 +38,7 @@ What's New in Libc++ 19.0.0?
 Implemented Papers
 --
 - P2637R3 - Member ``visit``
+- P2819R2 - Add ``tuple`` protocol to ``complex``
 
 
 Improvements and New Features
diff --git a/libcxx/docs/Status/Cxx2cPapers.csv 
b/libcxx/docs/Status/Cxx2cPapers.csv
index a62faee4f44e2..1c895f79a4c0f 100644
--- a/libcxx/docs/Status/Cxx2cPapers.csv
+++ b/libcxx/docs/Status/Cxx2cPapers.csv
@@ -39,7 +39,7 @@
 "`P2868R3 `__","LWG","Remove Deprecated 
``std::allocator`` Typedef From C++26","Kona November 
2023","|Complete|","18.0",""
 "`P2870R3 `__","LWG","Remove 
``basic_string::reserve()`` From C++26","Kona November 
2023","|Complete|","18.0",""
 "`P2871R3 `__","LWG","Remove Deprecated Unicode 
Conversion Facets from C++26","Kona November 2023","|Complete|","18.0",""
-"`P2819R2 `__","LWG","Add tuple protocol to 
complex","Kona November 2023","","",""
+"`P2819R2 `__","LWG","Add tuple protocol to 
complex","Kona November 2023","|Complete|","19.0",""
 "`P2937R0 `__","LWG","Freestanding: Remove 
``strtok``","Kona November 2023","","",""
 "`P2833R2 `__","LWG","Freestanding Library: inout 
expected span","Kona November 2023","","",""
 "`P2836R1 `__","LWG","``std::basic_const_iterator`` 
should follow its underlying type's convertibility","Kona November 
2023","","","|DR|"
diff --git a/libcxx/include/CMakeLists.txt b/libcxx/include/CMakeLists.txt
index ed721d467e94f..05332a3507d07 100644
--- a/libcxx/include/CMakeLists.txt
+++ b/libcxx/include/CMakeLists.txt
@@ -426,6 +426,7 @@ set(files
   __functional/weak_result_type.h
   __fwd/array.h
   __fwd/bit_reference.h
+  __fwd/complex.h
   __fwd/fstream.h
   __fwd/get.h
   __fwd/hash.h
diff --git a/libcxx/include/__fwd/complex.h b/libcxx/include/__fwd/complex.h
new file mode 100644
index 0..1c7be5a5ff750
--- /dev/null
+++ b/libcxx/include/__fwd/complex.h
@@ -0,0 +1,25 @@
+//===-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===-===//
+
+#ifndef _LIBCPP___FWD_COMPLEX_H
+#define _LIBCPP___FWD_COMPLEX_H
+
+#include <__config>
+
+#if !defined(_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER)
+#  pragma GCC system_header
+#endif
+

[llvm] [clang] [Clang][CMake] Add CSSPGO support to LLVM_BUILD_INSTRUMENTED (PR #79942)

2024-01-29 Thread Amir Ayupov via cfe-commits


https://github.com/aaupov updated 
https://github.com/llvm/llvm-project/pull/79942

>From 90686f2cd5e210f9ca974c10f8c1224a825c1315 Mon Sep 17 00:00:00 2001
From: Amir Ayupov 
Date: Wed, 19 Jul 2023 20:30:29 -0700
Subject: [PATCH 1/2] [Clang][CMake] Add CSSPGO support to
 LLVM_BUILD_INSTRUMENTED

Build on Clang-BOLT infrastructure to collect sample profiles for CSSPGO.
Add clang/cmake/caches/CSSPGO.cmake to automate CSSPGO Clang build.

Differential Revision: https://reviews.llvm.org/D155419
---
 clang/CMakeLists.txt   | 12 -
 clang/cmake/caches/CSSPGO.cmake|  3 ++
 clang/utils/perf-training/CMakeLists.txt   | 32 -
 clang/utils/perf-training/lit.cfg  |  6 +++
 clang/utils/perf-training/lit.site.cfg.in  |  1 +
 clang/utils/perf-training/perf-helper.py   | 54 ++
 llvm/CMakeLists.txt|  3 ++
 llvm/cmake/modules/HandleLLVMOptions.cmake | 26 ++-
 8 files changed, 123 insertions(+), 14 deletions(-)
 create mode 100644 clang/cmake/caches/CSSPGO.cmake

diff --git a/clang/CMakeLists.txt b/clang/CMakeLists.txt
index 47fc2e4886cfc..5d16442ac7bc3 100644
--- a/clang/CMakeLists.txt
+++ b/clang/CMakeLists.txt
@@ -741,11 +741,21 @@ if (CLANG_ENABLE_BOOTSTRAP)
   if(BOOTSTRAP_LLVM_BUILD_INSTRUMENTED)
 add_dependencies(clang-bootstrap-deps llvm-profdata)
 set(PGO_OPT -DLLVM_PROFDATA=${LLVM_RUNTIME_OUTPUT_INTDIR}/llvm-profdata)
+string(TOUPPER "${BOOTSTRAP_LLVM_BUILD_INSTRUMENTED}" 
BOOTSTRAP_LLVM_BUILD_INSTRUMENTED)
+if (BOOTSTRAP_LLVM_BUILD_INSTRUMENTED STREQUAL "CSSPGO")
+  add_dependencies(clang-bootstrap-deps llvm-profgen)
+  list(APPEND PGO_OPT 
-DLLVM_PROFGEN=${LLVM_RUNTIME_OUTPUT_INTDIR}/llvm-profgen)
+endif()
   endif()
 
   if(LLVM_BUILD_INSTRUMENTED)
+string(TOUPPER "${LLVM_BUILD_INSTRUMENTED}" LLVM_BUILD_INSTRUMENTED)
 add_dependencies(clang-bootstrap-deps generate-profdata)
-set(PGO_OPT 
-DLLVM_PROFDATA_FILE=${CMAKE_CURRENT_BINARY_DIR}/utils/perf-training/clang.profdata)
+if (LLVM_BUILD_INSTRUMENTED STREQUAL "CSSPGO")
+  set(PGO_OPT 
-DLLVM_SPROFDATA_FILE=${CMAKE_CURRENT_BINARY_DIR}/utils/perf-training/clang.profdata)
+else()
+  set(PGO_OPT 
-DLLVM_PROFDATA_FILE=${CMAKE_CURRENT_BINARY_DIR}/utils/perf-training/clang.profdata)
+endif()
 # Use the current tools for LTO instead of the instrumented ones
 list(APPEND _BOOTSTRAP_DEFAULT_PASSTHROUGH
   CMAKE_CXX_COMPILER
diff --git a/clang/cmake/caches/CSSPGO.cmake b/clang/cmake/caches/CSSPGO.cmake
new file mode 100644
index 0..34159068d5ea3
--- /dev/null
+++ b/clang/cmake/caches/CSSPGO.cmake
@@ -0,0 +1,3 @@
+set(CMAKE_BUILD_TYPE RelWithDebInfo CACHE STRING "")
+set(BOOTSTRAP_LLVM_BUILD_INSTRUMENTED "CSSPGO" CACHE STRING "")
+include(${CMAKE_CURRENT_LIST_DIR}/PGO.cmake)
diff --git a/clang/utils/perf-training/CMakeLists.txt 
b/clang/utils/perf-training/CMakeLists.txt
index 601f40902fa34..489a097cd49c8 100644
--- a/clang/utils/perf-training/CMakeLists.txt
+++ b/clang/utils/perf-training/CMakeLists.txt
@@ -14,8 +14,33 @@ if(LLVM_BUILD_INSTRUMENTED)
 DEPENDS clang clear-profraw ${CLANG_PERF_TRAINING_DEPS}
 )
 
+  add_custom_target(generate-profdata-deps)
+  string(TOUPPER "${LLVM_BUILD_INSTRUMENTED}" 
uppercase_LLVM_BUILD_INSTRUMENTED)
+  if (uppercase_LLVM_BUILD_INSTRUMENTED STREQUAL "CSSPGO")
+set(PROFDATA_SAMPLE "--sample")
+if(NOT LLVM_PROFGEN)
+  find_program(LLVM_PROFGEN llvm-profgen)
+endif()
+
+if(NOT LLVM_PROFGEN)
+  message(STATUS "To enable converting CSSPGO samples LLVM_PROFGEN has to 
point to llvm-profgen")
+endif()
+
+# Convert perf profiles into profraw
+add_custom_target(convert-perf-profraw
+  COMMAND "${Python3_EXECUTABLE}"
+  ${CMAKE_CURRENT_SOURCE_DIR}/perf-helper.py perf2prof ${LLVM_PROFGEN}
+  $ ${CMAKE_CURRENT_BINARY_DIR}
+  COMMENT "Converting perf profiles into profraw"
+  DEPENDS generate-profraw)
+add_dependencies(generate-profdata-deps convert-perf-profraw)
+  else()
+add_dependencies(generate-profdata-deps generate-profraw)
+  endif()
+
   add_custom_target(clear-profraw
 COMMAND "${Python3_EXECUTABLE}" ${CMAKE_CURRENT_SOURCE_DIR}/perf-helper.py 
clean ${CMAKE_CURRENT_BINARY_DIR} profraw
+COMMAND "${Python3_EXECUTABLE}" ${CMAKE_CURRENT_SOURCE_DIR}/perf-helper.py 
clean ${CMAKE_CURRENT_BINARY_DIR} perf.data
 COMMENT "Clearing old profraw data")
 
   if(NOT LLVM_PROFDATA)
@@ -26,9 +51,12 @@ if(LLVM_BUILD_INSTRUMENTED)
 message(STATUS "To enable merging PGO data LLVM_PROFDATA has to point to 
llvm-profdata")
   else()
 add_custom_target(generate-profdata
-  COMMAND "${Python3_EXECUTABLE}" 
${CMAKE_CURRENT_SOURCE_DIR}/perf-helper.py merge ${LLVM_PROFDATA} 
${CMAKE_CURRENT_BINARY_DIR}/clang.profdata ${CMAKE_CURRENT_BINARY_DIR}
+  COMMAND "${Python3_EXECUTABLE}"
+  ${CMAKE_CURRENT_SOURCE_DIR}/perf-helper.py merge ${LLVM_PROFDATA}
+

[clang] [RISCV][clang] Add Zvfbfmin C intrinsics support (PR #79618)

2024-01-29 Thread Brandon Wu via cfe-commits



@@ -1883,6 +1883,12 @@ let Log2LMUL = [-3, -2, -1, 0, 1, 2] in {
   def vfncvt_rtz_x_f_w : RVVConvToNarrowingSignedBuiltin<"vfncvt_rtz_x">;
   def vfncvt_rod_f_f_w : RVVConvBuiltin<"v", "vw", "xf", "vfncvt_rod_f">;
 }
+
+// Zvfbfmin - Vector convert BF16 to FP32
+let Log2LMUL = [-2, -1, 0, 1, 2],
+OverloadedName = "vfwcvtbf16_f" in
+defm : RVVConvBuiltinSet<"vfwcvtbf16_f_f_v", "y", [["Fw", "Fwv"]]>;

4vtomat wrote:

Yes, we can just define like this~

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

[llvm] [clang] [Clang][CMake] Add CSSPGO support to LLVM_BUILD_INSTRUMENTED (PR #79942)

2024-01-29 Thread Amir Ayupov via cfe-commits


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

[llvm] [clang] [Clang][CMake] Add CSSPGO support to LLVM_BUILD_INSTRUMENTED (PR #79942)

2024-01-29 Thread Amir Ayupov via cfe-commits


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

[flang] [libc] [libcxx] [clang] [llvm] [lldb] [compiler-rt] [lld] [ASan][AMDGPU] Fix Assertion Failure. (PR #79795)

2024-01-29 Thread Matt Arsenault via cfe-commits


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


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

[llvm] [clang] [Clang][CMake] Add CSSPGO support to LLVM_BUILD_INSTRUMENTED (PR #79942)

2024-01-29 Thread via cfe-commits


github-actions[bot] wrote:




:warning: Python code formatter, darker found issues in your code. :warning:



You can test this locally with the following command:


``bash
darker --check --diff -r 
c34aa784f8867517315d8ef32a8038ee9dbb7165...90686f2cd5e210f9ca974c10f8c1224a825c1315
 clang/utils/perf-training/perf-helper.py
``





View the diff from darker here.


``diff
--- perf-helper.py  2024-01-30 04:13:23.00 +
+++ perf-helper.py  2024-01-30 04:20:47.870019 +
@@ -42,11 +42,11 @@
 
 
 def merge(args):
 parser = argparse.ArgumentParser(
 prog="perf-helper merge",
-description="Merges all profraw files from path into output"
+description="Merges all profraw files from path into output",
 )
 parser.add_argument("profdata", help="Path to llvm-profdata tool")
 parser.add_argument("output", help="Output filename")
 parser.add_argument("path", help="Folder containing input profraw files")
 parser.add_argument("--sample", action="store_true", help="Sample profile")
@@ -74,21 +74,18 @@
 
 
 def perf(args):
 parser = argparse.ArgumentParser(
 prog="perf-helper perf",
-description="perf wrapper for BOLT/CSSPGO profile collection"
+description="perf wrapper for BOLT/CSSPGO profile collection",
 )
 parser.add_argument(
 "--lbr", action="store_true", help="Use perf with branch stacks"
 )
-parser.add_argument(
-"--call-graph", action="store_true", help="Collect call graph"
-)
-parser.add_argument(
-"--event", help="PMU event name, defaults to cycles:u",
-default="cycles:u"
+parser.add_argument("--call-graph", action="store_true", help="Collect 
call graph")
+parser.add_argument(
+"--event", help="PMU event name, defaults to cycles:u", 
default="cycles:u"
 )
 parser.add_argument("cmd", nargs=argparse.REMAINDER, help="")
 
 opts = parser.parse_args(args)
 cmd = opts.cmd[1:]
@@ -139,22 +136,23 @@
 return 0
 
 
 def perf2prof(args):
 parser = argparse.ArgumentParser(
-prog="perf-helper perf2prof",
-description="perf to CSSPGO prof conversion wrapper",
-)
+prog="perf-helper perf2prof",
+description="perf to CSSPGO prof conversion wrapper",
+)
 parser.add_argument("profgen", help="Path to llvm-profgen binary")
 parser.add_argument("binary", help="Input binary")
 parser.add_argument("path", help="Path containing perf.data files")
 opts = parser.parse_args(args)
 
 profgen_args = [opts.profgen, f"--binary={opts.binary}"]
 for filename in findFilesWithExtension(opts.path, "perf.data"):
-subprocess.check_call(profgen_args + [f"--perfdata={filename}",
-  f"--output={filename}.profraw"])
+subprocess.check_call(
+profgen_args + [f"--perfdata={filename}", 
f"--output={filename}.profraw"]
+)
 return 0
 
 
 def dtrace(args):
 parser = argparse.ArgumentParser(

``




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

[clang] [RISCV][clang] Add Zvfbfmin C intrinsics support (PR #79618)

2024-01-29 Thread Brandon Wu via cfe-commits


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

[llvm] [clang] [Clang][CMake] Add CSSPGO support to LLVM_BUILD_INSTRUMENTED (PR #79942)

2024-01-29 Thread via cfe-commits


llvmbot wrote:




@llvm/pr-subscribers-clang

Author: Amir Ayupov (aaupov)


Changes

Build on Clang-BOLT infrastructure to collect sample profiles for CSSPGO.
Add clang/cmake/caches/CSSPGO.cmake to automate CSSPGO Clang build.

Differential Revision: https://reviews.llvm.org/D155419

Test Plan:
Added CSSPGO.cmake with same use as PGO.cmake, e.g. for bootstrapped 
ThinLTO+CSSPGO:
```
cmake -B csspgo -S /path/to/llvm-project/llvm \
-DLLVM_ENABLE_LLD=ON -DBOOTSTRAP_LLVM_ENABLE_LLD=ON  \
-DBOOTSTRAP_BOOTSTRAP_LLVM_ENABLE_LLD=ON  \
-DPGO_INSTRUMENT_LTO=Thin \
-GNinja  -C/path/to/llvm-project/clang/cmake/caches/CSSPGO.cmake
ninja stage2
```


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


8 Files Affected:

- (modified) clang/CMakeLists.txt (+11-1) 
- (added) clang/cmake/caches/CSSPGO.cmake (+3) 
- (modified) clang/utils/perf-training/CMakeLists.txt (+30-2) 
- (modified) clang/utils/perf-training/lit.cfg (+6) 
- (modified) clang/utils/perf-training/lit.site.cfg.in (+1) 
- (modified) clang/utils/perf-training/perf-helper.py (+44-10) 
- (modified) llvm/CMakeLists.txt (+3) 
- (modified) llvm/cmake/modules/HandleLLVMOptions.cmake (+25-1) 


``diff
diff --git a/clang/CMakeLists.txt b/clang/CMakeLists.txt
index 47fc2e4886cfc..5d16442ac7bc3 100644
--- a/clang/CMakeLists.txt
+++ b/clang/CMakeLists.txt
@@ -741,11 +741,21 @@ if (CLANG_ENABLE_BOOTSTRAP)
   if(BOOTSTRAP_LLVM_BUILD_INSTRUMENTED)
 add_dependencies(clang-bootstrap-deps llvm-profdata)
 set(PGO_OPT -DLLVM_PROFDATA=${LLVM_RUNTIME_OUTPUT_INTDIR}/llvm-profdata)
+string(TOUPPER "${BOOTSTRAP_LLVM_BUILD_INSTRUMENTED}" 
BOOTSTRAP_LLVM_BUILD_INSTRUMENTED)
+if (BOOTSTRAP_LLVM_BUILD_INSTRUMENTED STREQUAL "CSSPGO")
+  add_dependencies(clang-bootstrap-deps llvm-profgen)
+  list(APPEND PGO_OPT 
-DLLVM_PROFGEN=${LLVM_RUNTIME_OUTPUT_INTDIR}/llvm-profgen)
+endif()
   endif()
 
   if(LLVM_BUILD_INSTRUMENTED)
+string(TOUPPER "${LLVM_BUILD_INSTRUMENTED}" LLVM_BUILD_INSTRUMENTED)
 add_dependencies(clang-bootstrap-deps generate-profdata)
-set(PGO_OPT 
-DLLVM_PROFDATA_FILE=${CMAKE_CURRENT_BINARY_DIR}/utils/perf-training/clang.profdata)
+if (LLVM_BUILD_INSTRUMENTED STREQUAL "CSSPGO")
+  set(PGO_OPT 
-DLLVM_SPROFDATA_FILE=${CMAKE_CURRENT_BINARY_DIR}/utils/perf-training/clang.profdata)
+else()
+  set(PGO_OPT 
-DLLVM_PROFDATA_FILE=${CMAKE_CURRENT_BINARY_DIR}/utils/perf-training/clang.profdata)
+endif()
 # Use the current tools for LTO instead of the instrumented ones
 list(APPEND _BOOTSTRAP_DEFAULT_PASSTHROUGH
   CMAKE_CXX_COMPILER
diff --git a/clang/cmake/caches/CSSPGO.cmake b/clang/cmake/caches/CSSPGO.cmake
new file mode 100644
index 0..34159068d5ea3
--- /dev/null
+++ b/clang/cmake/caches/CSSPGO.cmake
@@ -0,0 +1,3 @@
+set(CMAKE_BUILD_TYPE RelWithDebInfo CACHE STRING "")
+set(BOOTSTRAP_LLVM_BUILD_INSTRUMENTED "CSSPGO" CACHE STRING "")
+include(${CMAKE_CURRENT_LIST_DIR}/PGO.cmake)
diff --git a/clang/utils/perf-training/CMakeLists.txt 
b/clang/utils/perf-training/CMakeLists.txt
index 601f40902fa34..489a097cd49c8 100644
--- a/clang/utils/perf-training/CMakeLists.txt
+++ b/clang/utils/perf-training/CMakeLists.txt
@@ -14,8 +14,33 @@ if(LLVM_BUILD_INSTRUMENTED)
 DEPENDS clang clear-profraw ${CLANG_PERF_TRAINING_DEPS}
 )
 
+  add_custom_target(generate-profdata-deps)
+  string(TOUPPER "${LLVM_BUILD_INSTRUMENTED}" 
uppercase_LLVM_BUILD_INSTRUMENTED)
+  if (uppercase_LLVM_BUILD_INSTRUMENTED STREQUAL "CSSPGO")
+set(PROFDATA_SAMPLE "--sample")
+if(NOT LLVM_PROFGEN)
+  find_program(LLVM_PROFGEN llvm-profgen)
+endif()
+
+if(NOT LLVM_PROFGEN)
+  message(STATUS "To enable converting CSSPGO samples LLVM_PROFGEN has to 
point to llvm-profgen")
+endif()
+
+# Convert perf profiles into profraw
+add_custom_target(convert-perf-profraw
+  COMMAND "${Python3_EXECUTABLE}"
+  ${CMAKE_CURRENT_SOURCE_DIR}/perf-helper.py perf2prof ${LLVM_PROFGEN}
+  $ ${CMAKE_CURRENT_BINARY_DIR}
+  COMMENT "Converting perf profiles into profraw"
+  DEPENDS generate-profraw)
+add_dependencies(generate-profdata-deps convert-perf-profraw)
+  else()
+add_dependencies(generate-profdata-deps generate-profraw)
+  endif()
+
   add_custom_target(clear-profraw
 COMMAND "${Python3_EXECUTABLE}" ${CMAKE_CURRENT_SOURCE_DIR}/perf-helper.py 
clean ${CMAKE_CURRENT_BINARY_DIR} profraw
+COMMAND "${Python3_EXECUTABLE}" ${CMAKE_CURRENT_SOURCE_DIR}/perf-helper.py 
clean ${CMAKE_CURRENT_BINARY_DIR} perf.data
 COMMENT "Clearing old profraw data")
 
   if(NOT LLVM_PROFDATA)
@@ -26,9 +51,12 @@ if(LLVM_BUILD_INSTRUMENTED)
 message(STATUS "To enable merging PGO data LLVM_PROFDATA has to point to 
llvm-profdata")
   else()
 add_custom_target(generate-profdata
-  COMMAND "${Python3_EXECUTABLE}" 
${CMAKE_CURRENT_SOURCE_DIR}/perf-helper.py merge ${LLVM_PROFDATA} 
${CMAKE_CURRENT_BINARY_DIR}/clang.profdata ${CMAKE_CURRENT_BINARY_DIR}
+  COMMAND

[llvm] [clang] [Clang][CMake] Add CSSPGO support to LLVM_BUILD_INSTRUMENTED (PR #79942)

2024-01-29 Thread Amir Ayupov via cfe-commits


https://github.com/aaupov created 
https://github.com/llvm/llvm-project/pull/79942

Build on Clang-BOLT infrastructure to collect sample profiles for CSSPGO.
Add clang/cmake/caches/CSSPGO.cmake to automate CSSPGO Clang build.

Differential Revision: https://reviews.llvm.org/D155419

Test Plan:
Added CSSPGO.cmake with same use as PGO.cmake, e.g. for bootstrapped 
ThinLTO+CSSPGO:
```
cmake -B csspgo -S /path/to/llvm-project/llvm \
-DLLVM_ENABLE_LLD=ON -DBOOTSTRAP_LLVM_ENABLE_LLD=ON  \
-DBOOTSTRAP_BOOTSTRAP_LLVM_ENABLE_LLD=ON  \
-DPGO_INSTRUMENT_LTO=Thin \
-GNinja  -C/path/to/llvm-project/clang/cmake/caches/CSSPGO.cmake
ninja stage2
```


>From 90686f2cd5e210f9ca974c10f8c1224a825c1315 Mon Sep 17 00:00:00 2001
From: Amir Ayupov 
Date: Wed, 19 Jul 2023 20:30:29 -0700
Subject: [PATCH] [Clang][CMake] Add CSSPGO support to LLVM_BUILD_INSTRUMENTED

Build on Clang-BOLT infrastructure to collect sample profiles for CSSPGO.
Add clang/cmake/caches/CSSPGO.cmake to automate CSSPGO Clang build.

Differential Revision: https://reviews.llvm.org/D155419
---
 clang/CMakeLists.txt   | 12 -
 clang/cmake/caches/CSSPGO.cmake|  3 ++
 clang/utils/perf-training/CMakeLists.txt   | 32 -
 clang/utils/perf-training/lit.cfg  |  6 +++
 clang/utils/perf-training/lit.site.cfg.in  |  1 +
 clang/utils/perf-training/perf-helper.py   | 54 ++
 llvm/CMakeLists.txt|  3 ++
 llvm/cmake/modules/HandleLLVMOptions.cmake | 26 ++-
 8 files changed, 123 insertions(+), 14 deletions(-)
 create mode 100644 clang/cmake/caches/CSSPGO.cmake

diff --git a/clang/CMakeLists.txt b/clang/CMakeLists.txt
index 47fc2e4886cfc..5d16442ac7bc3 100644
--- a/clang/CMakeLists.txt
+++ b/clang/CMakeLists.txt
@@ -741,11 +741,21 @@ if (CLANG_ENABLE_BOOTSTRAP)
   if(BOOTSTRAP_LLVM_BUILD_INSTRUMENTED)
 add_dependencies(clang-bootstrap-deps llvm-profdata)
 set(PGO_OPT -DLLVM_PROFDATA=${LLVM_RUNTIME_OUTPUT_INTDIR}/llvm-profdata)
+string(TOUPPER "${BOOTSTRAP_LLVM_BUILD_INSTRUMENTED}" 
BOOTSTRAP_LLVM_BUILD_INSTRUMENTED)
+if (BOOTSTRAP_LLVM_BUILD_INSTRUMENTED STREQUAL "CSSPGO")
+  add_dependencies(clang-bootstrap-deps llvm-profgen)
+  list(APPEND PGO_OPT 
-DLLVM_PROFGEN=${LLVM_RUNTIME_OUTPUT_INTDIR}/llvm-profgen)
+endif()
   endif()
 
   if(LLVM_BUILD_INSTRUMENTED)
+string(TOUPPER "${LLVM_BUILD_INSTRUMENTED}" LLVM_BUILD_INSTRUMENTED)
 add_dependencies(clang-bootstrap-deps generate-profdata)
-set(PGO_OPT 
-DLLVM_PROFDATA_FILE=${CMAKE_CURRENT_BINARY_DIR}/utils/perf-training/clang.profdata)
+if (LLVM_BUILD_INSTRUMENTED STREQUAL "CSSPGO")
+  set(PGO_OPT 
-DLLVM_SPROFDATA_FILE=${CMAKE_CURRENT_BINARY_DIR}/utils/perf-training/clang.profdata)
+else()
+  set(PGO_OPT 
-DLLVM_PROFDATA_FILE=${CMAKE_CURRENT_BINARY_DIR}/utils/perf-training/clang.profdata)
+endif()
 # Use the current tools for LTO instead of the instrumented ones
 list(APPEND _BOOTSTRAP_DEFAULT_PASSTHROUGH
   CMAKE_CXX_COMPILER
diff --git a/clang/cmake/caches/CSSPGO.cmake b/clang/cmake/caches/CSSPGO.cmake
new file mode 100644
index 0..34159068d5ea3
--- /dev/null
+++ b/clang/cmake/caches/CSSPGO.cmake
@@ -0,0 +1,3 @@
+set(CMAKE_BUILD_TYPE RelWithDebInfo CACHE STRING "")
+set(BOOTSTRAP_LLVM_BUILD_INSTRUMENTED "CSSPGO" CACHE STRING "")
+include(${CMAKE_CURRENT_LIST_DIR}/PGO.cmake)
diff --git a/clang/utils/perf-training/CMakeLists.txt 
b/clang/utils/perf-training/CMakeLists.txt
index 601f40902fa34..489a097cd49c8 100644
--- a/clang/utils/perf-training/CMakeLists.txt
+++ b/clang/utils/perf-training/CMakeLists.txt
@@ -14,8 +14,33 @@ if(LLVM_BUILD_INSTRUMENTED)
 DEPENDS clang clear-profraw ${CLANG_PERF_TRAINING_DEPS}
 )
 
+  add_custom_target(generate-profdata-deps)
+  string(TOUPPER "${LLVM_BUILD_INSTRUMENTED}" 
uppercase_LLVM_BUILD_INSTRUMENTED)
+  if (uppercase_LLVM_BUILD_INSTRUMENTED STREQUAL "CSSPGO")
+set(PROFDATA_SAMPLE "--sample")
+if(NOT LLVM_PROFGEN)
+  find_program(LLVM_PROFGEN llvm-profgen)
+endif()
+
+if(NOT LLVM_PROFGEN)
+  message(STATUS "To enable converting CSSPGO samples LLVM_PROFGEN has to 
point to llvm-profgen")
+endif()
+
+# Convert perf profiles into profraw
+add_custom_target(convert-perf-profraw
+  COMMAND "${Python3_EXECUTABLE}"
+  ${CMAKE_CURRENT_SOURCE_DIR}/perf-helper.py perf2prof ${LLVM_PROFGEN}
+  $ ${CMAKE_CURRENT_BINARY_DIR}
+  COMMENT "Converting perf profiles into profraw"
+  DEPENDS generate-profraw)
+add_dependencies(generate-profdata-deps convert-perf-profraw)
+  else()
+add_dependencies(generate-profdata-deps generate-profraw)
+  endif()
+
   add_custom_target(clear-profraw
 COMMAND "${Python3_EXECUTABLE}" ${CMAKE_CURRENT_SOURCE_DIR}/perf-helper.py 
clean ${CMAKE_CURRENT_BINARY_DIR} profraw
+COMMAND "${Python3_EXECUTABLE}" ${CMAKE_CURRENT_SOURCE_DIR}/perf-helper.py 
clean ${CMAKE_CURRENT_BINARY_DIR} perf.data
 COMMENT "Clearing old

[clang] [RISCV][clang] Add Zvfbfwma C intrinsics support (PR #79615)

2024-01-29 Thread Brandon Wu via cfe-commits



@@ -1730,12 +1730,26 @@ let ManualCodegen = [{
 defm vfwnmacc : RVVFloatingWidenTerBuiltinSetRoundingMode;
 defm vfwmsac  : RVVFloatingWidenTerBuiltinSetRoundingMode;
 defm vfwnmsac : RVVFloatingWidenTerBuiltinSetRoundingMode;
+
+// Vector BF16 widening multiply-accumulate
+let Log2LMUL = [-2, -1, 0, 1, 2],

4vtomat wrote:

Yes, we do.

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

[libc] [clang-tools-extra] [libcxxabi] [llvm] [clang] [compiler-rt] [libcxx] [flang] [lld] [CSSPGO] Compute and report post-match profile staleness (PR #79090)

2024-01-29 Thread via cfe-commits



@@ -2460,63 +2528,108 @@ void SampleProfileMatcher::runOnFunction(const 
Function ) {
   !ProbeManager->profileIsValid(F, *FSFlattened)) {
 // The matching result will be saved to IRToProfileLocationMap, create a 
new
 // map for each function.
+auto  = getIRToProfileLocationMap(F);
 runStaleProfileMatching(F, IRAnchors, ProfileAnchors,
-getIRToProfileLocationMap(F));
+IRToProfileLocationMap);
+PostMatchStats.countMismatchedCallsites(F, IRAnchors, ProfileAnchors,
+IRToProfileLocationMap);
   }
 }
 
-void SampleProfileMatcher::runOnModule() {
-  ProfileConverter::flattenProfile(Reader.getProfiles(), FlattenedProfiles,
-   FunctionSamples::ProfileIsCS);
-  for (auto  : M) {
-if (F.isDeclaration() || !F.hasFnAttribute("use-sample-profile"))
-  continue;
-runOnFunction(F);
-  }
-  if (SalvageStaleProfile)
-distributeIRToProfileLocationMap();
-
+void SampleProfileMatcher::reportOrPersistProfileStats() {
   if (ReportProfileStaleness) {
 if (FunctionSamples::ProfileIsProbeBased) {
-  errs() << "(" << NumMismatchedFuncHash << "/" << TotalProfiledFunc << ")"
+  errs() << "(" << PreMatchStats.NumMismatchedFuncHash << "/"
+ << PreMatchStats.TotalProfiledFunc << ")"
  << " of functions' profile are invalid and "
- << " (" << MismatchedFuncHashSamples << "/" << 
TotalFuncHashSamples
- << ")"
+ << " (" << PreMatchStats.MismatchedFuncHashSamples << "/"
+ << PreMatchStats.TotalFunctionSamples << ")"
  << " of samples are discarded due to function hash mismatch.\n";
 }
-errs() << "(" << NumMismatchedCallsites << "/" << TotalProfiledCallsites
-   << ")"
+errs() << "(" << PreMatchStats.NumMismatchedCallsites << "/"
+   << PreMatchStats.TotalProfiledCallsites << ")"
<< " of callsites' profile are invalid and "
-   << "(" << MismatchedCallsiteSamples << "/" << TotalCallsiteSamples
-   << ")"
+   << "(" << PreMatchStats.MismatchedCallsiteSamples << "/"
+   << PreMatchStats.TotalFunctionSamples << ")"
<< " of samples are discarded due to callsite location mismatch.\n";
+if (SalvageStaleProfile) {
+  uint64_t NumRecoveredCallsites = PostMatchStats.TotalProfiledCallsites -
+   PostMatchStats.NumMismatchedCallsites;
+  uint64_t NumMismatchedCallsites =
+  PreMatchStats.NumMismatchedCallsites - NumRecoveredCallsites;
+  errs() << "Out of " << PostMatchStats.TotalProfiledCallsites
+ << " callsites used for profile matching, "
+ << NumRecoveredCallsites
+ << " callsites have been recovered. After the matching, ("
+ << NumMismatchedCallsites << "/"
+ << PreMatchStats.TotalProfiledCallsites
+ << ") of callsites are still invalid ("
+ << PostMatchStats.MismatchedCallsiteSamples << "/"
+ << PreMatchStats.TotalFunctionSamples << ")"
+ << " of samples are still discarded.\n";
+}
   }
 
   if (PersistProfileStaleness) {
 LLVMContext  = M.getContext();
 MDBuilder MDB(Ctx);
 
 SmallVector> ProfStatsVec;
+ProfStatsVec.emplace_back("NumMismatchedCallsites",
+  PreMatchStats.NumMismatchedCallsites);
+ProfStatsVec.emplace_back("TotalProfiledCallsites",
+  PreMatchStats.TotalProfiledCallsites);
+ProfStatsVec.emplace_back("MismatchedCallsiteSamples",
+  PreMatchStats.MismatchedCallsiteSamples);
+ProfStatsVec.emplace_back("TotalProfiledFunc",
+  PreMatchStats.TotalProfiledFunc);
+ProfStatsVec.emplace_back("TotalFunctionSamples",
+  PreMatchStats.TotalFunctionSamples);
 if (FunctionSamples::ProfileIsProbeBased) {
-  ProfStatsVec.emplace_back("NumMismatchedFuncHash", 
NumMismatchedFuncHash);
-  ProfStatsVec.emplace_back("TotalProfiledFunc", TotalProfiledFunc);
+  ProfStatsVec.emplace_back("NumMismatchedFuncHash",
+PreMatchStats.NumMismatchedFuncHash);
   ProfStatsVec.emplace_back("MismatchedFuncHashSamples",
-MismatchedFuncHashSamples);
-  ProfStatsVec.emplace_back("TotalFuncHashSamples", TotalFuncHashSamples);
+PreMatchStats.MismatchedFuncHashSamples);
+}
+if (SalvageStaleProfile) {
+  ProfStatsVec.emplace_back("PostMatchNumMismatchedCallsites",
+PostMatchStats.NumMismatchedCallsites);
+  ProfStatsVec.emplace_back("NumCallsitesForMatching",
+PostMatchStats.TotalProfiledCallsites);
+  ProfStatsVec.emplace_back("PostMatchMismatchedCallsiteSamples",
+

[libc] [clang-tools-extra] [mlir] [llvm] [clang] [lldb] [compiler-rt] [libcxx] [flang] [lld] fix vulnerabilities (PR #79697)

2024-01-29 Thread via cfe-commits


https://github.com/NxPKG updated https://github.com/llvm/llvm-project/pull/79697

>From f7b4f61db6016a1a02d775efc1e921fac785e823 Mon Sep 17 00:00:00 2001
From: snyk-bot 
Date: Fri, 19 Jan 2024 07:12:22 +
Subject: [PATCH 1/6] feat: upgrade vscode-languageclient from 8.0.2-next.5 to
 9.0.1

Snyk has created this PR to upgrade vscode-languageclient from 8.0.2-next.5 to 
9.0.1.

See this package in npm:
https://www.npmjs.com/package/vscode-languageclient

See this project in Snyk:
https://app.snyk.io/org/gitaction-log4j/project/a71a1b94-9555-4c53-b459-4ef6c4d3545e?utm_source=github_medium=referral=upgrade-pr
---
 mlir/utils/vscode/package-lock.json | 117 +++-
 mlir/utils/vscode/package.json  |   2 +-
 2 files changed, 80 insertions(+), 39 deletions(-)

diff --git a/mlir/utils/vscode/package-lock.json 
b/mlir/utils/vscode/package-lock.json
index c93f6167c80a1..7d573b63fcca1 100644
--- a/mlir/utils/vscode/package-lock.json
+++ b/mlir/utils/vscode/package-lock.json
@@ -10,7 +10,7 @@
   "dependencies": {
 "base64-js": "^1.5.1",
 "chokidar": "3.5.2",
-"vscode-languageclient": "^8.0.2-next.5"
+"vscode-languageclient": "^9.0.1"
   },
   "devDependencies": {
 "@types/mocha": "^7.0.2",
@@ -279,6 +279,7 @@
   "version": "1.1.11",
   "resolved": 
"https://registry.npmjs.org/brace-expansion/-/brace-expansion-1.1.11.tgz;,
   "integrity": 
"sha512-iCuPHDFgrHX7H2vEI/5xpz07zSHB00TpugqhmYtVmMO6518mCuRMoOYFldEBl0g187ufozdaHgWKcYFb61qGiA==",
+  "dev": true,
   "dependencies": {
 "balanced-match": "^1.0.0",
 "concat-map": "0.0.1"
@@ -509,7 +510,8 @@
 "node_modules/concat-map": {
   "version": "0.0.1",
   "resolved": 
"https://registry.npmjs.org/concat-map/-/concat-map-0.0.1.tgz;,
-  "integrity": "sha1-2Klr13/Wjfd5OnMDajug1UBdR3s="
+  "integrity": "sha1-2Klr13/Wjfd5OnMDajug1UBdR3s=",
+  "dev": true
 },
 "node_modules/console-control-strings": {
   "version": "1.1.0",
@@ -1198,6 +1200,7 @@
   "version": "3.0.4",
   "resolved": "https://registry.npmjs.org/minimatch/-/minimatch-3.0.4.tgz;,
   "integrity": 
"sha512-yJHVQEhyqPLUTgt9B83PXu6W3rx4MvvHvSUvToogpwoGDOUQ+yDrR0HRot+yOCdCO7u4hX3pWft6kWBBcqh0UA==",
+  "dev": true,
   "dependencies": {
 "brace-expansion": "^1.1.7"
   },
@@ -1881,24 +1884,43 @@
   "dev": true
 },
 "node_modules/vscode-jsonrpc": {
-  "version": "8.0.2-next.1",
-  "resolved": 
"https://registry.npmjs.org/vscode-jsonrpc/-/vscode-jsonrpc-8.0.2-next.1.tgz;,
-  "integrity": 
"sha512-sbbvGSWja7NVBLHPGawtgezc8DHYJaP4qfr/AaJiyDapWcSFtHyPtm18+LnYMLTmB7bhOUW/lf5PeeuLpP6bKA==",
+  "version": "8.2.0",
+  "resolved": 
"https://registry.npmjs.org/vscode-jsonrpc/-/vscode-jsonrpc-8.2.0.tgz;,
+  "integrity": 
"sha512-C+r0eKJUIfiDIfwJhria30+TYWPtuHJXHtI7J0YlOmKAo7ogxP20T0zxB7HZQIFhIyvoBPwWskjxrvAtfjyZfA==",
   "engines": {
 "node": ">=14.0.0"
   }
 },
 "node_modules/vscode-languageclient": {
-  "version": "8.0.2-next.5",
-  "resolved": 
"https://registry.npmjs.org/vscode-languageclient/-/vscode-languageclient-8.0.2-next.5.tgz;,
-  "integrity": 
"sha512-g87RJLHz0XlRyk6DOTbAk4JHcj8CKggXy4JiFL7OlhETkcYzTOR8d+Qdb4GqZr37PDs1Cl21omtTNK5LyR/RQg==",
+  "version": "9.0.1",
+  "resolved": 
"https://registry.npmjs.org/vscode-languageclient/-/vscode-languageclient-9.0.1.tgz;,
+  "integrity": 
"sha512-JZiimVdvimEuHh5olxhxkht09m3JzUGwggb5eRUkzzJhZ2KjCN0nh55VfiED9oez9DyF8/fz1g1iBV3h+0Z2EA==",
   "dependencies": {
-"minimatch": "^3.0.4",
-"semver": "^7.3.5",
-"vscode-languageserver-protocol": "3.17.2-next.6"
+"minimatch": "^5.1.0",
+"semver": "^7.3.7",
+"vscode-languageserver-protocol": "3.17.5"
   },
   "engines": {
-"vscode": "^1.67.0"
+"vscode": "^1.82.0"
+  }
+},
+"node_modules/vscode-languageclient/node_modules/brace-expansion": {
+  "version": "2.0.1",
+  "resolved": 
"https://registry.npmjs.org/brace-expansion/-/brace-expansion-2.0.1.tgz;,
+  "integrity": 
"sha512-XnAIvQ8eM+kC6aULx6wuQiwVsnzsi9d3WxzV3FpWTGA19F621kwdbsAcFKXgKUHZWsy+mY6iL1sHTxWEFCytDA==",
+  "dependencies": {
+"balanced-match": "^1.0.0"
+  }
+},
+"node_modules/vscode-languageclient/node_modules/minimatch": {
+  "version": "5.1.6",
+  "resolved": "https://registry.npmjs.org/minimatch/-/minimatch-5.1.6.tgz;,
+  "integrity": 
"sha512-lKwV/1brpG6mBUFHtb7NUmtABCb2WZZmm2wNiOA5hAb8VdCS4B3dtMWyvcoViccwAW/COERjXLt0zP1zXUN26g==",
+  "dependencies": {
+"brace-expansion": "^2.0.1"
+  },
+  "engines": {
+"node": ">=10"
   }
 },
 "node_modules/vscode-languageclient/node_modules/semver": {
@@ -1916,18 +1938,18 @@
   }
 },
 "node_modules/vscode-languageserver-protocol": {
-  "version": "3.17.2-next.6",
-  "resolved":

[clang] [clang][Sema] Warn on self move for inlined static cast (PR #76646)

2024-01-29 Thread Max Winkler via cfe-commits


MaxEW707 wrote:

Ping

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

[clang] [RISCV][clang] Add Zvfbfwma C intrinsics support (PR #79615)

2024-01-29 Thread Brandon Wu via cfe-commits



@@ -0,0 +1,479 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py 
UTC_ARGS: --version 4
+// REQUIRES: riscv-registered-target
+// RUN: %clang_cc1 -triple riscv64 -target-feature +v -target-feature +zfh \
+// RUN:   -target-feature +zvfh -target-feature +experimental-zvfbfwma 
-disable-O0-optnone  \

4vtomat wrote:

No, it doesn't, I just copied the test cases from 
[this](https://github.com/riscv-non-isa/rvv-intrinsic-doc/pull/293) lol. I will 
remove it though.

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

[clang] [clang][analyzer] Improve modeling of 'realpath' in StdLibraryFunctionsChecker (PR #79939)

2024-01-29 Thread via cfe-commits


llvmbot wrote:




@llvm/pr-subscribers-clang-static-analyzer-1

Author: Ben Shi (benshi001)


Changes



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


2 Files Affected:

- (modified) clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp 
(+4-2) 
- (modified) clang/test/Analysis/errno-stdlibraryfunctions.c (+10) 


``diff
diff --git a/clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp 
b/clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp
index be26f5521c8d7..3bcde86c9e66f 100644
--- a/clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp
+++ b/clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp
@@ -2992,12 +2992,14 @@ void StdLibraryFunctionsChecker::initFunctionSummaries(
 
 // char *realpath(const char *restrict file_name,
 //char *restrict resolved_name);
-// FIXME: Improve for errno modeling.
 addToFunctionSummaryMap(
 "realpath",
 Signature(ArgTypes{ConstCharPtrRestrictTy, CharPtrRestrictTy},
   RetType{CharPtrTy}),
-Summary(NoEvalCall).ArgConstraint(NotNull(ArgNo(0;
+Summary(NoEvalCall)
+.Case({NotNull(Ret)}, ErrnoMustNotBeChecked, GenericSuccessMsg)
+.Case({IsNull(Ret)}, ErrnoNEZeroIrrelevant, GenericFailureMsg)
+.ArgConstraint(NotNull(ArgNo(0;
 
 QualType CharPtrConstPtr = getPointerTy(getConstTy(CharPtrTy));
 
diff --git a/clang/test/Analysis/errno-stdlibraryfunctions.c 
b/clang/test/Analysis/errno-stdlibraryfunctions.c
index 9b487fed0a2eb..a28efb764edfd 100644
--- a/clang/test/Analysis/errno-stdlibraryfunctions.c
+++ b/clang/test/Analysis/errno-stdlibraryfunctions.c
@@ -128,3 +128,13 @@ void errno_pclose(void) {
 if (errno) {} // expected-warning{{An undefined value may be read from 
'errno'}}
   }
 }
+
+void errno_realpath(char *Path, char *Buf) {
+  char *Ret = realpath(Path, Buf);
+  if (!Ret) {
+clang_analyzer_eval(errno != 0);  // expected-warning{{TRUE}}
+if (errno) {} // no-warning
+  } else {
+if (errno) {} // expected-warning{{An undefined value may be read from 
'errno'}}
+  }
+}

``




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

[clang] [clang][analyzer] Improve modeling of 'realpath' in StdLibraryFunctionsChecker (PR #79939)

2024-01-29 Thread via cfe-commits


llvmbot wrote:




@llvm/pr-subscribers-clang

Author: Ben Shi (benshi001)


Changes



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


2 Files Affected:

- (modified) clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp 
(+4-2) 
- (modified) clang/test/Analysis/errno-stdlibraryfunctions.c (+10) 


``diff
diff --git a/clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp 
b/clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp
index be26f5521c8d7..3bcde86c9e66f 100644
--- a/clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp
+++ b/clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp
@@ -2992,12 +2992,14 @@ void StdLibraryFunctionsChecker::initFunctionSummaries(
 
 // char *realpath(const char *restrict file_name,
 //char *restrict resolved_name);
-// FIXME: Improve for errno modeling.
 addToFunctionSummaryMap(
 "realpath",
 Signature(ArgTypes{ConstCharPtrRestrictTy, CharPtrRestrictTy},
   RetType{CharPtrTy}),
-Summary(NoEvalCall).ArgConstraint(NotNull(ArgNo(0;
+Summary(NoEvalCall)
+.Case({NotNull(Ret)}, ErrnoMustNotBeChecked, GenericSuccessMsg)
+.Case({IsNull(Ret)}, ErrnoNEZeroIrrelevant, GenericFailureMsg)
+.ArgConstraint(NotNull(ArgNo(0;
 
 QualType CharPtrConstPtr = getPointerTy(getConstTy(CharPtrTy));
 
diff --git a/clang/test/Analysis/errno-stdlibraryfunctions.c 
b/clang/test/Analysis/errno-stdlibraryfunctions.c
index 9b487fed0a2eb..a28efb764edfd 100644
--- a/clang/test/Analysis/errno-stdlibraryfunctions.c
+++ b/clang/test/Analysis/errno-stdlibraryfunctions.c
@@ -128,3 +128,13 @@ void errno_pclose(void) {
 if (errno) {} // expected-warning{{An undefined value may be read from 
'errno'}}
   }
 }
+
+void errno_realpath(char *Path, char *Buf) {
+  char *Ret = realpath(Path, Buf);
+  if (!Ret) {
+clang_analyzer_eval(errno != 0);  // expected-warning{{TRUE}}
+if (errno) {} // no-warning
+  } else {
+if (errno) {} // expected-warning{{An undefined value may be read from 
'errno'}}
+  }
+}

``




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

[clang] [clang][analyzer] Improve modeling of 'realpath' in StdLibraryFunctionsChecker (PR #79939)

2024-01-29 Thread Ben Shi via cfe-commits


https://github.com/benshi001 created 
https://github.com/llvm/llvm-project/pull/79939

None

>From 5bbac365c3b587bc72f503c4ce146503f0d0095f Mon Sep 17 00:00:00 2001
From: Ben Shi 
Date: Tue, 30 Jan 2024 11:45:30 +0800
Subject: [PATCH] [clang][analyzer] Improve modeling of 'realpath' in
 StdLibraryFunctionsChecker

---
 .../Checkers/StdLibraryFunctionsChecker.cpp|  6 --
 clang/test/Analysis/errno-stdlibraryfunctions.c| 10 ++
 2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp 
b/clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp
index be26f5521c8d7..3bcde86c9e66f 100644
--- a/clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp
+++ b/clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp
@@ -2992,12 +2992,14 @@ void StdLibraryFunctionsChecker::initFunctionSummaries(
 
 // char *realpath(const char *restrict file_name,
 //char *restrict resolved_name);
-// FIXME: Improve for errno modeling.
 addToFunctionSummaryMap(
 "realpath",
 Signature(ArgTypes{ConstCharPtrRestrictTy, CharPtrRestrictTy},
   RetType{CharPtrTy}),
-Summary(NoEvalCall).ArgConstraint(NotNull(ArgNo(0;
+Summary(NoEvalCall)
+.Case({NotNull(Ret)}, ErrnoMustNotBeChecked, GenericSuccessMsg)
+.Case({IsNull(Ret)}, ErrnoNEZeroIrrelevant, GenericFailureMsg)
+.ArgConstraint(NotNull(ArgNo(0;
 
 QualType CharPtrConstPtr = getPointerTy(getConstTy(CharPtrTy));
 
diff --git a/clang/test/Analysis/errno-stdlibraryfunctions.c 
b/clang/test/Analysis/errno-stdlibraryfunctions.c
index 9b487fed0a2eb..a28efb764edfd 100644
--- a/clang/test/Analysis/errno-stdlibraryfunctions.c
+++ b/clang/test/Analysis/errno-stdlibraryfunctions.c
@@ -128,3 +128,13 @@ void errno_pclose(void) {
 if (errno) {} // expected-warning{{An undefined value may be read from 
'errno'}}
   }
 }
+
+void errno_realpath(char *Path, char *Buf) {
+  char *Ret = realpath(Path, Buf);
+  if (!Ret) {
+clang_analyzer_eval(errno != 0);  // expected-warning{{TRUE}}
+if (errno) {} // no-warning
+  } else {
+if (errno) {} // expected-warning{{An undefined value may be read from 
'errno'}}
+  }
+}

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

[clang] [RISCV][clang] Add Zvfbfmin C intrinsics support (PR #79618)

2024-01-29 Thread Brandon Wu via cfe-commits



@@ -1883,6 +1883,12 @@ let Log2LMUL = [-3, -2, -1, 0, 1, 2] in {
   def vfncvt_rtz_x_f_w : RVVConvToNarrowingSignedBuiltin<"vfncvt_rtz_x">;
   def vfncvt_rod_f_f_w : RVVConvBuiltin<"v", "vw", "xf", "vfncvt_rod_f">;
 }
+
+// Zvfbfmin - Vector convert BF16 to FP32
+let Log2LMUL = [-2, -1, 0, 1, 2],
+OverloadedName = "vfwcvtbf16_f" in
+defm : RVVConvBuiltinSet<"vfwcvtbf16_f_f_v", "y", [["Fw", "Fwv"]]>;

4vtomat wrote:

There are two same definitions in this scope, one has `HasFRMRoundModeOp` and 
the other doesn't. If we define the name then it causes the redefinition error.

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

[clang] [RISCV][clang] Add Zvfbfmin C intrinsics support (PR #79618)

2024-01-29 Thread Jim Lin via cfe-commits



@@ -1883,6 +1883,12 @@ let Log2LMUL = [-3, -2, -1, 0, 1, 2] in {
   def vfncvt_rtz_x_f_w : RVVConvToNarrowingSignedBuiltin<"vfncvt_rtz_x">;
   def vfncvt_rod_f_f_w : RVVConvBuiltin<"v", "vw", "xf", "vfncvt_rod_f">;
 }
+
+// Zvfbfmin - Vector convert BF16 to FP32
+let Log2LMUL = [-2, -1, 0, 1, 2],

tclin914 wrote:

Ok, It can't declare a bfloat16 vector without Zvfbfmin extension. Thanks for 
explanation.

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

[clang] [polly] [clang-format] Add AllowShortType option for AlwaysBreakAfterReturnType. (PR #78011)

2024-01-29 Thread via cfe-commits

rmarker wrote:

> > > @mydeveloperday @HazardyKnusperkeks @rymiel this patch fixes a very old 
> > > bug and will cause behavior changes whether the default is changed to the 
> > > new `AllowShortType` or left at `None`. Which way should we go?
> > 
> > 
> > Now I'm leaning toward keeping the existing (buggy) behavior of `None` and 
> > using the new `AllowShortType` to allow wrapping after short return types.
> 
> Buggy would be no break? That would be what I expect from `None`. :) So +1 
> from me.

`None` prevents breaks after short return types. The buggy behaviour is that it 
doesn't take leading indentation into account when determining if a return type 
is short or not. This means that if there is indentation, it wouldn't think a 
type is short that otherwise would be, and would thus allow a break after the 
return type.
Fixing the bug would cause return types in more situations to be identified as 
short and thus prevent breaks previously allowed (changing the previous 
behaviour).

 ```
 // Buggy None
void LongName::
  AnotherLongName();
class C {
   void
   LongName::AnotherLongName();
};

// Fixed None
void LongName::
  AnotherLongName();
class C {
   void LongName::
AnotherLongName();
};
 ```

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

[compiler-rt] [mlir] [lld] [clang] [libcxx] [libc] [lldb] [llvm] [flang] [mlir][sparse] Expand LevelType to 64 bits and implement n out of m (PR #79935)

2024-01-29 Thread Yinying Li via cfe-commits


https://github.com/yinying-lisa-li updated 
https://github.com/llvm/llvm-project/pull/79935

>From fa5210448dea1f88d8e0a242543ad1be655087e0 Mon Sep 17 00:00:00 2001
From: Yinying Li 
Date: Tue, 30 Jan 2024 01:01:52 +
Subject: [PATCH 1/3] [mlir][sparse] Expand LevelType to 64 bit and implement n
 out of m

---
 mlir/include/mlir-c/Dialect/SparseTensor.h|  28 +--
 .../mlir/Dialect/SparseTensor/IR/Enums.h  | 225 +++---
 .../SparseTensor/IR/SparseTensorAttrDefs.td   |   4 +-
 .../SparseTensor/IR/SparseTensorType.h|   2 +-
 .../mlir/Dialect/SparseTensor/Utils/Merger.h  |   2 +-
 .../ExecutionEngine/SparseTensor/Storage.h|  14 +-
 .../Bindings/Python/DialectSparseTensor.cpp   |   2 +-
 mlir/lib/CAPI/Dialect/SparseTensor.cpp|  49 ++--
 .../IR/Detail/DimLvlMapParser.cpp |   2 +
 .../SparseTensor/IR/Detail/LvlTypeParser.cpp  |  55 -
 .../SparseTensor/IR/Detail/LvlTypeParser.h|   6 +-
 .../Transforms/SparseGPUCodegen.cpp   |   2 +-
 .../Transforms/SparseTensorCodegen.cpp|   6 +-
 .../Transforms/Sparsification.cpp |   2 +-
 .../Transforms/Utils/CodegenUtils.h   |   2 +-
 .../Transforms/Utils/SparseTensorLevel.cpp|   2 +-
 .../lib/Dialect/SparseTensor/Utils/Merger.cpp |   4 +-
 .../ExecutionEngine/SparseTensor/Storage.cpp  |   2 +-
 mlir/test/CAPI/sparse_tensor.c|   6 +-
 .../SparseTensor/GPU/gpu_matmul24_lib.mlir|   2 +-
 .../test/Dialect/SparseTensor/conversion.mlir |  16 +-
 .../SparseTensor/roundtrip_encoding.mlir  |  12 +-
 .../SparseTensor/sparse_fill_zero.mlir|  12 +-
 .../SparseTensor/CPU/sparse_block_matmul.mlir |   2 +-
 .../Dialect/SparseTensor/CPU/sparse_ds.mlir   |   2 +-
 .../CUDA/sm80-lt/sparse-matmul-2-4-lib.mlir   |   2 +-
 .../CUDA/sm80-lt/sparse-matmul-2-4-prune.mlir |   2 +-
 .../python/dialects/sparse_tensor/dialect.py  | 148 ++--
 28 files changed, 358 insertions(+), 255 deletions(-)

diff --git a/mlir/include/mlir-c/Dialect/SparseTensor.h 
b/mlir/include/mlir-c/Dialect/SparseTensor.h
index 41d024db04964..5fc1f51452482 100644
--- a/mlir/include/mlir-c/Dialect/SparseTensor.h
+++ b/mlir/include/mlir-c/Dialect/SparseTensor.h
@@ -26,20 +26,20 @@ MLIR_DECLARE_CAPI_DIALECT_REGISTRATION(SparseTensor, 
sparse_tensor);
 /// If updating, keep them in sync and update the static_assert in the impl
 /// file.
 enum MlirSparseTensorLevelType {
-  MLIR_SPARSE_TENSOR_LEVEL_DENSE = 4,   // 0b1_00
-  MLIR_SPARSE_TENSOR_LEVEL_COMPRESSED = 8,  // 0b00010_00
-  MLIR_SPARSE_TENSOR_LEVEL_COMPRESSED_NU = 9,   // 0b00010_01
-  MLIR_SPARSE_TENSOR_LEVEL_COMPRESSED_NO = 10,  // 0b00010_10
-  MLIR_SPARSE_TENSOR_LEVEL_COMPRESSED_NU_NO = 11,   // 0b00010_11
-  MLIR_SPARSE_TENSOR_LEVEL_SINGLETON = 16,  // 0b00100_00
-  MLIR_SPARSE_TENSOR_LEVEL_SINGLETON_NU = 17,   // 0b00100_01
-  MLIR_SPARSE_TENSOR_LEVEL_SINGLETON_NO = 18,   // 0b00100_10
-  MLIR_SPARSE_TENSOR_LEVEL_SINGLETON_NU_NO = 19,// 0b00100_11
-  MLIR_SPARSE_TENSOR_LEVEL_LOOSE_COMPRESSED = 32,   // 0b01000_00
-  MLIR_SPARSE_TENSOR_LEVEL_LOOSE_COMPRESSED_NU = 33,// 0b01000_01
-  MLIR_SPARSE_TENSOR_LEVEL_LOOSE_COMPRESSED_NO = 34,// 0b01000_10
-  MLIR_SPARSE_TENSOR_LEVEL_LOOSE_COMPRESSED_NU_NO = 35, // 0b01000_11
-  MLIR_SPARSE_TENSOR_LEVEL_TWO_OUT_OF_FOUR = 64,// 0b1_00
+  MLIR_SPARSE_TENSOR_LEVEL_DENSE = 65536,   // 
0x00_00_0001_
+  MLIR_SPARSE_TENSOR_LEVEL_COMPRESSED = 131072, // 
0x00_00_0002_
+  MLIR_SPARSE_TENSOR_LEVEL_COMPRESSED_NU = 131073,  // 
0x00_00_0002_0001
+  MLIR_SPARSE_TENSOR_LEVEL_COMPRESSED_NO = 131074,  // 
0x00_00_0002_0002
+  MLIR_SPARSE_TENSOR_LEVEL_COMPRESSED_NU_NO = 131075,   // 
0x00_00_0002_0003
+  MLIR_SPARSE_TENSOR_LEVEL_SINGLETON = 262144,  // 
0x00_00_0004_
+  MLIR_SPARSE_TENSOR_LEVEL_SINGLETON_NU = 262145,   // 
0x00_00_0004_0001
+  MLIR_SPARSE_TENSOR_LEVEL_SINGLETON_NO = 262146,   // 
0x00_00_0004_0002
+  MLIR_SPARSE_TENSOR_LEVEL_SINGLETON_NU_NO = 262147,// 
0x00_00_0004_0003
+  MLIR_SPARSE_TENSOR_LEVEL_LOOSE_COMPRESSED = 524288,   // 
0x00_00_0008_
+  MLIR_SPARSE_TENSOR_LEVEL_LOOSE_COMPRESSED_NU = 524289,// 
0x00_00_0008_0001
+  MLIR_SPARSE_TENSOR_LEVEL_LOOSE_COMPRESSED_NO = 524290,// 
0x00_00_0008_0002
+  MLIR_SPARSE_TENSOR_LEVEL_LOOSE_COMPRESSED_NU_NO = 524291, // 
0x00_00_0008_0003
+  MLIR_SPARSE_TENSOR_LEVEL_N_OUT_OF_M = 1048576,// 
0x00_00_0010_
 };
 
 
//===--===//
diff --git a/mlir/include/mlir/Dialect/SparseTensor/IR/Enums.h 
b/mlir/include/mlir/Dialect/SparseTensor/IR/Enums.h
index ac91bfa5ae622..6ddc9326179fe 100644
--- a/mlir/include/mlir/Dialect/SparseTensor/IR/Enums.h
+++ b/mlir/include/mlir/Dialect/SparseTensor/IR/Enums.h
@@ -154,9 +154,10 @@ enum class Action : uint32_t {
 
 ///

[llvm] [compiler-rt] [clang] [clang-repl] [ORC] Add support for out-of-process execution on ELF (PR #79936)

2024-01-29 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 bc7a3bd864be696217c4d11eddf16bed7646b60f 
158cc5ec91bf085ec9914de26a1554606a1e3338 -- 
clang/test/Interpreter/out-of-process.cpp 
clang/include/clang/Interpreter/Interpreter.h 
clang/lib/Interpreter/IncrementalExecutor.cpp 
clang/lib/Interpreter/IncrementalExecutor.h 
clang/lib/Interpreter/Interpreter.cpp 
clang/test/Interpreter/dynamic-library.cpp clang/tools/clang-repl/ClangRepl.cpp 
compiler-rt/lib/orc/dlfcn_wrapper.cpp compiler-rt/lib/orc/elfnix_platform.cpp 
compiler-rt/lib/orc/elfnix_platform.h 
llvm/lib/ExecutionEngine/Orc/ELFNixPlatform.cpp 
llvm/lib/ExecutionEngine/Orc/LLJIT.cpp
``





View the diff from clang-format here.


``diff
diff --git a/clang/include/clang/Interpreter/Interpreter.h 
b/clang/include/clang/Interpreter/Interpreter.h
index 314beb7b72d..c1e63a9cdb6 100644
--- a/clang/include/clang/Interpreter/Interpreter.h
+++ b/clang/include/clang/Interpreter/Interpreter.h
@@ -107,7 +107,8 @@ public:
   static llvm::Expected>
   createWithOutOfProcessExecutor(
   std::unique_ptr CI,
-  std::unique_ptr EI, llvm::StringRef 
OrcRuntimePath);
+  std::unique_ptr EI,
+  llvm::StringRef OrcRuntimePath);
   const ASTContext () const;
   ASTContext ();
   const CompilerInstance *getCompilerInstance() const;
diff --git a/clang/lib/Interpreter/IncrementalExecutor.cpp 
b/clang/lib/Interpreter/IncrementalExecutor.cpp
index 30b24caa4a5..3da8d24606c 100644
--- a/clang/lib/Interpreter/IncrementalExecutor.cpp
+++ b/clang/lib/Interpreter/IncrementalExecutor.cpp
@@ -66,7 +66,8 @@ 
IncrementalExecutor::IncrementalExecutor(llvm::orc::ThreadSafeContext ,
 IncrementalExecutor::IncrementalExecutor(
 llvm::orc::ThreadSafeContext , llvm::Error ,
 const clang::TargetInfo ,
-std::unique_ptr EPC, llvm::StringRef 
OrcRuntimePath)
+std::unique_ptr EPC,
+llvm::StringRef OrcRuntimePath)
 : TSCtx(TSC) {
   using namespace llvm::orc;
   llvm::ErrorAsOutParameter EAO();
@@ -82,7 +83,8 @@ IncrementalExecutor::IncrementalExecutor(
 return llvm::Error::success();
   });
   Builder.setExecutorProcessControl(std::move(EPC));
-  
Builder.setPlatformSetUp(llvm::orc::ExecutorNativePlatform(OrcRuntimePath.str()));
+  Builder.setPlatformSetUp(
+  llvm::orc::ExecutorNativePlatform(OrcRuntimePath.str()));
 
   if (auto JitOrErr = Builder.create()) {
 Jit = std::move(*JitOrErr);
diff --git a/clang/lib/Interpreter/IncrementalExecutor.h 
b/clang/lib/Interpreter/IncrementalExecutor.h
index a73ba903518..6d75594793e 100644
--- a/clang/lib/Interpreter/IncrementalExecutor.h
+++ b/clang/lib/Interpreter/IncrementalExecutor.h
@@ -48,7 +48,8 @@ public:
   const clang::TargetInfo );
   IncrementalExecutor(llvm::orc::ThreadSafeContext , llvm::Error ,
   const clang::TargetInfo ,
-  std::unique_ptr EPC, 
llvm::StringRef OrcRuntimePath);
+  std::unique_ptr EPC,
+  llvm::StringRef OrcRuntimePath);
   ~IncrementalExecutor();
 
   llvm::Error addModule(PartialTranslationUnit );
diff --git a/clang/lib/Interpreter/Interpreter.cpp 
b/clang/lib/Interpreter/Interpreter.cpp
index 13e6be3b54a..5953afbb17f 100644
--- a/clang/lib/Interpreter/Interpreter.cpp
+++ b/clang/lib/Interpreter/Interpreter.cpp
@@ -244,7 +244,7 @@ Interpreter::~Interpreter() {
   toString(std::move(Err)));
   }
 
-if (EPC) {
+  if (EPC) {
 if (auto Err = EPC->disconnect()) {
   llvm::report_fatal_error(
   llvm::Twine("Failed to clean up EPC (IncrementalExecutor has not yet 
"
@@ -325,11 +325,11 @@ 
Interpreter::createWithCUDA(std::unique_ptr CI,
   return Interp;
 }
 
-
 llvm::Expected>
 Interpreter::createWithOutOfProcessExecutor(
 std::unique_ptr CI,
-std::unique_ptr EI, llvm::StringRef 
OrcRuntimePath) {
+std::unique_ptr EI,
+llvm::StringRef OrcRuntimePath) {
   auto Interp = create(std::move(CI));
   if (auto E = Interp.takeError()) {
 return std::move(E);
@@ -389,8 +389,8 @@ llvm::Error Interpreter::CreateExecutor() {
   llvm::Error Err = llvm::Error::success();
   std::unique_ptr Executor;
   if (EPC) {
-Executor =
-std::make_unique(*TSCtx, Err, TI, std::move(EPC), 
OrcRuntimePath);
+Executor = std::make_unique(
+*TSCtx, Err, TI, std::move(EPC), OrcRuntimePath);
   } else {
 Executor = std::make_unique(*TSCtx, Err, TI);
   }
diff --git a/clang/tools/clang-repl/ClangRepl.cpp 
b/clang/tools/clang-repl/ClangRepl.cpp
index 1c43e7b5036..9f45910ed64 100644
--- a/clang/tools/clang-repl/ClangRepl.cpp
+++ b/clang/tools/clang-repl/ClangRepl.cpp
@@ -63,10 +63,9 @@ static llvm::cl::opt 
OutOfProcessExecutorConnect(
 "oop-executor-connect",
 llvm::cl::desc("Connect to an out-of-process executor via TCP"),
 llvm::cl::cat(OOPCategory));

[clang] [llvm] [compiler-rt] [clang-repl] [ORC] Add support for out-of-process execution on ELF (PR #79936)

2024-01-29 Thread via cfe-commits


llvmbot wrote:




@llvm/pr-subscribers-clang

Author: None (jameshu15869)


Changes

This PR adds initial support for out-of-process execution through 
llvm-jitlink-executor to clang-repl on ELF. The out-of-process executor can be 
invoked with "-oop-executor" or "-oop-executor-connect=host" on ELF 
platforms. Now, clang-repl depends upon the ORC runtime to support static 
initializers and deinitializers. 

This PR modifies the ORC ELFNix platform to allow JITDylibs to be reinitialized 
through the "__orc_rt_jit_dlupdate" function, since clang-repl incrementally 
adds static initializers to a single JITDylib. 

On x86_64 linux, the following tests pass with the out-of-process executor 
flag. However, a new new testing file (out-of-process.cpp) was added with 
select tests to restrict the test to ELF only. 

- code-undo.cpp
- const.cpp
- execute-stmts.cpp
- execute-weak.cpp
- global-dtor.cpp
- incremental-mode.cpp
- inline-virtual.cpp
- lambda.cpp
- multiline.cpp
- sanity.cpp

---

Patch is 28.44 KiB, truncated to 20.00 KiB below, full version: 
https://github.com/llvm/llvm-project/pull/79936.diff


13 Files Affected:

- (modified) clang/include/clang/Interpreter/Interpreter.h (+10) 
- (modified) clang/lib/Interpreter/IncrementalExecutor.cpp (+29) 
- (modified) clang/lib/Interpreter/IncrementalExecutor.h (+3) 
- (modified) clang/lib/Interpreter/Interpreter.cpp (+33-5) 
- (modified) clang/test/Interpreter/dynamic-library.cpp (+1) 
- (added) clang/test/Interpreter/out-of-process.cpp (+61) 
- (modified) clang/tools/clang-repl/CMakeLists.txt (+2) 
- (modified) clang/tools/clang-repl/ClangRepl.cpp (+230) 
- (modified) compiler-rt/lib/orc/dlfcn_wrapper.cpp (+14) 
- (modified) compiler-rt/lib/orc/elfnix_platform.cpp (+39) 
- (modified) compiler-rt/lib/orc/elfnix_platform.h (+1) 
- (modified) llvm/lib/ExecutionEngine/Orc/ELFNixPlatform.cpp (+9-1) 
- (modified) llvm/lib/ExecutionEngine/Orc/LLJIT.cpp (+23-1) 


``diff
diff --git a/clang/include/clang/Interpreter/Interpreter.h 
b/clang/include/clang/Interpreter/Interpreter.h
index 43573fb1a4b89..314beb7b72dac 100644
--- a/clang/include/clang/Interpreter/Interpreter.h
+++ b/clang/include/clang/Interpreter/Interpreter.h
@@ -21,6 +21,7 @@
 
 #include "llvm/ADT/DenseMap.h"
 #include "llvm/ExecutionEngine/JITSymbol.h"
+#include "llvm/ExecutionEngine/Orc/ExecutorProcessControl.h"
 #include "llvm/ExecutionEngine/Orc/Shared/ExecutorAddress.h"
 #include "llvm/Support/Error.h"
 #include 
@@ -81,6 +82,11 @@ class Interpreter {
   // An optional parser for CUDA offloading
   std::unique_ptr DeviceParser;
 
+  // An optional parameter for an out-of-process executor
+  std::unique_ptr EPC;
+
+  llvm::StringRef OrcRuntimePath;
+
   Interpreter(std::unique_ptr CI, llvm::Error );
 
   llvm::Error CreateExecutor();
@@ -98,6 +104,10 @@ class Interpreter {
   static llvm::Expected>
   createWithCUDA(std::unique_ptr CI,
  std::unique_ptr DCI);
+  static llvm::Expected>
+  createWithOutOfProcessExecutor(
+  std::unique_ptr CI,
+  std::unique_ptr EI, llvm::StringRef 
OrcRuntimePath);
   const ASTContext () const;
   ASTContext ();
   const CompilerInstance *getCompilerInstance() const;
diff --git a/clang/lib/Interpreter/IncrementalExecutor.cpp 
b/clang/lib/Interpreter/IncrementalExecutor.cpp
index 40bcef94797d4..30b24caa4a594 100644
--- a/clang/lib/Interpreter/IncrementalExecutor.cpp
+++ b/clang/lib/Interpreter/IncrementalExecutor.cpp
@@ -63,6 +63,35 @@ 
IncrementalExecutor::IncrementalExecutor(llvm::orc::ThreadSafeContext ,
   }
 }
 
+IncrementalExecutor::IncrementalExecutor(
+llvm::orc::ThreadSafeContext , llvm::Error ,
+const clang::TargetInfo ,
+std::unique_ptr EPC, llvm::StringRef 
OrcRuntimePath)
+: TSCtx(TSC) {
+  using namespace llvm::orc;
+  llvm::ErrorAsOutParameter EAO();
+
+  auto JTMB = JITTargetMachineBuilder(TI.getTriple());
+  JTMB.addFeatures(TI.getTargetOpts().Features);
+  LLJITBuilder Builder;
+  Builder.setJITTargetMachineBuilder(JTMB);
+  Builder.setPrePlatformSetup([](LLJIT ) {
+// Try to enable debugging of JIT'd code (only works with JITLink for
+// ELF and MachO).
+consumeError(enableDebuggerSupport(J));
+return llvm::Error::success();
+  });
+  Builder.setExecutorProcessControl(std::move(EPC));
+  
Builder.setPlatformSetUp(llvm::orc::ExecutorNativePlatform(OrcRuntimePath.str()));
+
+  if (auto JitOrErr = Builder.create()) {
+Jit = std::move(*JitOrErr);
+  } else {
+Err = JitOrErr.takeError();
+return;
+  }
+}
+
 IncrementalExecutor::~IncrementalExecutor() {}
 
 llvm::Error IncrementalExecutor::addModule(PartialTranslationUnit ) {
diff --git a/clang/lib/Interpreter/IncrementalExecutor.h 
b/clang/lib/Interpreter/IncrementalExecutor.h
index dd0a210a06141..a73ba9035182c 100644
--- a/clang/lib/Interpreter/IncrementalExecutor.h
+++ b/clang/lib/Interpreter/IncrementalExecutor.h
@@ -46,6 +46,9 @@ class IncrementalExecutor {
 
   IncrementalExecutor(llvm::orc::ThreadSafeContext , llvm::Error ,

[llvm] [compiler-rt] [clang] [clang-repl] [ORC] Add support for out-of-process execution on ELF (PR #79936)

2024-01-29 Thread via cfe-commits


github-actions[bot] wrote:

Thank you for submitting a Pull Request (PR) to the LLVM Project!

This PR will be automatically labeled and the relevant teams will be
notified.

If you wish to, you can add reviewers by using the "Reviewers" section on this 
page.

If this is not working for you, it is probably because you do not have write
permissions for the repository. In which case you can instead tag reviewers by
name in a comment by using `@` followed by their GitHub username.

If you have received no comments on your PR for a week, you can request a review
by "ping"ing the PR by adding a comment “Ping”. The common courtesy "ping" rate
is once a week. Please remember that you are asking for valuable time from 
other developers.

If you have further questions, they may be answered by the [LLVM GitHub User 
Guide](https://llvm.org/docs/GitHub.html).

You can also ask questions in a comment on this PR, on the [LLVM 
Discord](https://discord.com/invite/xS7Z362) or on the 
[forums](https://discourse.llvm.org/).

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

[llvm] [compiler-rt] [clang] [clang-repl] [ORC] Add support for out-of-process execution on ELF (PR #79936)

2024-01-29 Thread via cfe-commits


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

[clang] [llvm] [compiler-rt] [clang-repl] [ORC] Add support for out-of-process execution on ELF (PR #79936)

2024-01-29 Thread via cfe-commits


https://github.com/jameshu15869 created 
https://github.com/llvm/llvm-project/pull/79936

This PR adds initial support for out-of-process execution through 
llvm-jitlink-executor to clang-repl on ELF. The out-of-process executor can be 
invoked with "-oop-executor" or "-oop-executor-connect=" on ELF 
platforms. Now, clang-repl depends upon the ORC runtime to support static 
initializers and deinitializers. 

This PR modifies the ORC ELFNix platform to allow JITDylibs to be reinitialized 
through the "__orc_rt_jit_dlupdate" function, since clang-repl incrementally 
adds static initializers to a single JITDylib. 

On x86_64 linux, the following tests pass with the out-of-process executor 
flag. However, a new new testing file (out-of-process.cpp) was added with 
select tests to restrict the test to ELF only. 

- code-undo.cpp
- const.cpp
- execute-stmts.cpp
- execute-weak.cpp
- global-dtor.cpp
- incremental-mode.cpp
- inline-virtual.cpp
- lambda.cpp
- multiline.cpp
- sanity.cpp

>From 5efb122bc1d3b732bd58eb636ec770dfc572611f Mon Sep 17 00:00:00 2001
From: James Hu 
Date: Sun, 28 Jan 2024 20:01:20 -0500
Subject: [PATCH 1/4] [clang-repl][ORC] Add support for out-of-process
 execution on ELF

---
 clang/include/clang/Interpreter/Interpreter.h |  10 +
 clang/lib/Interpreter/IncrementalExecutor.cpp |  29 +++
 clang/lib/Interpreter/IncrementalExecutor.h   |   3 +
 clang/lib/Interpreter/Interpreter.cpp |  41 +++-
 clang/test/Interpreter/code-undo.cpp  |   1 +
 clang/test/Interpreter/const.cpp  |   1 +
 clang/test/Interpreter/execute-stmts.cpp  |   1 +
 clang/test/Interpreter/execute-weak.cpp   |   1 +
 clang/test/Interpreter/global-dtor.cpp|   1 +
 clang/test/Interpreter/incremental-mode.cpp   |   1 +
 clang/test/Interpreter/inline-virtual.cpp |   1 +
 clang/test/Interpreter/lambda.cpp |   1 +
 clang/test/Interpreter/multiline.cpp  |   1 +
 clang/test/Interpreter/sanity.c   |   4 +
 clang/tools/clang-repl/CMakeLists.txt |   1 +
 clang/tools/clang-repl/ClangRepl.cpp  | 220 ++
 compiler-rt/lib/orc/dlfcn_wrapper.cpp |  14 ++
 compiler-rt/lib/orc/elfnix_platform.cpp   |  39 
 compiler-rt/lib/orc/elfnix_platform.h |   1 +
 .../ExecutionEngine/Orc/ELFNixPlatform.cpp|  10 +-
 llvm/lib/ExecutionEngine/Orc/LLJIT.cpp|  21 +-
 21 files changed, 392 insertions(+), 10 deletions(-)

diff --git a/clang/include/clang/Interpreter/Interpreter.h 
b/clang/include/clang/Interpreter/Interpreter.h
index 43573fb1a4b89..314beb7b72dac 100644
--- a/clang/include/clang/Interpreter/Interpreter.h
+++ b/clang/include/clang/Interpreter/Interpreter.h
@@ -21,6 +21,7 @@
 
 #include "llvm/ADT/DenseMap.h"
 #include "llvm/ExecutionEngine/JITSymbol.h"
+#include "llvm/ExecutionEngine/Orc/ExecutorProcessControl.h"
 #include "llvm/ExecutionEngine/Orc/Shared/ExecutorAddress.h"
 #include "llvm/Support/Error.h"
 #include 
@@ -81,6 +82,11 @@ class Interpreter {
   // An optional parser for CUDA offloading
   std::unique_ptr DeviceParser;
 
+  // An optional parameter for an out-of-process executor
+  std::unique_ptr EPC;
+
+  llvm::StringRef OrcRuntimePath;
+
   Interpreter(std::unique_ptr CI, llvm::Error );
 
   llvm::Error CreateExecutor();
@@ -98,6 +104,10 @@ class Interpreter {
   static llvm::Expected>
   createWithCUDA(std::unique_ptr CI,
  std::unique_ptr DCI);
+  static llvm::Expected>
+  createWithOutOfProcessExecutor(
+  std::unique_ptr CI,
+  std::unique_ptr EI, llvm::StringRef 
OrcRuntimePath);
   const ASTContext () const;
   ASTContext ();
   const CompilerInstance *getCompilerInstance() const;
diff --git a/clang/lib/Interpreter/IncrementalExecutor.cpp 
b/clang/lib/Interpreter/IncrementalExecutor.cpp
index 40bcef94797d4..30b24caa4a594 100644
--- a/clang/lib/Interpreter/IncrementalExecutor.cpp
+++ b/clang/lib/Interpreter/IncrementalExecutor.cpp
@@ -63,6 +63,35 @@ 
IncrementalExecutor::IncrementalExecutor(llvm::orc::ThreadSafeContext ,
   }
 }
 
+IncrementalExecutor::IncrementalExecutor(
+llvm::orc::ThreadSafeContext , llvm::Error ,
+const clang::TargetInfo ,
+std::unique_ptr EPC, llvm::StringRef 
OrcRuntimePath)
+: TSCtx(TSC) {
+  using namespace llvm::orc;
+  llvm::ErrorAsOutParameter EAO();
+
+  auto JTMB = JITTargetMachineBuilder(TI.getTriple());
+  JTMB.addFeatures(TI.getTargetOpts().Features);
+  LLJITBuilder Builder;
+  Builder.setJITTargetMachineBuilder(JTMB);
+  Builder.setPrePlatformSetup([](LLJIT ) {
+// Try to enable debugging of JIT'd code (only works with JITLink for
+// ELF and MachO).
+consumeError(enableDebuggerSupport(J));
+return llvm::Error::success();
+  });
+  Builder.setExecutorProcessControl(std::move(EPC));
+  
Builder.setPlatformSetUp(llvm::orc::ExecutorNativePlatform(OrcRuntimePath.str()));
+
+  if (auto JitOrErr = Builder.create()) {
+Jit = std::move(*JitOrErr);
+  } else {
+Err = JitOrErr.takeError();
+

[libcxx] [clang-tools-extra] [llvm] [libc] [compiler-rt] [lldb] [lld] [clang] [flang] LLVM_FAULTMAPS section can be put after the DWARF section. (PR #77107)

2024-01-29 Thread via cfe-commits


https://github.com/shamithoke updated 
https://github.com/llvm/llvm-project/pull/77107

>From a0ccb2cbe3882a6ea8bb020dd54460f57dd84a90 Mon Sep 17 00:00:00 2001
From: shami 
Date: Thu, 28 Dec 2023 21:29:36 +0530
Subject: [PATCH] LLVM_FAULTMAPS section can be put after the DWARF section.

---
 llvm/lib/MC/MCMachOStreamer.cpp | 4 
 1 file changed, 4 insertions(+)

diff --git a/llvm/lib/MC/MCMachOStreamer.cpp b/llvm/lib/MC/MCMachOStreamer.cpp
index d7d343f15eaa6..61ab944ae44fb 100644
--- a/llvm/lib/MC/MCMachOStreamer.cpp
+++ b/llvm/lib/MC/MCMachOStreamer.cpp
@@ -160,6 +160,10 @@ static bool canGoAfterDWARF(const MCSectionMachO ) {
 return true;
   if (SegName == "__LLVM" && SecName == "__cg_profile")
 return true;
+
+  if (SegName == "__LLVM_FAULTMAPS" && SecName == "__llvm_faultmaps")
+return true;
+
   return false;
 }
 

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

[clang] a112df2 - [diagtool] Use StringRef::consume_front (NFC)

2024-01-29 Thread Kazu Hirata via cfe-commits


Author: Kazu Hirata
Date: 2024-01-29T18:46:11-08:00
New Revision: a112df28edc449e3e47101ffa7d4b6f0bc040c63

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

LOG: [diagtool] Use StringRef::consume_front (NFC)

Added: 


Modified: 
clang/tools/diagtool/TreeView.cpp

Removed: 




diff  --git a/clang/tools/diagtool/TreeView.cpp 
b/clang/tools/diagtool/TreeView.cpp
index eae16243d3d59..00d1097b5fbfd 100644
--- a/clang/tools/diagtool/TreeView.cpp
+++ b/clang/tools/diagtool/TreeView.cpp
@@ -160,8 +160,7 @@ int TreeView::run(unsigned int argc, char **argv, 
llvm::raw_ostream ) {
 break;
   case 1:
 RootGroup = argv[0];
-if (RootGroup.starts_with("-W"))
-  RootGroup = RootGroup.substr(2);
+RootGroup.consume_front("-W");
 if (RootGroup == "everything")
   ShowAll = true;
 // FIXME: Handle other special warning flags, like -pedantic.



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

[clang] [RISCV][clang] Add Zvfbfmin C intrinsics support (PR #79618)

2024-01-29 Thread Craig Topper via cfe-commits



@@ -1883,6 +1883,12 @@ let Log2LMUL = [-3, -2, -1, 0, 1, 2] in {
   def vfncvt_rtz_x_f_w : RVVConvToNarrowingSignedBuiltin<"vfncvt_rtz_x">;
   def vfncvt_rod_f_f_w : RVVConvBuiltin<"v", "vw", "xf", "vfncvt_rod_f">;
 }
+
+// Zvfbfmin - Vector convert BF16 to FP32
+let Log2LMUL = [-2, -1, 0, 1, 2],

topperc wrote:

We can probably do something like what is done for Zvfh in 
SemaRISCVVectorLookup.cpp. In practice, it probably doesn't matter match since 
you can't declare a bfloat16 vector with Zvfhbfmin so you can't use the 
intrinsic even if it was declared.

```
  if (BaseType == BasicType::Float16) { 
 
if ((Record.RequiredExtensions & RVV_REQ_Zvfhmin) == RVV_REQ_Zvfhmin) { 
 
  if (!TI.hasFeature("zvfhmin"))
 
continue;   
 
} else if (!TI.hasFeature("zvfh")) {
 
  continue; 
 
}   
 
  } 
```

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

[clang] [llvm] [compiler-rt] [libc] [flang] [llvm-gsymutil] Fix assert failure on FileEntry.Dir empty (PR #79926)

2024-01-29 Thread Greg Clayton via cfe-commits



@@ -0,0 +1,108 @@
+## Test converting DWARF using relative path
+
+# RUN: yaml2obj %s -o %t
+# RUN: llvm-gsymutil --convert %t -o %t.gsym --segment-size=10 
--num-threads=80 --quiet 2>&1 | FileCheck %s --check-prefix=CONVERT

clayborg wrote:

Don't specify the number of threads, they will automatically be set to a good 
value.

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

[flang] [clang] [libc] [compiler-rt] [llvm] [llvm-gsymutil] Fix assert failure on FileEntry.Dir empty (PR #79926)

2024-01-29 Thread Greg Clayton via cfe-commits


https://github.com/clayborg commented:

Just remove the "--num-threads" option from the test yaml file and this is good 
to go.

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

[llvm] [libc] [compiler-rt] [clang] [flang] [llvm-gsymutil] Fix assert failure on FileEntry.Dir empty (PR #79926)

2024-01-29 Thread Greg Clayton via cfe-commits


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

[clang] [llvm] [BPF] add cast_{user,kern} instructions (PR #79902)

2024-01-29 Thread via cfe-commits


https://github.com/eddyz87 updated 
https://github.com/llvm/llvm-project/pull/79902

>From fdd5a736fb5f2ce046f53f7d059e3d347416b27d Mon Sep 17 00:00:00 2001
From: Eduard Zingerman 
Date: Fri, 26 Jan 2024 04:18:32 +0200
Subject: [PATCH 1/2] [BPF] add cast_{user,kern} instructions

This commit aims to support BPF arena kernel side feature:
- arena is a memory region accessible from both
  BPF program and userspace;
- base pointers for this memory region differ between
  kernel and user spaces;
- `dst_reg = cast_user(src_reg, addr_space_no)`
  translates src_reg, kernel space pointer within arena,
  to dst_reg, equivalent user space pointer within arena
  (both pointers have identical offset from arena start),
  addr_space_no is an immediate constant, used to identify
  the particular arena;
- `dst_reg = cast_kern(src_reg, addr_space_no)`
  is similar but in opposite direction: converts user space arena
  pointer to kernel space arena pointer.

On the LLVM side, the goal is to have all arena pointers stored in
arena memory in user space format:
- assume that pointers with non-zero address space are pointers to
  arena memory;
- assume that arena is identified by address space number;
- assume that every BPF-side load or store from arena is done via
  pointer in user address space, thus convert base pointers using
  cast_kern;
- assume that every BPF-side store of arena pointer value is in kernel
  address space, thus convert stored pointers with cast_user.

Only load and store IR instructions are handled at the moment.

For example, the following C code:

```c

struct list {
  struct list __as *next;
  int i;
};

extern struct list __as *mklist(void);

struct list __as *push(int i, struct list __as *list) {
  struct list __as *elt = mklist();
  elt->i = i;
  elt->next = list;
  return elt;
}
```

Compiled to the following IR:

```llvm
  %call = tail call ptr addrspace(272) @mklist() #2
  %i1 = getelementptr inbounds %struct.list, ptr addrspace(272) %call, i64 0, 
i32 1
  store i32 %i, ptr addrspace(272) %i1, align 8, !tbaa !3
  store ptr addrspace(272) %list, ptr addrspace(272) %call, align 8
  ret ptr addrspace(272) %call
```

Is transformed to:

```llvm
  %list6 = call ptr addrspace(272) @llvm.bpf.addr.space.p272.p272(ptr 
addrspace(272) %list, i32 2) ;; cast_user
  %call = tail call ptr addrspace(272) @mklist() #3
  %call4 = call ptr addrspace(272) @llvm.bpf.addr.space.p272.p272(ptr 
addrspace(272) %call, i32 1) ;; cast_kern
  %i15 = getelementptr inbounds %struct.list, ptr addrspace(272) %call4, i64 0, 
i32 1
  store i32 %i, ptr addrspace(272) %i15, align 8, !tbaa !3
  store ptr addrspace(272) %list6, ptr addrspace(272) %call4, align 8
  ret ptr addrspace(272) %call
```

And compiled as:

```asm
  r6 = r2
  r7 = r1
  call mklist
  r1 = cast_kern(r0, 272)
  *(u32 *)(r1 + 8) = r7
  r2 = cast_user(r6, 272)
  *(u64 *)(r1 + 0) = r2
  exit
```

Internally:
- use a new intrinsic function to mark the conversions:
  `llvm.bpf.addr.space(, )`,
  where `cast_diretion` is an immediate describing whether
  operation is `cast_kern` (1) or `cast_user` (2);
- piggy-back `BPFCheckAndAdjustIR` pass to insert the above intrinsic
  calls for load and store instructions;
- modify `BPFInstrInfo.td` and `BPFIselLowering.cpp` to allow
  translation of new intrinsic:
  - define and SDNode type `BPFAddrSpace` to represent new intrinsic:
- override `BPFTargetLowering::CollectTargetIntrinsicOperands()`
  method to add pointer address space as a parameter of intrinsic
  SDNode;
- define `BPFTargetLowering::LowerINTRINSIC_WO_CHAIN()` called
  from `BPFTargetLowering::LowerOperation()` to lower intrinsic
  call to an SDNode;
  - define new instructions: `ADDR_SPACE_K`, `ADDR_SPACE_U`;
  - define patterns to lower `BPFAddrSpace` as `ADDR_SPACE_{KU}`.
---
 llvm/include/llvm/IR/IntrinsicsBPF.td |   5 +
 llvm/lib/Target/BPF/BPFCheckAndAdjustIR.cpp   |  88 ++
 llvm/lib/Target/BPF/BPFISelLowering.cpp   |  32 
 llvm/lib/Target/BPF/BPFISelLowering.h |   6 +-
 llvm/lib/Target/BPF/BPFInstrInfo.td   |  20 +++
 llvm/test/CodeGen/BPF/addr-space-builtin.ll   | 153 ++
 llvm/test/CodeGen/BPF/addr-space-gep-chain.ll |  34 
 llvm/test/CodeGen/BPF/addr-space-insn.ll  |  15 ++
 llvm/test/CodeGen/BPF/addr-space-ku-chain.ll  |  56 +++
 .../BPF/addr-space-ku-for-same-base.ll|  61 +++
 llvm/test/CodeGen/BPF/addr-space-phi.ll   |  68 
 11 files changed, 537 insertions(+), 1 deletion(-)
 create mode 100644 llvm/test/CodeGen/BPF/addr-space-builtin.ll
 create mode 100644 llvm/test/CodeGen/BPF/addr-space-gep-chain.ll
 create mode 100644 llvm/test/CodeGen/BPF/addr-space-insn.ll
 create mode 100644 llvm/test/CodeGen/BPF/addr-space-ku-chain.ll
 create mode 100644 llvm/test/CodeGen/BPF/addr-space-ku-for-same-base.ll
 create mode 100644 llvm/test/CodeGen/BPF/addr-space-phi.ll

diff --git a/llvm/include/llvm/IR/IntrinsicsBPF.td

[clang] [Serialization] Check for stack exhaustion when reading declarations (PR #79875)

2024-01-29 Thread Chuanqi Xu via cfe-commits


ChuanqiXu9 wrote:

Another idea is to limit (or check) the threshold for 
`ASTReader::NumCurrentElementsDeserializing`. Then we still can print the stack 
trace by some utils in LLVM also we can get better performance than this. 

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

[clang] [Serialization] Check for stack exhaustion when reading declarations (PR #79875)

2024-01-29 Thread Chuanqi Xu via cfe-commits



@@ -0,0 +1,43 @@
+// RUN: rm -rf %t
+// RUN: mkdir -p %t
+// RUN: split-file %s %t
+
+// RUN: %clang_cc1 -std=c++20 -emit-module-interface %t/usings.cppm -o 
%t/usings.pcm
+// RUN: %clang_cc1 -std=c++20 -fmodule-file=usings=%t/usings.pcm %t/use.cpp 
-verify -fsyntax-only -Wno-stack-exhausted
+
+// expected-no-diagnostics
+
+//--- usings.cppm
+export module usings;
+
+#define TYPES1(NAME) DECLARE(NAME##a) DECLARE(NAME##b) DECLARE(NAME##c) \
+DECLARE(NAME##d) DECLARE(NAME##e) DECLARE(NAME##f) DECLARE(NAME##g) \
+DECLARE(NAME##h) DECLARE(NAME##i) DECLARE(NAME##j) 
+#define TYPES2(NAME) TYPES1(NAME##a) TYPES1(NAME##b) TYPES1(NAME##c) \
+TYPES1(NAME##d) TYPES1(NAME##e) TYPES1(NAME##f) TYPES1(NAME##g) \
+TYPES1(NAME##h) TYPES1(NAME##i) TYPES1(NAME##j) 
+#define TYPES3(NAME) TYPES2(NAME##a) TYPES2(NAME##b) TYPES2(NAME##c) \
+TYPES2(NAME##d) TYPES2(NAME##e) TYPES2(NAME##f) TYPES2(NAME##g) \
+TYPES2(NAME##h) TYPES2(NAME##i) TYPES2(NAME##j) 
+#define TYPES4(NAME) TYPES3(NAME##a) TYPES3(NAME##b) TYPES3(NAME##c) \
+TYPES3(NAME##d) TYPES3(NAME##e) TYPES3(NAME##f) TYPES3(NAME##g)
+
+#define DECLARE(NAME) struct NAME {};
+TYPES4(Type)

ChuanqiXu9 wrote:

> I am not sure if there is an an approach that does not involve structural 
> changes to the AST (i.e. rewriting the ASTReaderDecl somehow, but keeping the 
> AST the same).

To my knowledge, it is only possible by introducing coroutines if we don't want 
to refactor the current deserializer significantly.

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

[clang] [Serialization] Check for stack exhaustion when reading declarations (PR #79875)

2024-01-29 Thread Chuanqi Xu via cfe-commits


https://github.com/ChuanqiXu9 commented:

To make this testable, maybe we can refactor 
`clang::runWithSufficientStackSpace`  a little bit to make `DesiredStackSize` 
and `isStackNearlyExhausted::SufficientStack` configurable.

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

[clang] [Serialization] Check for stack exhaustion when reading declarations (PR #79875)

2024-01-29 Thread Chuanqi Xu via cfe-commits



@@ -4099,7 +4099,9 @@ Decl *ASTReader::ReadDeclRecord(DeclID ID) {
   // calls to Decl::getASTContext() by Decl's methods will find the
   // TranslationUnitDecl without crashing.
   D->setDeclContext(Context.getTranslationUnitDecl());
-  Reader.Visit(D);
+
+  // Reading some declarations can result in deep recursion.
+  SemaObj->runWithSufficientStackSpace(DeclLoc, [&] { Reader.Visit(D); });

ChuanqiXu9 wrote:

Sema may not meaningful in ASTReader (e.g., we're compiling a pcm file). 
```suggestion
clang::runWithSufficientStackSpace(...)
```

Also in this way, we can get better diagnotsics.

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

[clang] [Serialization] Check for stack exhaustion when reading declarations (PR #79875)

2024-01-29 Thread Chuanqi Xu via cfe-commits


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

[clang] [RISCV][clang] Add Zvfbfmin C intrinsics support (PR #79618)

2024-01-29 Thread Jim Lin via cfe-commits



@@ -0,0 +1,218 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py 
UTC_ARGS: --version 4
+// REQUIRES: riscv-registered-target
+// RUN: %clang_cc1 -triple riscv64 -target-feature +v -target-feature +zfh \
+// RUN:   -target-feature +zvfh -target-feature +experimental-zvfbfmin 
-disable-O0-optnone  \

tclin914 wrote:

Are -target-feature +zfh and -target-feature +zvfh necessary?

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

[clang] [RISCV][clang] Add Zvfbfmin C intrinsics support (PR #79618)

2024-01-29 Thread Jim Lin via cfe-commits



@@ -1883,6 +1883,12 @@ let Log2LMUL = [-3, -2, -1, 0, 1, 2] in {
   def vfncvt_rtz_x_f_w : RVVConvToNarrowingSignedBuiltin<"vfncvt_rtz_x">;
   def vfncvt_rod_f_f_w : RVVConvBuiltin<"v", "vw", "xf", "vfncvt_rod_f">;
 }
+
+// Zvfbfmin - Vector convert BF16 to FP32
+let Log2LMUL = [-2, -1, 0, 1, 2],
+OverloadedName = "vfwcvtbf16_f" in
+defm : RVVConvBuiltinSet<"vfwcvtbf16_f_f_v", "y", [["Fw", "Fwv"]]>;

tclin914 wrote:

Could we just use `RVVConvBuiltin` here. 
Like `def vfwcvtbf16_f_f_v : RVVConvBuiltin<"Fw", "Fwv", "y", "vfwcvtbf16_f">;`

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

[clang] [RISCV][clang] Add Zvfbfmin C intrinsics support (PR #79618)

2024-01-29 Thread Jim Lin via cfe-commits



@@ -1883,6 +1883,12 @@ let Log2LMUL = [-3, -2, -1, 0, 1, 2] in {
   def vfncvt_rtz_x_f_w : RVVConvToNarrowingSignedBuiltin<"vfncvt_rtz_x">;
   def vfncvt_rod_f_f_w : RVVConvBuiltin<"v", "vw", "xf", "vfncvt_rod_f">;
 }
+
+// Zvfbfmin - Vector convert BF16 to FP32
+let Log2LMUL = [-2, -1, 0, 1, 2],

tclin914 wrote:

Do we need a RequiredFeatures for this?

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

[clang-tools-extra] [clang-tidy] Add AllowStringArrays option to modernize-avoid-c-arrays (PR #71701)

2024-01-29 Thread Congcong Cai via cfe-commits

HerrCai0907 wrote:

> It should not work, as this is not array, but pointer

Agree. But it fulfills the description of this opinion, since it looks like to 
construct a array from string literals.
It would be better to explain it in document.

> incomplete array types constructed from string literals will be ignored.

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

[clang] [llvm] [RISCV] Add support for RISC-V Pointer Masking (PR #79929)

2024-01-29 Thread Michael Maitland via cfe-commits


https://github.com/michaelmaitland updated 
https://github.com/llvm/llvm-project/pull/79929

>From 0d1c71afab487cc1028fcfc678c111205140ac21 Mon Sep 17 00:00:00 2001
From: Michael Maitland 
Date: Mon, 29 Jan 2024 12:33:59 -0800
Subject: [PATCH 1/2] [RISCV] Add support for RISC-V Pointer Masking

This patch implements the v0.8.1 specification. This includes support of
the `Ssnpm`, `Smnpm`, `Smmpm`, `Sspm` and `Supm` extensions that make up
RISC-V pointer masking.

All of these extensions only require emitting attribute containing
correct `march` string. `Ssnpm`, `Smnpm`, `Smmpm` extensions introduce a
2-bit WARL field (PMM). The extension does not specify how PMM is set,
and therefore this patch does not need to address this. One example of
how it *could* be set is using the Zicsr instructions to update the PMM
bits of the described registers.

The full specification can be found at
https://github.com/riscv/riscv-j-extension/blob/master/zjpm-spec.pdf
---
 .../test/Preprocessor/riscv-target-features.c | 45 +++
 llvm/docs/RISCVUsage.rst  |  3 ++
 llvm/docs/ReleaseNotes.rst|  1 +
 llvm/lib/Support/RISCVISAInfo.cpp |  6 +++
 llvm/lib/Target/RISCV/RISCVFeatures.td| 34 ++
 llvm/test/CodeGen/RISCV/attributes.ll | 20 +
 llvm/unittests/Support/RISCVISAInfoTest.cpp   |  5 +++
 7 files changed, 114 insertions(+)

diff --git a/clang/test/Preprocessor/riscv-target-features.c 
b/clang/test/Preprocessor/riscv-target-features.c
index 2361c83a5a6102..82d2efd51a091a 100644
--- a/clang/test/Preprocessor/riscv-target-features.c
+++ b/clang/test/Preprocessor/riscv-target-features.c
@@ -142,6 +142,11 @@
 
 // Experimental extensions
 
+// CHECK-NOT: __riscv_smmpm{{.*$}}
+// CHECK-NOT: __riscv_smnpm{{.*$}}
+// CHECK-NOT: __riscv_ssnpm{{.*$}}
+// CHECK-NOT: __riscv_sspm{{.*$}}
+// CHECK-NOT: __riscv_supm{{.*$}}
 // CHECK-NOT: __riscv_zaamo {{.*$}}
 // CHECK-NOT: __riscv_zacas {{.*$}}
 // CHECK-NOT: __riscv_zalrsc {{.*$}}
@@ -1405,6 +1410,46 @@
 // RUN:   -o - | FileCheck --check-prefix=CHECK-ZICFISS-EXT %s
 // CHECK-ZICFISS-EXT: __riscv_zicfiss 4000{{$}}
 
+// RUN: %clang --target=riscv32 -menable-experimental-extensions \
+// RUN:   -march=rv32i_ssnpm0p8 -E -dM %s \
+// RUN:   -o - | FileCheck --check-prefix=CHECK-SSNPM-EXT %s
+// RUN: %clang --target=riscv64 -menable-experimental-extensions \
+// RUN:   -march=rv64i_ssnpm0p8 -E -dM %s \
+// RUN:   -o - | FileCheck --check-prefix=CHECK-SSNPM-EXT %s
+// CHECK-SSNPM-EXT: __riscv_ssnpm 8000{{$}}
+
+// RUN: %clang --target=riscv32 -menable-experimental-extensions \
+// RUN:   -march=rv32i_smnpm0p8 -E -dM %s \
+// RUN:   -o - | FileCheck --check-prefix=CHECK-SMNPM-EXT %s
+// RUN: %clang --target=riscv64 -menable-experimental-extensions \
+// RUN:   -march=rv64i_smnpm0p8 -E -dM %s \
+// RUN:   -o - | FileCheck --check-prefix=CHECK-SMNPM-EXT %s
+// CHECK-SMNPM-EXT: __riscv_smnpm 8000{{$}}
+
+// RUN: %clang --target=riscv32 -menable-experimental-extensions \
+// RUN:   -march=rv32i_smmpm0p8 -E -dM %s \
+// RUN:   -o - | FileCheck --check-prefix=CHECK-SMMPM-EXT %s
+// RUN: %clang --target=riscv64 -menable-experimental-extensions \
+// RUN:   -march=rv64i_smmpm0p8 -E -dM %s \
+// RUN:   -o - | FileCheck --check-prefix=CHECK-SMMPM-EXT %s
+// CHECK-SMMPM-EXT: __riscv_smmpm 8000{{$}}
+
+// RUN: %clang --target=riscv32 -menable-experimental-extensions \
+// RUN:   -march=rv32i_sspm0p8 -E -dM %s \
+// RUN:   -o - | FileCheck --check-prefix=CHECK-SSPM-EXT %s
+// RUN: %clang --target=riscv64 \
+// RUN:   -march=rv64i_sspm0p8 -E -dM %s -menable-experimental-extensions \
+// RUN:   -o - | FileCheck --check-prefix=CHECK-SSPM-EXT %s
+// CHECK-SSPM-EXT: __riscv_sspm 8000{{$}}
+
+// RUN: %clang --target=riscv32 -menable-experimental-extensions \
+// RUN:   -march=rv32i_supm0p8 -E -dM %s \
+// RUN:   -o - | FileCheck --check-prefix=CHECK-SUPM-EXT %s
+// RUN: %clang --target=riscv64 \
+// RUN:   -march=rv64i_supm0p8 -E -dM %s -menable-experimental-extensions \
+// RUN:   -o - | FileCheck --check-prefix=CHECK-SUPM-EXT %s
+// CHECK-SUPM-EXT: __riscv_supm 8000{{$}}
+
 // Misaligned
 
 // RUN: %clang --target=riscv32-unknown-linux-gnu -march=rv32i -E -dM %s \
diff --git a/llvm/docs/RISCVUsage.rst b/llvm/docs/RISCVUsage.rst
index 06292f05b90b82..d07f0480f70240 100644
--- a/llvm/docs/RISCVUsage.rst
+++ b/llvm/docs/RISCVUsage.rst
@@ -226,6 +226,9 @@ LLVM supports (to various degrees) a number of experimental 
extensions.  All exp
 
 The primary goal of experimental support is to assist in the process of 
ratification by providing an existence proof of an implementation, and 
simplifying efforts to validate the value of a proposed extension against large 
code bases.  Experimental extensions are expected to either transition to 
ratified status, or be eventually removed.  The decision on whether to accept 
an experimental extension is currently done on an entirely case by case basis; 
if you want to propose

[clang] [llvm] [RISCV] Add support for RISC-V Pointer Masking (PR #79929)

2024-01-29 Thread via cfe-commits


llvmbot wrote:




@llvm/pr-subscribers-backend-risc-v

Author: Michael Maitland (michaelmaitland)


Changes

This patch implements the v0.8.1 specification. This patch reports version 0.8 
in llvm since `RISCVISAInfo::ExtensionVersion` only has a `Major` and `Minor` 
version number. This patch includes includes support of the `Ssnpm`, `Smnpm`, 
`Smmpm`, `Sspm` and `Supm` extensions that make up RISC-V pointer masking.

All of these extensions require emitting attribute containing correct `march` 
string.

`Ssnpm`, `Smnpm`, `Smmpm` extensions introduce a 2-bit WARL field (PMM). The 
extension does not specify how PMM is set, and therefore this patch does not 
need to address this. One example of how it *could* be set is using the Zicsr 
instructions to update the PMM bits of the described registers.

The full specification can be found at
https://github.com/riscv/riscv-j-extension/blob/master/zjpm-spec.pdf

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


7 Files Affected:

- (modified) clang/test/Preprocessor/riscv-target-features.c (+45) 
- (modified) llvm/docs/RISCVUsage.rst (+3) 
- (modified) llvm/docs/ReleaseNotes.rst (+1) 
- (modified) llvm/lib/Support/RISCVISAInfo.cpp (+6) 
- (modified) llvm/lib/Target/RISCV/RISCVFeatures.td (+34) 
- (modified) llvm/test/CodeGen/RISCV/attributes.ll (+20) 
- (modified) llvm/unittests/Support/RISCVISAInfoTest.cpp (+5) 


``diff
diff --git a/clang/test/Preprocessor/riscv-target-features.c 
b/clang/test/Preprocessor/riscv-target-features.c
index 2361c83a5a610..82d2efd51a091 100644
--- a/clang/test/Preprocessor/riscv-target-features.c
+++ b/clang/test/Preprocessor/riscv-target-features.c
@@ -142,6 +142,11 @@
 
 // Experimental extensions
 
+// CHECK-NOT: __riscv_smmpm{{.*$}}
+// CHECK-NOT: __riscv_smnpm{{.*$}}
+// CHECK-NOT: __riscv_ssnpm{{.*$}}
+// CHECK-NOT: __riscv_sspm{{.*$}}
+// CHECK-NOT: __riscv_supm{{.*$}}
 // CHECK-NOT: __riscv_zaamo {{.*$}}
 // CHECK-NOT: __riscv_zacas {{.*$}}
 // CHECK-NOT: __riscv_zalrsc {{.*$}}
@@ -1405,6 +1410,46 @@
 // RUN:   -o - | FileCheck --check-prefix=CHECK-ZICFISS-EXT %s
 // CHECK-ZICFISS-EXT: __riscv_zicfiss 4000{{$}}
 
+// RUN: %clang --target=riscv32 -menable-experimental-extensions \
+// RUN:   -march=rv32i_ssnpm0p8 -E -dM %s \
+// RUN:   -o - | FileCheck --check-prefix=CHECK-SSNPM-EXT %s
+// RUN: %clang --target=riscv64 -menable-experimental-extensions \
+// RUN:   -march=rv64i_ssnpm0p8 -E -dM %s \
+// RUN:   -o - | FileCheck --check-prefix=CHECK-SSNPM-EXT %s
+// CHECK-SSNPM-EXT: __riscv_ssnpm 8000{{$}}
+
+// RUN: %clang --target=riscv32 -menable-experimental-extensions \
+// RUN:   -march=rv32i_smnpm0p8 -E -dM %s \
+// RUN:   -o - | FileCheck --check-prefix=CHECK-SMNPM-EXT %s
+// RUN: %clang --target=riscv64 -menable-experimental-extensions \
+// RUN:   -march=rv64i_smnpm0p8 -E -dM %s \
+// RUN:   -o - | FileCheck --check-prefix=CHECK-SMNPM-EXT %s
+// CHECK-SMNPM-EXT: __riscv_smnpm 8000{{$}}
+
+// RUN: %clang --target=riscv32 -menable-experimental-extensions \
+// RUN:   -march=rv32i_smmpm0p8 -E -dM %s \
+// RUN:   -o - | FileCheck --check-prefix=CHECK-SMMPM-EXT %s
+// RUN: %clang --target=riscv64 -menable-experimental-extensions \
+// RUN:   -march=rv64i_smmpm0p8 -E -dM %s \
+// RUN:   -o - | FileCheck --check-prefix=CHECK-SMMPM-EXT %s
+// CHECK-SMMPM-EXT: __riscv_smmpm 8000{{$}}
+
+// RUN: %clang --target=riscv32 -menable-experimental-extensions \
+// RUN:   -march=rv32i_sspm0p8 -E -dM %s \
+// RUN:   -o - | FileCheck --check-prefix=CHECK-SSPM-EXT %s
+// RUN: %clang --target=riscv64 \
+// RUN:   -march=rv64i_sspm0p8 -E -dM %s -menable-experimental-extensions \
+// RUN:   -o - | FileCheck --check-prefix=CHECK-SSPM-EXT %s
+// CHECK-SSPM-EXT: __riscv_sspm 8000{{$}}
+
+// RUN: %clang --target=riscv32 -menable-experimental-extensions \
+// RUN:   -march=rv32i_supm0p8 -E -dM %s \
+// RUN:   -o - | FileCheck --check-prefix=CHECK-SUPM-EXT %s
+// RUN: %clang --target=riscv64 \
+// RUN:   -march=rv64i_supm0p8 -E -dM %s -menable-experimental-extensions \
+// RUN:   -o - | FileCheck --check-prefix=CHECK-SUPM-EXT %s
+// CHECK-SUPM-EXT: __riscv_supm 8000{{$}}
+
 // Misaligned
 
 // RUN: %clang --target=riscv32-unknown-linux-gnu -march=rv32i -E -dM %s \
diff --git a/llvm/docs/RISCVUsage.rst b/llvm/docs/RISCVUsage.rst
index 06292f05b90b8..d07f0480f7024 100644
--- a/llvm/docs/RISCVUsage.rst
+++ b/llvm/docs/RISCVUsage.rst
@@ -226,6 +226,9 @@ LLVM supports (to various degrees) a number of experimental 
extensions.  All exp
 
 The primary goal of experimental support is to assist in the process of 
ratification by providing an existence proof of an implementation, and 
simplifying efforts to validate the value of a proposed extension against large 
code bases.  Experimental extensions are expected to either transition to 
ratified status, or be eventually removed.  The decision on whether to accept 
an experimental extension is currently done on an entirely case by case basis; 
if you want to propose one,

[clang] [llvm] [RISCV] Add support for RISC-V Pointer Masking (PR #79929)

2024-01-29 Thread Michael Maitland via cfe-commits


https://github.com/michaelmaitland created 
https://github.com/llvm/llvm-project/pull/79929

This patch implements the v0.8.1 specification. This patch reports version 0.8 
in llvm since `RISCVISAInfo::ExtensionVersion` only has a `Major` and `Minor` 
version number. This patch includes includes support of the `Ssnpm`, `Smnpm`, 
`Smmpm`, `Sspm` and `Supm` extensions that make up RISC-V pointer masking.

All of these extensions require emitting attribute containing correct `march` 
string.

`Ssnpm`, `Smnpm`, `Smmpm` extensions introduce a 2-bit WARL field (PMM). The 
extension does not specify how PMM is set, and therefore this patch does not 
need to address this. One example of how it *could* be set is using the Zicsr 
instructions to update the PMM bits of the described registers.

The full specification can be found at
https://github.com/riscv/riscv-j-extension/blob/master/zjpm-spec.pdf

>From 0d1c71afab487cc1028fcfc678c111205140ac21 Mon Sep 17 00:00:00 2001
From: Michael Maitland 
Date: Mon, 29 Jan 2024 12:33:59 -0800
Subject: [PATCH] [RISCV] Add support for RISC-V Pointer Masking

This patch implements the v0.8.1 specification. This includes support of
the `Ssnpm`, `Smnpm`, `Smmpm`, `Sspm` and `Supm` extensions that make up
RISC-V pointer masking.

All of these extensions only require emitting attribute containing
correct `march` string. `Ssnpm`, `Smnpm`, `Smmpm` extensions introduce a
2-bit WARL field (PMM). The extension does not specify how PMM is set,
and therefore this patch does not need to address this. One example of
how it *could* be set is using the Zicsr instructions to update the PMM
bits of the described registers.

The full specification can be found at
https://github.com/riscv/riscv-j-extension/blob/master/zjpm-spec.pdf
---
 .../test/Preprocessor/riscv-target-features.c | 45 +++
 llvm/docs/RISCVUsage.rst  |  3 ++
 llvm/docs/ReleaseNotes.rst|  1 +
 llvm/lib/Support/RISCVISAInfo.cpp |  6 +++
 llvm/lib/Target/RISCV/RISCVFeatures.td| 34 ++
 llvm/test/CodeGen/RISCV/attributes.ll | 20 +
 llvm/unittests/Support/RISCVISAInfoTest.cpp   |  5 +++
 7 files changed, 114 insertions(+)

diff --git a/clang/test/Preprocessor/riscv-target-features.c 
b/clang/test/Preprocessor/riscv-target-features.c
index 2361c83a5a610..82d2efd51a091 100644
--- a/clang/test/Preprocessor/riscv-target-features.c
+++ b/clang/test/Preprocessor/riscv-target-features.c
@@ -142,6 +142,11 @@
 
 // Experimental extensions
 
+// CHECK-NOT: __riscv_smmpm{{.*$}}
+// CHECK-NOT: __riscv_smnpm{{.*$}}
+// CHECK-NOT: __riscv_ssnpm{{.*$}}
+// CHECK-NOT: __riscv_sspm{{.*$}}
+// CHECK-NOT: __riscv_supm{{.*$}}
 // CHECK-NOT: __riscv_zaamo {{.*$}}
 // CHECK-NOT: __riscv_zacas {{.*$}}
 // CHECK-NOT: __riscv_zalrsc {{.*$}}
@@ -1405,6 +1410,46 @@
 // RUN:   -o - | FileCheck --check-prefix=CHECK-ZICFISS-EXT %s
 // CHECK-ZICFISS-EXT: __riscv_zicfiss 4000{{$}}
 
+// RUN: %clang --target=riscv32 -menable-experimental-extensions \
+// RUN:   -march=rv32i_ssnpm0p8 -E -dM %s \
+// RUN:   -o - | FileCheck --check-prefix=CHECK-SSNPM-EXT %s
+// RUN: %clang --target=riscv64 -menable-experimental-extensions \
+// RUN:   -march=rv64i_ssnpm0p8 -E -dM %s \
+// RUN:   -o - | FileCheck --check-prefix=CHECK-SSNPM-EXT %s
+// CHECK-SSNPM-EXT: __riscv_ssnpm 8000{{$}}
+
+// RUN: %clang --target=riscv32 -menable-experimental-extensions \
+// RUN:   -march=rv32i_smnpm0p8 -E -dM %s \
+// RUN:   -o - | FileCheck --check-prefix=CHECK-SMNPM-EXT %s
+// RUN: %clang --target=riscv64 -menable-experimental-extensions \
+// RUN:   -march=rv64i_smnpm0p8 -E -dM %s \
+// RUN:   -o - | FileCheck --check-prefix=CHECK-SMNPM-EXT %s
+// CHECK-SMNPM-EXT: __riscv_smnpm 8000{{$}}
+
+// RUN: %clang --target=riscv32 -menable-experimental-extensions \
+// RUN:   -march=rv32i_smmpm0p8 -E -dM %s \
+// RUN:   -o - | FileCheck --check-prefix=CHECK-SMMPM-EXT %s
+// RUN: %clang --target=riscv64 -menable-experimental-extensions \
+// RUN:   -march=rv64i_smmpm0p8 -E -dM %s \
+// RUN:   -o - | FileCheck --check-prefix=CHECK-SMMPM-EXT %s
+// CHECK-SMMPM-EXT: __riscv_smmpm 8000{{$}}
+
+// RUN: %clang --target=riscv32 -menable-experimental-extensions \
+// RUN:   -march=rv32i_sspm0p8 -E -dM %s \
+// RUN:   -o - | FileCheck --check-prefix=CHECK-SSPM-EXT %s
+// RUN: %clang --target=riscv64 \
+// RUN:   -march=rv64i_sspm0p8 -E -dM %s -menable-experimental-extensions \
+// RUN:   -o - | FileCheck --check-prefix=CHECK-SSPM-EXT %s
+// CHECK-SSPM-EXT: __riscv_sspm 8000{{$}}
+
+// RUN: %clang --target=riscv32 -menable-experimental-extensions \
+// RUN:   -march=rv32i_supm0p8 -E -dM %s \
+// RUN:   -o - | FileCheck --check-prefix=CHECK-SUPM-EXT %s
+// RUN: %clang --target=riscv64 \
+// RUN:   -march=rv64i_supm0p8 -E -dM %s -menable-experimental-extensions \
+// RUN:   -o - | FileCheck --check-prefix=CHECK-SUPM-EXT %s
+// CHECK-SUPM-EXT: __riscv_supm 8000{{$}}
+
 // Misaligned
 
 // RUN: %clang

[compiler-rt] [flang] [llvm] [libc] [clang] [llvm-gsymutil] Fix assert failure on FileEntry.Dir empty (PR #79926)

2024-01-29 Thread via cfe-commits


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

[compiler-rt] [flang] [llvm] [libc] [clang] [llvm-gsymutil] Fix assert failure on FileEntry.Dir empty (PR #79926)

2024-01-29 Thread via cfe-commits


https://github.com/kusmour updated 
https://github.com/llvm/llvm-project/pull/79926

>From 9536c3990f83400d6ce1a8208ccd669dc38f4ebf Mon Sep 17 00:00:00 2001
From: Wanyi Ye 
Date: Mon, 29 Jan 2024 16:01:33 -0800
Subject: [PATCH] [llvm-gsymutil] Fix assert failure on FileEntry.Dir empty

Summary:
FileEntry.Dir can be empty if debug info only contains relative path.
This caused an assertion failure when gsym segmentation is trying to copy a 
file entry with empty dir.
As the fitst entry of StringTable is always empty (and is preserved), 
`StringOffsetMap` doesn't have key 0.
Hence, `find(0)` returns `End` and `operator->()` fails the assertion

Test Plan:
./bin/llvm-lit -sv llvm/test/tools/llvm-gsymutil/X86/elf-empty-dir.yaml
---
 llvm/lib/DebugInfo/GSYM/GsymCreator.cpp   |   5 +-
 .../llvm-gsymutil/X86/elf-empty-dir.yaml  | 108 ++
 2 files changed, 112 insertions(+), 1 deletion(-)
 create mode 100644 llvm/test/tools/llvm-gsymutil/X86/elf-empty-dir.yaml

diff --git a/llvm/lib/DebugInfo/GSYM/GsymCreator.cpp 
b/llvm/lib/DebugInfo/GSYM/GsymCreator.cpp
index ee7b0efba5ea4..74138755090a4 100644
--- a/llvm/lib/DebugInfo/GSYM/GsymCreator.cpp
+++ b/llvm/lib/DebugInfo/GSYM/GsymCreator.cpp
@@ -55,7 +55,10 @@ uint32_t GsymCreator::copyFile(const GsymCreator , 
uint32_t FileIdx) {
 return 0;
   const FileEntry SrcFE = SrcGC.Files[FileIdx];
   // Copy the strings for the file and then add the newly converted file entry.
-  uint32_t Dir = StrTab.add(SrcGC.StringOffsetMap.find(SrcFE.Dir)->second);
+  uint32_t Dir =
+  SrcFE.Dir == 0
+  ? 0
+  : StrTab.add(SrcGC.StringOffsetMap.find(SrcFE.Dir)->second);
   uint32_t Base = StrTab.add(SrcGC.StringOffsetMap.find(SrcFE.Base)->second);
   FileEntry DstFE(Dir, Base);
   return insertFileEntry(DstFE);
diff --git a/llvm/test/tools/llvm-gsymutil/X86/elf-empty-dir.yaml 
b/llvm/test/tools/llvm-gsymutil/X86/elf-empty-dir.yaml
new file mode 100644
index 0..6f6acf8800488
--- /dev/null
+++ b/llvm/test/tools/llvm-gsymutil/X86/elf-empty-dir.yaml
@@ -0,0 +1,108 @@
+## Test converting DWARF using relative path
+
+# RUN: yaml2obj %s -o %t
+# RUN: llvm-gsymutil --convert %t -o %t.gsym --segment-size=10 
--num-threads=80 --quiet 2>&1 | FileCheck %s --check-prefix=CONVERT
+
+# CONVERT: Input file: {{.*\.yaml\.tmp}}
+# CONVERT: Output file (x86_64): {{.*\.yaml\.tmp\.gsym}}
+# CONVERT: Pruned 0 functions, ended with 1 total
+
+--- !ELF
+FileHeader:
+  Class:   ELFCLASS64
+  Data:ELFDATA2LSB
+  Type:ET_EXEC
+  Machine: EM_X86_64
+DWARF:
+  debug_str:
+- ''
+- main.cpp
+- foo
+  debug_abbrev:
+- ID:  0
+  Table:
+- Code:0x1
+  Tag: DW_TAG_compile_unit
+  Children:DW_CHILDREN_yes
+  Attributes:
+- Attribute:   DW_AT_name
+  Form:DW_FORM_strp
+- Attribute:   DW_AT_language
+  Form:DW_FORM_udata
+- Attribute:   DW_AT_stmt_list
+  Form:DW_FORM_sec_offset
+- Code:0x2
+  Tag: DW_TAG_subprogram
+  Children:DW_CHILDREN_no
+  Attributes:
+- Attribute:   DW_AT_name
+  Form:DW_FORM_strp
+- Attribute:   DW_AT_low_pc
+  Form:DW_FORM_addr
+- Attribute:   DW_AT_high_pc
+  Form:DW_FORM_addr
+  debug_info:
+- Length:  0x27
+  Version: 4
+  AbbrevTableID:   0
+  AbbrOffset:  0x0
+  AddrSize:8
+  Entries:
+- AbbrCode:0x1
+  Values:
+- Value:   0x1
+- Value:   0x2
+- Value:   0x0
+- AbbrCode:0x2
+  Values:
+- Value:   0xA
+- Value:   0x1000
+- Value:   0x1050
+- AbbrCode:0x0
+  debug_line:
+- Length:  66
+  Version: 2
+  PrologueLength:  31
+  MinInstLength:   1
+  DefaultIsStmt:   1
+  LineBase:251
+  LineRange:   14
+  OpcodeBase:  13
+  StandardOpcodeLengths: [ 0, 1, 1, 1, 1, 0, 0, 0, 1, 0, 0, 1 ]
+  Files:
+- Name:main.cpp
+  DirIdx:  0
+  ModTime: 0
+  Length:  0
+  Opcodes:
+- Opcode:  DW_LNS_extended_op
+  ExtLen:  9
+  SubOpcode:   DW_LNE_set_address
+  Data:4096
+- Opcode:  DW_LNS_advance_line
+  SData:   9
+  Data:0
+- Opcode:  DW_LNS_copy
+  Data:0
+- Opcode:  DW_LNS_advance_pc
+  Data:16
+- Opcode:  DW_LNS_advance_line
+  SData:   1
+  Data:

[clang] Add support for builtin_verbose_trap (PR #79230)

2024-01-29 Thread Akira Hatanaka via cfe-commits


https://github.com/ahatanak updated 
https://github.com/llvm/llvm-project/pull/79230

>From 678cd8ea37f1d02c70fd09b7107542c8301c3bd2 Mon Sep 17 00:00:00 2001
From: Akira Hatanaka 
Date: Tue, 16 Jan 2024 13:18:09 -0800
Subject: [PATCH 1/6] Add support for builtin_verbose_trap

The builtin causes the program to stop its execution abnormally and shows a
human-readable description of the reason for the termination when a debugger is
attached or in a symbolicated crash log.

The motivation for the builtin is explained in the following RFC:

https://discourse.llvm.org/t/rfc-adding-builtin-verbose-trap-string-literal/75845
---
 clang/docs/LanguageExtensions.rst | 48 ++
 clang/include/clang/AST/Expr.h|  5 ++
 clang/include/clang/Basic/Builtins.td |  6 +++
 .../clang/Basic/DiagnosticSemaKinds.td|  2 +
 clang/lib/AST/ExprConstant.cpp| 18 +--
 clang/lib/CodeGen/CGBuiltin.cpp   | 12 +
 clang/lib/CodeGen/CGDebugInfo.cpp | 42 
 clang/lib/CodeGen/CGDebugInfo.h   | 20 
 clang/lib/Sema/SemaChecking.cpp   | 22 +
 .../CodeGenCXX/debug-info-verbose-trap.cpp| 49 +++
 clang/test/SemaCXX/verbose-trap.cpp   | 28 +++
 11 files changed, 249 insertions(+), 3 deletions(-)
 create mode 100644 clang/test/CodeGenCXX/debug-info-verbose-trap.cpp
 create mode 100644 clang/test/SemaCXX/verbose-trap.cpp

diff --git a/clang/docs/LanguageExtensions.rst 
b/clang/docs/LanguageExtensions.rst
index c1420079f75118..4526bc2df53e42 100644
--- a/clang/docs/LanguageExtensions.rst
+++ b/clang/docs/LanguageExtensions.rst
@@ -3379,6 +3379,54 @@ Query for this feature with 
``__has_builtin(__builtin_debugtrap)``.
 
 Query for this feature with ``__has_builtin(__builtin_trap)``.
 
+``__builtin_verbose_trap``
+--
+
+``__builtin_verbose_trap`` causes the program to stop its execution abnormally
+and shows a human-readable description of the reason for the termination when a
+debugger is attached or in a symbolicated crash log.
+
+**Syntax**:
+
+.. code-block:: c++
+
+__builtin_verbose_trap(const char *reason)
+
+**Description**
+
+``__builtin_verbose_trap`` is lowered to the ` ``llvm.trap`` 
`_ builtin.
+Additionally, clang emits debug metadata that represents an artificial inline
+frame whose name encodes the string passed to the builtin, prefixed by a 
"magic"
+prefix.
+
+For example, consider the following code:
+
+.. code-block:: c++
+
+void foo(int* p) {
+  if (p == nullptr)
+__builtin_verbose_trap("Argument_must_not_be_null");
+}
+
+The debug metadata would look as if it were produced for the following code:
+
+.. code-block:: c++
+
+__attribute__((always_inline))
+inline void "__llvm_verbose_trap: Argument_must_not_be_null"() {
+  __builtin_trap();
+}
+
+void foo(int* p) {
+  if (p == nullptr)
+"__llvm_verbose_trap: Argument_must_not_be_null"();
+}
+
+However, the LLVM IR would not actually contain a call to the artificial
+function — it only exists in the debug metadata.
+
+Query for this feature with ``__has_builtin(__builtin_verbose_trap)``.
+
 ``__builtin_nondeterministic_value``
 
 
diff --git a/clang/include/clang/AST/Expr.h b/clang/include/clang/AST/Expr.h
index 59f0aee2c0cedd..68447b19a4a107 100644
--- a/clang/include/clang/AST/Expr.h
+++ b/clang/include/clang/AST/Expr.h
@@ -775,6 +775,11 @@ class Expr : public ValueStmt {
  const Expr *PtrExpression, ASTContext ,
  EvalResult ) const;
 
+  /// If the current Expr can be evaluated to a pointer to a null-terminated
+  /// constant string, return the constant string (without the terminating 
null)
+  /// in Result. Return true if it succeeds.
+  bool tryEvaluateString(std::string , ASTContext ) const;
+
   /// Enumeration used to describe the kind of Null pointer constant
   /// returned from \c isNullPointerConstant().
   enum NullPointerConstantKind {
diff --git a/clang/include/clang/Basic/Builtins.td 
b/clang/include/clang/Basic/Builtins.td
index 22e616e6cde599..217c09e85a55cc 100644
--- a/clang/include/clang/Basic/Builtins.td
+++ b/clang/include/clang/Basic/Builtins.td
@@ -1096,6 +1096,12 @@ def Trap : Builtin {
   let Prototype = "void()";
 }
 
+def VerboseTrap : Builtin {
+  let Spellings = ["__builtin_verbose_trap"];
+  let Attributes = [NoThrow, NoReturn];
+  let Prototype = "void(char const*)";
+}
+
 def Debugtrap : Builtin {
   let Spellings = ["__builtin_debugtrap"];
   let Attributes = [NoThrow];
diff --git a/clang/include/clang/Basic/DiagnosticSemaKinds.td 
b/clang/include/clang/Basic/DiagnosticSemaKinds.td
index a1c32abb4dcd88..40482a964b39d5 100644
--- a/clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ b/clang/include/clang/Basic/DiagnosticSemaKinds.td

[clang] [llvm] [CMake] Add a linker test for -Bsymbolic-functions to AddLLVM (PR #79539)

2024-01-29 Thread Fangrui Song via cfe-commits

MaskRay wrote:

> OpenBSD also has a local patch for linking with the old BFD linker on mips64 
> and sparc64.

What's the issue? GNU ld has had -Bsymbolic-functions since 2007 and for quite 
a few releases LLVM has been using `-Bsymbolic-functions`.

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

[clang] [RISCV][clang] Add Zvfbfwma C intrinsics support (PR #79615)

2024-01-29 Thread Jim Lin via cfe-commits



@@ -0,0 +1,479 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py 
UTC_ARGS: --version 4
+// REQUIRES: riscv-registered-target
+// RUN: %clang_cc1 -triple riscv64 -target-feature +v -target-feature +zfh \
+// RUN:   -target-feature +zvfh -target-feature +experimental-zvfbfwma 
-disable-O0-optnone  \

tclin914 wrote:

Are `-target-feature +zfh` and `-target-feature +zvfh` necessary?

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

[clang] [clang-tools-extra] [llvm] [DirectX][docs] Architecture and design philosophy of DXIL support (PR #78221)

2024-01-29 Thread Justin Bogner via cfe-commits



@@ -0,0 +1,102 @@
+===
+Architecture and Design of DXIL Support in LLVM
+===
+
+.. contents::
+   :local:
+
+.. toctree::
+   :hidden:
+
+Introduction
+
+
+LLVM supports reading and writing the `DirectX Intermediate Language.
+`_,
+or DXIL. DXIL is essentially LLVM 3.7 era bitcode with some
+restrictions and various semantically important operations and
+metadata.
+
+LLVM's implementation philosophy for DXIL support is to treat DXIL as
+merely a representation format as much as possible. When reading DXIL,
+we should translate everyting to generic LLVM constructs when
+possible. Similarly, we should introduce DXIL-specific constructs as
+late as possible in the process of lowering to the format.
+
+There are three places to look for DXIL related code in LLVM: The
+`DirectX` backend, for writing DXIL; The `DXILUpgrade` pass, for
+reading; and in library code that is shared between writing and
+reading. We'll describe these in reverse order.
+
+Common Code for Reading and Writing
+===
+
+There's quite a bit of logic that needs to be shared between reading
+and writing DXIL in order to avoid code duplication. While we don't
+have a hard and fast rule about where such code should live, there are
+generally three sensible places. Simple definitions of enums and
+values that must stay fixed to match DXIL's ABI can be found in
+`Support/DXILABI.h`, utilities to translate bidirectionally between
+DXIL and modern LLVM constructs live in `lib/Transforms/Utils`, and
+more analyses that are needed to derive or preserve information are
+implemented as typical `lib/Analysis` passes.
+
+The DXILUpgrade Pass
+
+
+Translating DXIL to LLVM IR takes advantage of the fact that DXIL is
+compatible with LLVM 3.7 bitcode, and that modern LLVM is capable of
+"upgrading" older bitcode into modern IR. Simply relying on the
+bitcode upgrade process isn't sufficient though, since that leaves a
+number of DXIL specific constructs around. Thus, we have the
+`DXILUpgrade` pass to transform DXIL operations to LLVM operations and
+smooth over differences in metadata representation.
+
+The DirectX Backend
+===
+
+The DirectX backend lowers LLVM IR into DXIL. As we're transforming to
+an intermediate format rather than a specific ISA, this backend does
+not follow the instruction selection patterns you might be familiar
+with from other backends. There are two parts to lowering DXIL - a set
+of passes that mutate various constructs into a form that matches how
+DXIL represents those constructs, followed by a limited bitcode
+"downgrader pass".
+
+Before emitting DXIL, the DirectX backend needs to modify the LLVM IR
+such that external operations, types, and metadata is represented in
+the way that DXIL expects. For example, `DXILOpLowering` translates
+intrinsics into `dx.op` calls. It's encouraged to implement parts of
+the DXIL lowering as these kinds of IR to IR passes when possible, as
+that means that they can be easily tested with `opt` and `FileCheck`
+without the need for external tooling.
+
+The second part of DXIL emission is more or less an LLVM bitcode
+downgrader. We need to emit bitcode that matches the LLVM 3.7
+representation. For this, we have `DXILWriter`, which is an alternate
+version of LLVM's `BitcodeWriter`. At present, this is able to
+leverage LLVM's current bitcode libraries to do a lot of the work, but
+it's possible that at some point in the future it will need to be
+completely separate as modern LLVM bitcode evolves.
+
+Testing

bogner wrote:

I agree with all of this but I couldn't come up with much concrete to say for 
now

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

[clang] [clang-tools-extra] [llvm] [DirectX][docs] Architecture and design philosophy of DXIL support (PR #78221)

2024-01-29 Thread Justin Bogner via cfe-commits



@@ -0,0 +1,102 @@
+===
+Architecture and Design of DXIL Support in LLVM
+===
+
+.. contents::
+   :local:
+
+.. toctree::
+   :hidden:
+
+Introduction
+
+
+LLVM supports reading and writing the `DirectX Intermediate Language.
+`_,
+or DXIL. DXIL is essentially LLVM 3.7 era bitcode with some
+restrictions and various semantically important operations and
+metadata.
+
+LLVM's implementation philosophy for DXIL support is to treat DXIL as
+merely a representation format as much as possible. When reading DXIL,
+we should translate everyting to generic LLVM constructs when
+possible. Similarly, we should introduce DXIL-specific constructs as
+late as possible in the process of lowering to the format.
+
+There are three places to look for DXIL related code in LLVM: The
+`DirectX` backend, for writing DXIL; The `DXILUpgrade` pass, for
+reading; and in library code that is shared between writing and
+reading. We'll describe these in reverse order.
+
+Common Code for Reading and Writing
+===
+
+There's quite a bit of logic that needs to be shared between reading
+and writing DXIL in order to avoid code duplication. While we don't
+have a hard and fast rule about where such code should live, there are
+generally three sensible places. Simple definitions of enums and
+values that must stay fixed to match DXIL's ABI can be found in
+`Support/DXILABI.h`, utilities to translate bidirectionally between
+DXIL and modern LLVM constructs live in `lib/Transforms/Utils`, and
+more analyses that are needed to derive or preserve information are
+implemented as typical `lib/Analysis` passes.
+
+The DXILUpgrade Pass
+
+
+Translating DXIL to LLVM IR takes advantage of the fact that DXIL is
+compatible with LLVM 3.7 bitcode, and that modern LLVM is capable of
+"upgrading" older bitcode into modern IR. Simply relying on the
+bitcode upgrade process isn't sufficient though, since that leaves a
+number of DXIL specific constructs around. Thus, we have the
+`DXILUpgrade` pass to transform DXIL operations to LLVM operations and
+smooth over differences in metadata representation.
+
+The DirectX Backend
+===
+
+The DirectX backend lowers LLVM IR into DXIL. As we're transforming to
+an intermediate format rather than a specific ISA, this backend does
+not follow the instruction selection patterns you might be familiar
+with from other backends. There are two parts to lowering DXIL - a set
+of passes that mutate various constructs into a form that matches how
+DXIL represents those constructs, followed by a limited bitcode
+"downgrader pass".
+
+Before emitting DXIL, the DirectX backend needs to modify the LLVM IR
+such that external operations, types, and metadata is represented in
+the way that DXIL expects. For example, `DXILOpLowering` translates
+intrinsics into `dx.op` calls. It's encouraged to implement parts of
+the DXIL lowering as these kinds of IR to IR passes when possible, as
+that means that they can be easily tested with `opt` and `FileCheck`
+without the need for external tooling.
+
+The second part of DXIL emission is more or less an LLVM bitcode
+downgrader. We need to emit bitcode that matches the LLVM 3.7
+representation. For this, we have `DXILWriter`, which is an alternate
+version of LLVM's `BitcodeWriter`. At present, this is able to
+leverage LLVM's current bitcode libraries to do a lot of the work, but
+it's possible that at some point in the future it will need to be
+completely separate as modern LLVM bitcode evolves.
+
+Testing
+===
+
+A lot of DXIL testing can be done with typical IR to IR tests using
+`opt` and `FileCheck`, since a lot of the support is implemented in
+terms of IR level passes as described in the previous sections. You
+can see examples of this in `llvm/test/CodeGen/DirectX` as well as
+`llvm/test/Transforms/DXILUpgrade`, and this type of testing should be
+leveraged as much as possible.
+
+However, when it comes to testing the DXIL format itself, IR passes
+are insufficient for testing. For now, the best option we have
+available is using the DXC project's tools in order to round trip.
+These tests are currently found in `test/tools/dxil-dis` and are only
+available if the `LLVM_INCLUDE_DXIL_TESTS` cmake option is set. Note
+that we do not currently have the equivalent testing set up for the
+DXIL reading path.
+
+In the future, we will also want to round trip using the DXIL writing

bogner wrote:

I've reworded this to "As soon as we are able"

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

[clang] [clang-tools-extra] [llvm] [DirectX][docs] Architecture and design philosophy of DXIL support (PR #78221)

2024-01-29 Thread Justin Bogner via cfe-commits



@@ -0,0 +1,102 @@
+===
+Architecture and Design of DXIL Support in LLVM
+===
+
+.. contents::
+   :local:
+
+.. toctree::
+   :hidden:
+
+Introduction
+
+
+LLVM supports reading and writing the `DirectX Intermediate Language.
+`_,
+or DXIL. DXIL is essentially LLVM 3.7 era bitcode with some
+restrictions and various semantically important operations and
+metadata.
+
+LLVM's implementation philosophy for DXIL support is to treat DXIL as
+merely a representation format as much as possible. When reading DXIL,
+we should translate everyting to generic LLVM constructs when
+possible. Similarly, we should introduce DXIL-specific constructs as
+late as possible in the process of lowering to the format.
+
+There are three places to look for DXIL related code in LLVM: The
+`DirectX` backend, for writing DXIL; The `DXILUpgrade` pass, for
+reading; and in library code that is shared between writing and
+reading. We'll describe these in reverse order.
+
+Common Code for Reading and Writing
+===
+
+There's quite a bit of logic that needs to be shared between reading
+and writing DXIL in order to avoid code duplication. While we don't
+have a hard and fast rule about where such code should live, there are
+generally three sensible places. Simple definitions of enums and
+values that must stay fixed to match DXIL's ABI can be found in
+`Support/DXILABI.h`, utilities to translate bidirectionally between
+DXIL and modern LLVM constructs live in `lib/Transforms/Utils`, and
+more analyses that are needed to derive or preserve information are
+implemented as typical `lib/Analysis` passes.
+
+The DXILUpgrade Pass
+
+
+Translating DXIL to LLVM IR takes advantage of the fact that DXIL is
+compatible with LLVM 3.7 bitcode, and that modern LLVM is capable of
+"upgrading" older bitcode into modern IR. Simply relying on the
+bitcode upgrade process isn't sufficient though, since that leaves a
+number of DXIL specific constructs around. Thus, we have the
+`DXILUpgrade` pass to transform DXIL operations to LLVM operations and
+smooth over differences in metadata representation.
+
+The DirectX Backend
+===
+
+The DirectX backend lowers LLVM IR into DXIL. As we're transforming to
+an intermediate format rather than a specific ISA, this backend does
+not follow the instruction selection patterns you might be familiar
+with from other backends. There are two parts to lowering DXIL - a set
+of passes that mutate various constructs into a form that matches how
+DXIL represents those constructs, followed by a limited bitcode
+"downgrader pass".
+
+Before emitting DXIL, the DirectX backend needs to modify the LLVM IR
+such that external operations, types, and metadata is represented in
+the way that DXIL expects. For example, `DXILOpLowering` translates
+intrinsics into `dx.op` calls. It's encouraged to implement parts of
+the DXIL lowering as these kinds of IR to IR passes when possible, as
+that means that they can be easily tested with `opt` and `FileCheck`
+without the need for external tooling.
+
+The second part of DXIL emission is more or less an LLVM bitcode
+downgrader. We need to emit bitcode that matches the LLVM 3.7
+representation. For this, we have `DXILWriter`, which is an alternate

bogner wrote:

I added sentences to the DXILUpgrade section and to the paragraph about 
lowering/downgrading to try to clarify this

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

[clang] [clang-tools-extra] [llvm] [DirectX][docs] Architecture and design philosophy of DXIL support (PR #78221)

2024-01-29 Thread Justin Bogner via cfe-commits



@@ -0,0 +1,102 @@
+===
+Architecture and Design of DXIL Support in LLVM
+===
+
+.. contents::
+   :local:
+
+.. toctree::
+   :hidden:
+
+Introduction
+
+
+LLVM supports reading and writing the `DirectX Intermediate Language.
+`_,
+or DXIL. DXIL is essentially LLVM 3.7 era bitcode with some
+restrictions and various semantically important operations and
+metadata.
+
+LLVM's implementation philosophy for DXIL support is to treat DXIL as
+merely a representation format as much as possible. When reading DXIL,
+we should translate everyting to generic LLVM constructs when
+possible. Similarly, we should introduce DXIL-specific constructs as
+late as possible in the process of lowering to the format.
+
+There are three places to look for DXIL related code in LLVM: The
+`DirectX` backend, for writing DXIL; The `DXILUpgrade` pass, for
+reading; and in library code that is shared between writing and
+reading. We'll describe these in reverse order.
+
+Common Code for Reading and Writing
+===
+
+There's quite a bit of logic that needs to be shared between reading
+and writing DXIL in order to avoid code duplication. While we don't
+have a hard and fast rule about where such code should live, there are
+generally three sensible places. Simple definitions of enums and
+values that must stay fixed to match DXIL's ABI can be found in
+`Support/DXILABI.h`, utilities to translate bidirectionally between
+DXIL and modern LLVM constructs live in `lib/Transforms/Utils`, and
+more analyses that are needed to derive or preserve information are
+implemented as typical `lib/Analysis` passes.
+
+The DXILUpgrade Pass
+
+
+Translating DXIL to LLVM IR takes advantage of the fact that DXIL is

bogner wrote:

Yes, of course. I added a short paragraph mentioning how this works to try to 
clarify.

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

[clang] [llvm] [clang-tools-extra] [DirectX][docs] Architecture and design philosophy of DXIL support (PR #78221)

2024-01-29 Thread Justin Bogner via cfe-commits


https://github.com/bogner updated 
https://github.com/llvm/llvm-project/pull/78221

>From 8903229f71503c1c4291254c355b1692d9d908a3 Mon Sep 17 00:00:00 2001
From: Justin Bogner 
Date: Mon, 15 Jan 2024 18:14:07 -0800
Subject: [PATCH 1/2] =?UTF-8?q?[=F0=9D=98=80=F0=9D=97=BD=F0=9D=97=BF]=20in?=
 =?UTF-8?q?itial=20version?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Created using spr 1.3.5-bogner
---
 llvm/docs/DirectX/DXILArchitecture.rst | 102 +
 llvm/docs/DirectXUsage.rst |   2 +
 2 files changed, 104 insertions(+)
 create mode 100644 llvm/docs/DirectX/DXILArchitecture.rst

diff --git a/llvm/docs/DirectX/DXILArchitecture.rst 
b/llvm/docs/DirectX/DXILArchitecture.rst
new file mode 100644
index 0..9d1edefc3a768
--- /dev/null
+++ b/llvm/docs/DirectX/DXILArchitecture.rst
@@ -0,0 +1,102 @@
+===
+Architecture and Design of DXIL Support in LLVM
+===
+
+.. contents::
+   :local:
+
+.. toctree::
+   :hidden:
+
+Introduction
+
+
+LLVM supports reading and writing the `DirectX Intermediate Language.
+`_,
+or DXIL. DXIL is essentially LLVM 3.7 era bitcode with some
+restrictions and various semantically important operations and
+metadata.
+
+LLVM's implementation philosophy for DXIL support is to treat DXIL as
+merely a representation format as much as possible. When reading DXIL,
+we should translate everyting to generic LLVM constructs when
+possible. Similarly, we should introduce DXIL-specific constructs as
+late as possible in the process of lowering to the format.
+
+There are three places to look for DXIL related code in LLVM: The
+`DirectX` backend, for writing DXIL; The `DXILUpgrade` pass, for
+reading; and in library code that is shared between writing and
+reading. We'll describe these in reverse order.
+
+Common Code for Reading and Writing
+===
+
+There's quite a bit of logic that needs to be shared between reading
+and writing DXIL in order to avoid code duplication. While we don't
+have a hard and fast rule about where such code should live, there are
+generally three sensible places. Simple definitions of enums and
+values that must stay fixed to match DXIL's ABI can be found in
+`Support/DXILABI.h`, utilities to translate bidirectionally between
+DXIL and modern LLVM constructs live in `lib/Transforms/Utils`, and
+more analyses that are needed to derive or preserve information are
+implemented as typical `lib/Analysis` passes.
+
+The DXILUpgrade Pass
+
+
+Translating DXIL to LLVM IR takes advantage of the fact that DXIL is
+compatible with LLVM 3.7 bitcode, and that modern LLVM is capable of
+"upgrading" older bitcode into modern IR. Simply relying on the
+bitcode upgrade process isn't sufficient though, since that leaves a
+number of DXIL specific constructs around. Thus, we have the
+`DXILUpgrade` pass to transform DXIL operations to LLVM operations and
+smooth over differences in metadata representation.
+
+The DirectX Backend
+===
+
+The DirectX backend lowers LLVM IR into DXIL. As we're transforming to
+an intermediate format rather than a specific ISA, this backend does
+not follow the instruction selection patterns you might be familiar
+with from other backends. There are two parts to lowering DXIL - a set
+of passes that mutate various constructs into a form that matches how
+DXIL represents those constructs, followed by a limited bitcode
+"downgrader pass".
+
+Before emitting DXIL, the DirectX backend needs to modify the LLVM IR
+such that external operations, types, and metadata is represented in
+the way that DXIL expects. For example, `DXILOpLowering` translates
+intrinsics into `dx.op` calls. It's encouraged to implement parts of
+the DXIL lowering as these kinds of IR to IR passes when possible, as
+that means that they can be easily tested with `opt` and `FileCheck`
+without the need for external tooling.
+
+The second part of DXIL emission is more or less an LLVM bitcode
+downgrader. We need to emit bitcode that matches the LLVM 3.7
+representation. For this, we have `DXILWriter`, which is an alternate
+version of LLVM's `BitcodeWriter`. At present, this is able to
+leverage LLVM's current bitcode libraries to do a lot of the work, but
+it's possible that at some point in the future it will need to be
+completely separate as modern LLVM bitcode evolves.
+
+Testing
+===
+
+A lot of DXIL testing can be one with typical IR to IR tests using
+`opt` and `FileCheck`, since a lot of the support is implemented in
+terms of IR level passes as described in the previous sections. You
+can see examples of this in `llvm/test/CodeGen/DirectX` as well as
+`llvm/test/Transforms/DXILUpgrade`, and this type of testing should be
+leveraged as much as possible.
+

[llvm] [clang] [RISCV] Relax march string order constraint (PR #78120)

2024-01-29 Thread Piyou Chen via cfe-commits


https://github.com/BeMg updated https://github.com/llvm/llvm-project/pull/78120

>From f3444e9f434a5084b16ad25981428549c5b2e151 Mon Sep 17 00:00:00 2001
From: Piyou Chen 
Date: Sun, 14 Jan 2024 19:41:59 -0800
Subject: [PATCH 1/9] [RISCV] Relax march string order constraint

---
 clang/test/Driver/riscv-arch.c  |  14 +-
 llvm/lib/Support/RISCVISAInfo.cpp   | 295 ++--
 llvm/unittests/Support/RISCVISAInfoTest.cpp |  91 --
 3 files changed, 226 insertions(+), 174 deletions(-)

diff --git a/clang/test/Driver/riscv-arch.c b/clang/test/Driver/riscv-arch.c
index 0ac81ea982f1b..38de95e4fbf7a 100644
--- a/clang/test/Driver/riscv-arch.c
+++ b/clang/test/Driver/riscv-arch.c
@@ -156,9 +156,8 @@
 // RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32L %s
 // RV32L: error: invalid arch name 'rv32l'
 
-// RUN: not %clang --target=riscv32-unknown-elf -march=rv32imadf -### %s \
-// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32IMADF %s
-// RV32IMADF: error: invalid arch name 'rv32imadf'
+// RUN: %clang --target=riscv32-unknown-elf -march=rv32imadf -### %s \
+// RUN: -fsyntax-only 2>&1 | FileCheck %s
 
 // RUN: not %clang --target=riscv32-unknown-elf -march=rv32imm -### %s \
 // RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32IMM %s
@@ -184,9 +183,8 @@
 // RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV64L %s
 // RV64L: error: invalid arch name 'rv64l'
 
-// RUN: not %clang --target=riscv64-unknown-elf -march=rv64imadf -### %s \
-// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV64IMADF %s
-// RV64IMADF: error: invalid arch name 'rv64imadf'
+// RUN: %clang --target=riscv64-unknown-elf -march=rv64imadf -### %s \
+// RUN: -fsyntax-only 2>&1 | FileCheck %s
 
 // RUN: not %clang --target=riscv64-unknown-elf -march=rv64imm -### %s \
 // RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV64IMM %s
@@ -216,7 +214,7 @@
 // RUN: not %clang --target=riscv32-unknown-elf -march=rv32imcq -### %s \
 // RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-ORDER %s
 // RV32-ORDER: error: invalid arch name 'rv32imcq',
-// RV32-ORDER: standard user-level extension not given in canonical order 'q'
+// RV32-ORDER: unsupported standard user-level extension 'q'
 
 // RUN: not %clang --target=riscv32-unknown-elf -march=rv32izvl64b -### %s \
 // RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-ZVL64B-ER %s
@@ -318,7 +316,7 @@
 // RUN: not %clang --target=riscv32-unknown-elf -march=rv32ixabc_a -### %s \
 // RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-PREFIX %s
 // RV32-PREFIX: error: invalid arch name 'rv32ixabc_a',
-// RV32-PREFIX: invalid extension prefix 'a'
+// RV32-PREFIX: unsupported non-standard user-level extension 'xabc'
 
 // RUN: not %clang --target=riscv32-unknown-elf -march=rv32ixdef_sabc -### %s \
 // RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-X-ORDER %s
diff --git a/llvm/lib/Support/RISCVISAInfo.cpp 
b/llvm/lib/Support/RISCVISAInfo.cpp
index c46d76da962c6..61ac5769b5d33 100644
--- a/llvm/lib/Support/RISCVISAInfo.cpp
+++ b/llvm/lib/Support/RISCVISAInfo.cpp
@@ -703,6 +703,106 @@ RISCVISAInfo::parseNormalizedArchString(StringRef Arch) {
   return std::move(ISAInfo);
 }
 
+static Error splitExtsByUnderscore(StringRef Exts,
+   std::vector ) {
+  SmallVector Split;
+  if (Exts.empty())
+return Error::success();
+
+  Exts.split(Split, "_");
+
+  for (auto Ext : Split) {
+if (Ext.empty())
+  return createStringError(errc::invalid_argument,
+   "extension name missing after separator '_'");
+
+SplitedExts.push_back(Ext.str());
+  }
+  return Error::success();
+}
+
+static Error processMultiLetterExtension(
+StringRef RawExt, SmallVector ,
+SmallVector ,
+bool IgnoreUnknown, bool EnableExperimentalExtension,
+bool ExperimentalExtensionVersionCheck) {
+  StringRef Type = getExtensionType(RawExt);
+  StringRef Desc = getExtensionTypeDesc(RawExt);
+  auto Pos = findLastNonVersionCharacter(RawExt) + 1;
+  StringRef Name(RawExt.substr(0, Pos));
+  StringRef Vers(RawExt.substr(Pos));
+
+  if (Type.empty()) {
+if (IgnoreUnknown)
+  return Error::success();
+return createStringError(errc::invalid_argument,
+ "invalid extension prefix '" + RawExt + "'");
+  }
+
+  if (!IgnoreUnknown && Name.size() == Type.size())
+return createStringError(errc::invalid_argument,
+ "%s name missing after '%s'", Desc.str().c_str(),
+ Type.str().c_str());
+
+  unsigned Major, Minor, ConsumeLength;
+  if (auto E = getExtensionVersion(Name, Vers, Major, Minor, ConsumeLength,
+   EnableExperimentalExtension,
+   ExperimentalExtensionVersionCheck)) {
+if (IgnoreUnknown) {
+  consumeError(std::move(E));
+  return Error::success();
+}
+return E;
+  }
+
+  // Check if duplicated extension.
+  if

[llvm] [clang] [clang][DependencyScanner] Remove unused -ivfsoverlay files (PR #73734)

2024-01-29 Thread Michael Spencer via cfe-commits


https://github.com/Bigcheese updated 
https://github.com/llvm/llvm-project/pull/73734

>From 0559ec44d2d3c39292bae6d6431dde9626ac755e Mon Sep 17 00:00:00 2001
From: Michael Spencer 
Date: Fri, 24 Feb 2023 17:18:51 -0800
Subject: [PATCH 1/2] [clang][DepScan] Remove unused -ivfsoverlay files

`-ivfsoverlay` files are unused when building most modules. Enable
removing them by,
* adding a way to visit the filesystem tree with extensible RTTI to
  access each `RedirectingFileSystem`.
* Adding tracking to `RedirectingFileSystem` to record when it
  actually redirects a file access.
* Storing this information in each PCM.

Usage tracking is only enabled when iterating over the source manager
and affecting modulemaps. Here each path is stated to cause an access.
During scanning these stats all hit the cache.
---
 .../Basic/DiagnosticSerializationKinds.td |   3 +
 clang/include/clang/Basic/FileManager.h   |   4 +
 clang/include/clang/Lex/HeaderSearch.h|   6 +
 clang/include/clang/Lex/HeaderSearchOptions.h |   6 +-
 .../include/clang/Serialization/ASTBitCodes.h |   3 +
 clang/include/clang/Serialization/ASTReader.h |  16 +-
 .../include/clang/Serialization/ModuleFile.h  |   3 +
 .../DependencyScanningFilesystem.h|   6 +-
 .../DependencyScanningService.h   |  11 +-
 clang/lib/Basic/FileManager.cpp   |   7 +
 clang/lib/Frontend/CompilerInvocation.cpp |   1 +
 clang/lib/Lex/HeaderSearch.cpp|  16 ++
 clang/lib/Serialization/ASTReader.cpp |  41 ++--
 clang/lib/Serialization/ASTWriter.cpp |  41 +++-
 .../DependencyScanningFilesystem.cpp  |   6 +-
 .../DependencyScanningWorker.cpp  |  86 ++--
 .../DependencyScanning/ModuleDepCollector.cpp |  74 +--
 .../ClangScanDeps/optimize-vfs-edgecases.m|  84 
 clang/test/ClangScanDeps/optimize-vfs-leak.m  | 105 ++
 clang/test/ClangScanDeps/optimize-vfs-pch.m   | 129 
 clang/test/ClangScanDeps/optimize-vfs.m   | 193 ++
 clang/tools/clang-scan-deps/ClangScanDeps.cpp |   1 +
 llvm/include/llvm/Support/VirtualFileSystem.h |  55 -
 llvm/lib/Support/VirtualFileSystem.cpp|  26 +++
 .../Support/VirtualFileSystemTest.cpp |  86 
 25 files changed, 932 insertions(+), 77 deletions(-)
 create mode 100644 clang/test/ClangScanDeps/optimize-vfs-edgecases.m
 create mode 100644 clang/test/ClangScanDeps/optimize-vfs-leak.m
 create mode 100644 clang/test/ClangScanDeps/optimize-vfs-pch.m
 create mode 100644 clang/test/ClangScanDeps/optimize-vfs.m

diff --git a/clang/include/clang/Basic/DiagnosticSerializationKinds.td 
b/clang/include/clang/Basic/DiagnosticSerializationKinds.td
index 11c706ebf84b54..4c4659ed517e0a 100644
--- a/clang/include/clang/Basic/DiagnosticSerializationKinds.td
+++ b/clang/include/clang/Basic/DiagnosticSerializationKinds.td
@@ -44,6 +44,9 @@ def err_pch_diagopt_mismatch : Error<"%0 is currently 
enabled, but was not in "
   "the PCH file">;
 def err_pch_modulecache_mismatch : Error<"PCH was compiled with module cache "
   "path '%0', but the path is currently '%1'">;
+def err_pch_vfsoverlay_mismatch : Error<"PCH was compiled with different VFS 
overlay files than are currently in use">;
+def note_pch_vfsoverlay_files : Note<"%select{PCH|current translation unit}0 
has the following VFS overlays:\n%1">;
+def note_pch_vfsoverlay_empty : Note<"%select{PCH|current translation unit}0 
has no VFS overlays">;
 
 def err_pch_version_too_old : Error<
 "PCH file uses an older PCH format that is no longer supported">;
diff --git a/clang/include/clang/Basic/FileManager.h 
b/clang/include/clang/Basic/FileManager.h
index 56cb093dd8c376..997c17a0ffcfcc 100644
--- a/clang/include/clang/Basic/FileManager.h
+++ b/clang/include/clang/Basic/FileManager.h
@@ -248,6 +248,10 @@ class FileManager : public RefCountedBase {
 return FS;
   }
 
+  /// Enable or disable tracking of VFS usage. Used to not track full header
+  /// search and implicit modulemap lookup.
+  void trackVFSUsage(bool Active);
+
   void setVirtualFileSystem(IntrusiveRefCntPtr FS) {
 this->FS = std::move(FS);
   }
diff --git a/clang/include/clang/Lex/HeaderSearch.h 
b/clang/include/clang/Lex/HeaderSearch.h
index a2c33842924b10..49e1a4a124b55d 100644
--- a/clang/include/clang/Lex/HeaderSearch.h
+++ b/clang/include/clang/Lex/HeaderSearch.h
@@ -576,6 +576,12 @@ class HeaderSearch {
   /// Note: implicit module maps don't contribute to entry usage.
   std::vector computeUserEntryUsage() const;
 
+  /// Determine which HeaderSearchOptions::VFSOverlayFiles have been
+  /// successfully used so far and mark their index with 'true' in the 
resulting
+  /// bit vector.
+  /// Note: implicit module maps don't contribute to entry usage.
+  std::vector computeVFSUsageAndClear() const;
+
   /// This method returns a HeaderMap for the specified
   /// FileEntry, uniquing them through the 'HeaderMaps' datastructure.
   const HeaderMap

[clang] [llvm] [RISCV][MC] MC layer support for the experimental zalasr extension (PR #79911)

2024-01-29 Thread Craig Topper via cfe-commits



@@ -0,0 +1,66 @@
+//===-- RISCVInstrInfoZalasr.td - RISC-V 'Zalasr' instructions ---*- 
tablegen -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// This file describes the RISC-V instructions from the Zalasr (Load-Acquire
+// and Store-Release) extension
+//
+//===--===//
+
+//===--===//
+// Instruction class templates
+//===--===//
+
+let hasSideEffects = 0, mayLoad = 1, mayStore = 0 in
+class LAQ_r funct3, string opcodestr>
+: RVInstRAtomic<0b00110, aq, rl, funct3, OPC_AMO,
+(outs GPR:$rd), (ins GPRMemZeroOffset:$rs1),
+opcodestr, "$rd, $rs1"> {
+  let rs2 = 0;
+}
+
+let hasSideEffects = 0, mayLoad = 0, mayStore = 1 in
+class SRL_r funct3, string opcodestr>
+: RVInstRAtomic<0b00111, aq, rl, funct3, OPC_AMO,
+(outs ), (ins GPRMemZeroOffset:$rs1, GPR:$rs2),
+opcodestr, "$rs2, $rs1"> {
+  let rd = 0;
+}
+multiclass LAQ_r_aq_rl funct3, string opcodestr> {
+  def _AQ: LAQ_r<1, 0, funct3, opcodestr # ".aq">;
+  def _AQ_RL : LAQ_r<1, 1, funct3, opcodestr # ".aqrl">;
+}
+
+multiclass SRL_r_aq_rl funct3, string opcodestr> {
+  def _RL: SRL_r<0, 1, funct3, opcodestr # ".rl">;
+  def _AQ_RL : SRL_r<1, 1, funct3, opcodestr # ".aqrl">;
+}
+
+//===--===//
+// Instructions
+//===--===//
+
+
+let Predicates = [HasStdExtZalasr] in {
+defm LB_AQ : LAQ_r_aq_rl<0b000, "lb">;

topperc wrote:

> It does not -- looking at the .inc file, they appear to work as well (and in 
> my manual assembly test). This will still break if versions without .aq/.rl 
> are added, but maybe that is OK?

I think its ok. I think the instruction names we use in RISCVGenInstrInfo.inc 
try to match the mnemonic with periods replaced with underscores. If versions 
without .aq/.rl are added, the mnemonics would clash with the base load/store 
instructions. They would need to be given new mnemonics that would resolve that 
clash and we could use those mnemonics to name the instructions.

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

[clang] [RISCV][clang] Add Zvfbfwma C intrinsics support (PR #79615)

2024-01-29 Thread Craig Topper via cfe-commits



@@ -1730,12 +1730,26 @@ let ManualCodegen = [{
 defm vfwnmacc : RVVFloatingWidenTerBuiltinSetRoundingMode;
 defm vfwmsac  : RVVFloatingWidenTerBuiltinSetRoundingMode;
 defm vfwnmsac : RVVFloatingWidenTerBuiltinSetRoundingMode;
+
+// Vector BF16 widening multiply-accumulate
+let Log2LMUL = [-2, -1, 0, 1, 2],

topperc wrote:

Do we need a RequiredFeatures for this?

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

[clang] [Clang][Frontend] Fix a crash when -Wdocumentation is used (PR #68525)

2024-01-29 Thread Byoungchan Lee via cfe-commits


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

[clang] [llvm] [RISCV][MC] MC layer support for the experimental zalasr extension (PR #79911)

2024-01-29 Thread Brendan Sweeney via cfe-commits



@@ -0,0 +1,66 @@
+//===-- RISCVInstrInfoZalasr.td - RISC-V 'Zalasr' instructions ---*- 
tablegen -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// This file describes the RISC-V instructions from the Zalasr (Load-Acquire
+// and Store-Release) extension
+//
+//===--===//
+
+//===--===//
+// Instruction class templates
+//===--===//
+
+let hasSideEffects = 0, mayLoad = 1, mayStore = 0 in
+class LAQ_r funct3, string opcodestr>
+: RVInstRAtomic<0b00110, aq, rl, funct3, OPC_AMO,
+(outs GPR:$rd), (ins GPRMemZeroOffset:$rs1),
+opcodestr, "$rd, $rs1"> {
+  let rs2 = 0;
+}
+
+let hasSideEffects = 0, mayLoad = 0, mayStore = 1 in
+class SRL_r funct3, string opcodestr>
+: RVInstRAtomic<0b00111, aq, rl, funct3, OPC_AMO,
+(outs ), (ins GPRMemZeroOffset:$rs1, GPR:$rs2),
+opcodestr, "$rs2, $rs1"> {
+  let rd = 0;
+}
+multiclass LAQ_r_aq_rl funct3, string opcodestr> {
+  def _AQ: LAQ_r<1, 0, funct3, opcodestr # ".aq">;
+  def _AQ_RL : LAQ_r<1, 1, funct3, opcodestr # ".aqrl">;
+}
+
+multiclass SRL_r_aq_rl funct3, string opcodestr> {
+  def _RL: SRL_r<0, 1, funct3, opcodestr # ".rl">;
+  def _AQ_RL : SRL_r<1, 1, funct3, opcodestr # ".aqrl">;
+}
+
+//===--===//
+// Instructions
+//===--===//
+
+
+let Predicates = [HasStdExtZalasr] in {
+defm LB_AQ : LAQ_r_aq_rl<0b000, "lb">;

mehnadnerd wrote:

It does not -- looking at the .inc file, they appear to work as well (and in my 
manual assembly test). This will still break if versions without .aq/.rl are 
added, but maybe that is OK?

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

[clang] [RISCV][clang] Add Zvfbfmin C intrinsics support (PR #79618)

2024-01-29 Thread Craig Topper via cfe-commits


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

LGTM

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

[compiler-rt] [clang-tools-extra] [lldb] [libcxx] [openmp] [flang] [clang] [llvm] [OpenMP] Add memory diff dump for kernel record-replay (PR #70667)

2024-01-29 Thread via cfe-commits


https://github.com/nmustakin updated 
https://github.com/llvm/llvm-project/pull/70667

>From 153c6d812939cd23bb71e53c71378117ed5b23c7 Mon Sep 17 00:00:00 2001
From: Nafis Mustakin 
Date: Mon, 30 Oct 2023 07:50:59 -0700
Subject: [PATCH 1/6] Add memory diff dump for kernel record-replay

---
 .../PluginInterface/PluginInterface.cpp   | 65 +++
 1 file changed, 54 insertions(+), 11 deletions(-)

diff --git 
a/openmp/libomptarget/plugins-nextgen/common/PluginInterface/PluginInterface.cpp
 
b/openmp/libomptarget/plugins-nextgen/common/PluginInterface/PluginInterface.cpp
index 0243f0205dbf0..8469e8eaf1593 100644
--- 
a/openmp/libomptarget/plugins-nextgen/common/PluginInterface/PluginInterface.cpp
+++ 
b/openmp/libomptarget/plugins-nextgen/common/PluginInterface/PluginInterface.cpp
@@ -83,7 +83,7 @@ struct RecordReplayTy {
 return Plugin::success();
   }
 
-  void dumpDeviceMemory(StringRef Filename) {
+  void dumpDeviceMemory(StringRef Filename, bool saveDiff) {
 ErrorOr> DeviceMemoryMB =
 WritableMemoryBuffer::getNewUninitMemBuffer(MemorySize);
 if (!DeviceMemoryMB)
@@ -93,15 +93,58 @@ struct RecordReplayTy {
 MemoryStart, MemorySize, nullptr);
 if (Err)
   report_fatal_error("Error retrieving data for target pointer");
-
-StringRef DeviceMemory(DeviceMemoryMB.get()->getBufferStart(), MemorySize);
-std::error_code EC;
-raw_fd_ostream OS(Filename, EC);
-if (EC)
+
+std::error_code EC; 
+raw_fd_ostream OS(Filename, EC); 
+if(EC)
   report_fatal_error("Error dumping memory to file " + Filename + " :" +
  EC.message());
-OS << DeviceMemory;
-OS.close();
+
+if (saveDiff){
+  //Get the pre-record memory filename  
+  SmallString<128> InputFilename = {Filename.split('.').first, ".memory"};
+  //read the pre-record memorydump
+  auto InputFileBuffer = MemoryBuffer::getFileOrSTDIN(InputFilename); 
+  if(std::error_code EC = InputFileBuffer.getError())
+report_fatal_error("Error reading pre-record device memory");
+  
+  StringRef InputBufferContents = (*InputFileBuffer)->getBuffer(); 
+  if(InputBufferContents.size() != MemorySize) 
+report_fatal_error("Error: Pre-record device memory size mismatch");
+  
+  //get current memory contents
+  StringRef DeviceMemoryContents(DeviceMemoryMB.get()->getBuffer().data(),
+ DeviceMemoryMB.get()->getBuffer().size());
+  
+  //compare pre-record memorydump to current contents
+  size_t i = 0;
+  while(i < MemorySize){
+//if mismatch found, create a new diff line
+//current format - location, size, differences ...
+if(InputBufferContents[i] != DeviceMemoryContents[i]){
+  OS << i << " "; //marks the start offset
+  SmallVector modified; 
+  modified.push_back(DeviceMemoryContents[i]);
+  size_t j = 1;
+  //loop until next match is found
+  while(InputBufferContents[i+j] != DeviceMemoryContents[i+j]){
+modified.push_back(DeviceMemoryContents[i+j]);
+j++;
+  }
+  OS << j << " "; //marks the length of the mismatching sequence
+  for(const auto  : modified)
+OS << value << " ";
+  OS << "\n"; 
+  i+=j+1; 
+}
+else i++; 
+  }
+}
+else {
+  StringRef DeviceMemory(DeviceMemoryMB.get()->getBufferStart(), 
MemorySize);
+  OS << DeviceMemory;
+}
+OS.close();  
   }
 
 public:
@@ -209,7 +252,7 @@ struct RecordReplayTy {
 JsonKernelInfo["ArgOffsets"] = json::Value(std::move(JsonArgOffsets));
 
 SmallString<128> MemoryFilename = {Name, ".memory"};
-dumpDeviceMemory(MemoryFilename);
+dumpDeviceMemory(MemoryFilename, false);
 
 SmallString<128> GlobalsFilename = {Name, ".globals"};
 dumpGlobals(GlobalsFilename, Image);
@@ -227,7 +270,7 @@ struct RecordReplayTy {
   void saveKernelOutputInfo(const char *Name) {
 SmallString<128> OutputFilename = {
 Name, (isRecording() ? ".original.output" : ".replay.output")};
-dumpDeviceMemory(OutputFilename);
+dumpDeviceMemory(OutputFilename, true);
   }
 
   void *alloc(uint64_t Size) {
@@ -1307,7 +1350,7 @@ Error GenericDeviceTy::launchKernel(void *EntryPtr, void 
**ArgPtrs,
 GenericKernel.getName(), GenericKernel.getImage(), ArgPtrs, ArgOffsets,
 KernelArgs.NumArgs, KernelArgs.NumTeams[0], KernelArgs.ThreadLimit[0],
 KernelArgs.Tripcount);
-
+   
   if (RecordReplay.isRecording())
 RecordReplay.saveImage(GenericKernel.getName(), GenericKernel.getImage());
 

>From 8daffad57074dd09287d321acd79c74a667eb65f Mon Sep 17 00:00:00 2001
From: Nafis Mustakin 
Date: Mon, 30 Oct 2023 08:39:40 -0700
Subject: [PATCH 2/6] Fix clang-formatting issues, accept reviewed suggestions

---
 .../PluginInterface/PluginInterface.cpp   | 78

[clang] [llvm] [coroutine] Implement llvm.coro.await.suspend intrinsic (PR #79712)

2024-01-29 Thread via cfe-commits


fpasserby wrote:

Thank you for replying so quickly. 
Your suggestion about `IsSuspendNoThrow` makes sense, it's totally possible to 
perform the check during codegen. 
About `helperFunction` - this is how I understood the comment in 
`SemaCoroutine.cpp` near the place where `std::coroutine_handle::address()` is 
marked as always inline. As far as I can see, it makes perfect sense to hide 
all the temporary objects till coroutine frame is formed, given the history of 
optimizations and sanitizers messing it up. For example, current implementation 
seems to work correctly with the reproducer from #72006.
For other suggestions - I hope, I've fixed up AST serialization and added some 
documentation. Will add LLVM transformation tests a bit later.

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

[clang] [llvm] [coroutine] Implement llvm.coro.await.suspend intrinsic (PR #79712)

2024-01-29 Thread via cfe-commits


https://github.com/fpasserby updated 
https://github.com/llvm/llvm-project/pull/79712

>From 7f767bcc0fe44b3d4960e4a47aab4cc857471f00 Mon Sep 17 00:00:00 2001
From: fpasserby <125797601+fpasse...@users.noreply.github.com>
Date: Sun, 28 Jan 2024 00:02:15 +0100
Subject: [PATCH 1/4] Implement llvm.coro.await.suspend intrinsic

---
 clang/include/clang/AST/ExprCXX.h |  28 ++-
 clang/lib/CodeGen/CGCoroutine.cpp | 144 +--
 clang/lib/CodeGen/CodeGenFunction.h   |   4 +
 clang/lib/Sema/SemaCoroutine.cpp  | 160 +
 clang/test/AST/coroutine-locals-cleanup.cpp   |  10 +-
 .../CodeGenCoroutines/coro-always-inline.cpp  |   2 +-
 clang/test/CodeGenCoroutines/coro-await.cpp   |  79 ++--
 .../coro-awaiter-noinline-suspend.cpp | 168 --
 clang/test/CodeGenCoroutines/coro-dwarf.cpp   |  12 ++
 .../coro-function-try-block.cpp   |   2 +-
 .../coro-simplify-suspend-point.cpp   |  66 +++
 .../coro-symmetric-transfer-01.cpp|   8 +-
 .../coro-symmetric-transfer-02.cpp|  12 +-
 clang/test/CodeGenCoroutines/pr59181.cpp  |   9 +-
 clang/test/SemaCXX/co_await-ast.cpp   |   7 +-
 llvm/include/llvm/IR/Intrinsics.td|  12 ++
 llvm/lib/IR/Verifier.cpp  |   3 +
 llvm/lib/Transforms/Coroutines/CoroInstr.h|  30 
 llvm/lib/Transforms/Coroutines/CoroSplit.cpp  | 132 +-
 llvm/lib/Transforms/Coroutines/Coroutines.cpp |   3 +
 20 files changed, 573 insertions(+), 318 deletions(-)
 delete mode 100644 
clang/test/CodeGenCoroutines/coro-awaiter-noinline-suspend.cpp
 create mode 100644 clang/test/CodeGenCoroutines/coro-simplify-suspend-point.cpp

diff --git a/clang/include/clang/AST/ExprCXX.h 
b/clang/include/clang/AST/ExprCXX.h
index a0e467b35778c5c..57a505036def409 100644
--- a/clang/include/clang/AST/ExprCXX.h
+++ b/clang/include/clang/AST/ExprCXX.h
@@ -5035,15 +5035,19 @@ class CoroutineSuspendExpr : public Expr {
   enum SubExpr { Operand, Common, Ready, Suspend, Resume, Count };
 
   Stmt *SubExprs[SubExpr::Count];
+  bool IsSuspendNoThrow = false;
   OpaqueValueExpr *OpaqueValue = nullptr;
+  OpaqueValueExpr *OpaqueFramePtr = nullptr;
 
 public:
   CoroutineSuspendExpr(StmtClass SC, SourceLocation KeywordLoc, Expr *Operand,
Expr *Common, Expr *Ready, Expr *Suspend, Expr *Resume,
-   OpaqueValueExpr *OpaqueValue)
+   bool IsSuspendNoThrow, OpaqueValueExpr *OpaqueValue,
+   OpaqueValueExpr *OpaqueFramePtr)
   : Expr(SC, Resume->getType(), Resume->getValueKind(),
  Resume->getObjectKind()),
-KeywordLoc(KeywordLoc), OpaqueValue(OpaqueValue) {
+KeywordLoc(KeywordLoc), IsSuspendNoThrow(IsSuspendNoThrow),
+OpaqueValue(OpaqueValue), OpaqueFramePtr(OpaqueFramePtr) {
 SubExprs[SubExpr::Operand] = Operand;
 SubExprs[SubExpr::Common] = Common;
 SubExprs[SubExpr::Ready] = Ready;
@@ -5080,6 +5084,9 @@ class CoroutineSuspendExpr : public Expr {
   /// getOpaqueValue - Return the opaque value placeholder.
   OpaqueValueExpr *getOpaqueValue() const { return OpaqueValue; }
 
+  /// getOpaqueFramePtr - Return coroutine frame pointer placeholder.
+  OpaqueValueExpr *getOpaqueFramePtr() const { return OpaqueFramePtr; }
+
   Expr *getReadyExpr() const {
 return static_cast(SubExprs[SubExpr::Ready]);
   }
@@ -5097,6 +5104,8 @@ class CoroutineSuspendExpr : public Expr {
 return static_cast(SubExprs[SubExpr::Operand]);
   }
 
+  bool isSuspendNoThrow() const { return IsSuspendNoThrow; }
+
   SourceLocation getKeywordLoc() const { return KeywordLoc; }
 
   SourceLocation getBeginLoc() const LLVM_READONLY { return KeywordLoc; }
@@ -5125,10 +5134,12 @@ class CoawaitExpr : public CoroutineSuspendExpr {
 
 public:
   CoawaitExpr(SourceLocation CoawaitLoc, Expr *Operand, Expr *Common,
-  Expr *Ready, Expr *Suspend, Expr *Resume,
-  OpaqueValueExpr *OpaqueValue, bool IsImplicit = false)
+  Expr *Ready, Expr *Suspend, Expr *Resume, bool IsSuspendNoThrow,
+  OpaqueValueExpr *OpaqueValue, OpaqueValueExpr *OpaqueFramePtr,
+  bool IsImplicit = false)
   : CoroutineSuspendExpr(CoawaitExprClass, CoawaitLoc, Operand, Common,
- Ready, Suspend, Resume, OpaqueValue) {
+ Ready, Suspend, Resume, IsSuspendNoThrow,
+ OpaqueValue, OpaqueFramePtr) {
 CoawaitBits.IsImplicit = IsImplicit;
   }
 
@@ -5206,10 +5217,11 @@ class CoyieldExpr : public CoroutineSuspendExpr {
 
 public:
   CoyieldExpr(SourceLocation CoyieldLoc, Expr *Operand, Expr *Common,
-  Expr *Ready, Expr *Suspend, Expr *Resume,
-  OpaqueValueExpr *OpaqueValue)
+  Expr *Ready, Expr *Suspend, Expr *Resume, bool IsSuspendNoThrow,
+  OpaqueValueExpr *OpaqueValue, OpaqueValueExpr

[clang] [CUDA] Change 'activemask' to use 'nvvm_activemask()' (PR #79892)

2024-01-29 Thread Joseph Huber via cfe-commits


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

[clang] 51379a9 - [CUDA] Change 'activemask' to use 'nvvm_activemask()' (#79892)

2024-01-29 Thread via cfe-commits


Author: Joseph Huber
Date: 2024-01-29T17:34:45-06:00
New Revision: 51379a982efc64eb319ba6f4c1af4dce31af499a

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

LOG: [CUDA] Change '__activemask' to use '__nvvm_activemask()' (#79892)

Summary:
We recently added builitin support for this function.

Added: 


Modified: 
clang/lib/Headers/__clang_cuda_intrinsics.h

Removed: 




diff  --git a/clang/lib/Headers/__clang_cuda_intrinsics.h 
b/clang/lib/Headers/__clang_cuda_intrinsics.h
index 3c3948863c1d45..a04e8b6de44d05 100644
--- a/clang/lib/Headers/__clang_cuda_intrinsics.h
+++ b/clang/lib/Headers/__clang_cuda_intrinsics.h
@@ -215,9 +215,7 @@ inline __device__ unsigned int __activemask() {
 #if CUDA_VERSION < 9020
   return __nvvm_vote_ballot(1);
 #else
-  unsigned int mask;
-  asm volatile("activemask.b32 %0;" : "=r"(mask));
-  return mask;
+  return __nvvm_activemask();
 #endif
 }
 



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

[clang] 0a2b5b0 - [NVPTX][Fix] Ensure the return value of 'activemask' is unsigned

2024-01-29 Thread Joseph Huber via cfe-commits


Author: Joseph Huber
Date: 2024-01-29T17:33:38-06:00
New Revision: 0a2b5b03c4084ac1fefd0e62db2ba49f5ac24ab9

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

LOG: [NVPTX][Fix] Ensure the return value of 'activemask' is unsigned

Summary:
The previous patch missed the `U` prefix, which caused the mask to be
considered signed. This meant that conversions would incorrectly treat a
full mask as a negative number and break things.

Added: 


Modified: 
clang/include/clang/Basic/BuiltinsNVPTX.def

Removed: 




diff  --git a/clang/include/clang/Basic/BuiltinsNVPTX.def 
b/clang/include/clang/Basic/BuiltinsNVPTX.def
index 648c013a3002e..7819e71d7fe2a 100644
--- a/clang/include/clang/Basic/BuiltinsNVPTX.def
+++ b/clang/include/clang/Basic/BuiltinsNVPTX.def
@@ -159,7 +159,7 @@ BUILTIN(__nvvm_read_ptx_sreg_pm3, "i", "n")
 
 BUILTIN(__nvvm_prmt, "UiUiUiUi", "")
 BUILTIN(__nvvm_exit, "v", "r")
-TARGET_BUILTIN(__nvvm_nanosleep, "vi", "n", AND(SM_70, PTX63))
+TARGET_BUILTIN(__nvvm_nanosleep, "vUi", "n", AND(SM_70, PTX63))
 
 // Min Max
 
@@ -638,7 +638,7 @@ TARGET_BUILTIN(__nvvm_vote_uni_sync, "bUib", "", PTX60)
 TARGET_BUILTIN(__nvvm_vote_ballot_sync, "UiUib", "", PTX60)
 
 // Mask
-TARGET_BUILTIN(__nvvm_activemask, "i", "n", PTX62)
+TARGET_BUILTIN(__nvvm_activemask, "Ui", "n", PTX62)
 
 // Match
 TARGET_BUILTIN(__nvvm_match_any_sync_i32, "UiUiUi", "", AND(SM_70,PTX60))



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

[clang] [llvm] [RISCV][MC] MC layer support for the experimental zalasr extension (PR #79911)

2024-01-29 Thread Craig Topper via cfe-commits



@@ -0,0 +1,66 @@
+//===-- RISCVInstrInfoZalasr.td - RISC-V 'Zalasr' instructions ---*- 
tablegen -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// This file describes the RISC-V instructions from the Zalasr (Load-Acquire
+// and Store-Release) extension
+//
+//===--===//
+
+//===--===//
+// Instruction class templates
+//===--===//
+
+let hasSideEffects = 0, mayLoad = 1, mayStore = 0 in
+class LAQ_r funct3, string opcodestr>
+: RVInstRAtomic<0b00110, aq, rl, funct3, OPC_AMO,
+(outs GPR:$rd), (ins GPRMemZeroOffset:$rs1),
+opcodestr, "$rd, $rs1"> {
+  let rs2 = 0;
+}
+
+let hasSideEffects = 0, mayLoad = 0, mayStore = 1 in
+class SRL_r funct3, string opcodestr>
+: RVInstRAtomic<0b00111, aq, rl, funct3, OPC_AMO,
+(outs ), (ins GPRMemZeroOffset:$rs1, GPR:$rs2),
+opcodestr, "$rs2, $rs1"> {
+  let rd = 0;
+}
+multiclass LAQ_r_aq_rl funct3, string opcodestr> {
+  def _AQ: LAQ_r<1, 0, funct3, opcodestr # ".aq">;
+  def _AQ_RL : LAQ_r<1, 1, funct3, opcodestr # ".aqrl">;
+}
+
+multiclass SRL_r_aq_rl funct3, string opcodestr> {
+  def _RL: SRL_r<0, 1, funct3, opcodestr # ".rl">;
+  def _AQ_RL : SRL_r<1, 1, funct3, opcodestr # ".aqrl">;
+}
+
+//===--===//
+// Instructions
+//===--===//
+
+
+let Predicates = [HasStdExtZalasr] in {
+defm LB_AQ : LAQ_r_aq_rl<0b000, "lb">;

topperc wrote:

> Yes it does. I couldn't come up with a better alternative--since it would be 
> possible to encode this with neither bit set, which should just be a LB 
> without an immediate. That isn't useful, and so it wasn't included in the 
> extension, but there is the ability to specify it encoding-wise.
> 
> Also, it can't be named LB for the same reason--it would conflict with plain 
> LB. The alternative is LB. (with a period/underscore after), but that is even 
> more confusing. I decided for both this and riscv-opcodes that this was the 
> simplest way--but it would lead to issues if there was a load-release, it 
> would be named LB_AQ_RL which would be confusing with LB_AQ_AQ_RL.

Does the build fail if you name it LB here?

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

[clang] [CUDA] Change 'activemask' to use 'nvvm_activemask()' (PR #79892)

2024-01-29 Thread Joseph Huber via cfe-commits


jhuber6 wrote:

Scratch that, I missed `Ui` in the builtin definition. I'll do a quick fix.

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

[clang] [llvm] [RISCV][MC] MC layer support for the experimental zalasr extension (PR #79911)

2024-01-29 Thread Brendan Sweeney via cfe-commits



@@ -0,0 +1,66 @@
+//===-- RISCVInstrInfoZalasr.td - RISC-V 'Zalasr' instructions ---*- 
tablegen -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// This file describes the RISC-V instructions from the Zalasr (Load-Acquire
+// and Store-Release) extension
+//
+//===--===//
+
+//===--===//
+// Instruction class templates
+//===--===//
+
+let hasSideEffects = 0, mayLoad = 1, mayStore = 0 in
+class LAQ_r funct3, string opcodestr>
+: RVInstRAtomic<0b00110, aq, rl, funct3, OPC_AMO,
+(outs GPR:$rd), (ins GPRMemZeroOffset:$rs1),
+opcodestr, "$rd, $rs1"> {
+  let rs2 = 0;
+}
+
+let hasSideEffects = 0, mayLoad = 0, mayStore = 1 in
+class SRL_r funct3, string opcodestr>
+: RVInstRAtomic<0b00111, aq, rl, funct3, OPC_AMO,
+(outs ), (ins GPRMemZeroOffset:$rs1, GPR:$rs2),
+opcodestr, "$rs2, $rs1"> {
+  let rd = 0;
+}
+multiclass LAQ_r_aq_rl funct3, string opcodestr> {
+  def _AQ: LAQ_r<1, 0, funct3, opcodestr # ".aq">;
+  def _AQ_RL : LAQ_r<1, 1, funct3, opcodestr # ".aqrl">;
+}
+
+multiclass SRL_r_aq_rl funct3, string opcodestr> {
+  def _RL: SRL_r<0, 1, funct3, opcodestr # ".rl">;
+  def _AQ_RL : SRL_r<1, 1, funct3, opcodestr # ".aqrl">;
+}
+
+//===--===//
+// Instructions
+//===--===//
+
+
+let Predicates = [HasStdExtZalasr] in {
+defm LB_AQ : LAQ_r_aq_rl<0b000, "lb">;

mehnadnerd wrote:

Yes it does. I couldn't come up with a better alternative--since it would be 
possible to encode this with neither bit set, which should just be a LB without 
an immediate. That isn't useful, and so it wasn't included in the extension, 
but there is the ability to specify it encoding-wise.
Also, it can't be named LB for the same reason--it would conflict with plain 
LB. The alternative is LB. (with a period/underscore after), but that is even 
more confusing. I decided for both this and riscv-opcodes that this was the 
simplest way--but it would lead to issues if there was a load-release, it would 
be named LB_AQ_RL which would be confusing with LB_AQ_AQ_RL.

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

1 2 3 4 5 6 >

1 - 100 of 526 matches

Mail list logo