[clang] [AArch64] Add getHostCPUFeatures to query for enabled features in cpu… (PR #97749)

2024-07-04 Thread Madhur Amilkanthwar via cfe-commits 


@@ -445,4 +445,21 @@ void aarch64::getAArch64TargetFeatures(const Driver &D,
 
   if (Args.getLastArg(options::OPT_mno_bti_at_return_twice))
 Features.push_back("+no-bti-at-return-twice");
+
+  // Parse AArch64 CPU Features
+  const Arg *CPUArg = Args.getLastArg(options::OPT_mcpu_EQ);
+  StringRef CPUName;
+
+  if (CPUArg) {
+CPUName = CPUArg->getValue();
+if (CPUName == "native") {
+  llvm::StringMap HostFeatures;
+  if (llvm::sys::getHostCPUFeatures(HostFeatures)) {
+for (auto &F : HostFeatures) {
+  Features.push_back(
+Args.MakeArgString((F.second ? "+" : "-") + F.first()));
+}
+  }
+}

madhur13490 wrote:

You can use early return here.

```
if (!CPUArg) 
return;

if (CPUName != "native")
return

if (!llvm::sys::getHostCPUFeatures(HostFeatures)) 
return

```
and then iterate over `HostFeatures`. I think it will be cleaner.

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

[clang] [AArch64] Add getHostCPUFeatures to query for enabled features in cpu… (PR #97749)

2024-07-04 Thread Madhur Amilkanthwar via cfe-commits 

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

[clang] [AArch64] Add getHostCPUFeatures to query for enabled features in cpu… (PR #97749)

2024-07-04 Thread Madhur Amilkanthwar via cfe-commits 

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

[clang] [clang] check deduction consistency when partial ordering function templates (PR #100692)

2024-09-04 Thread Madhur Amilkanthwar via cfe-commits 

madhur13490 wrote:

@mizvekov Is it possible to revert this until you work on the solution? SPEC is 
failing since this patch is landed. 

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

[clang] [AMDGPU] Correctly determine the toolchain linker (PR #89803)

2024-04-23 Thread Madhur Amilkanthwar via cfe-commits 


@@ -24,3 +24,9 @@
 // RUN:   -L. -fconvergent-functions %s 2>&1 | FileCheck -check-prefix=MCPU %s
 // LTO: clang{{.*}} "-flto=full"{{.*}}"-fconvergent-functions"
 // MCPU: ld.lld{{.*}}"-L."{{.*}}"-plugin-opt=mcpu=gfx906"
+
+// We do not suppor the BFD linker, but we should be able to override the

madhur13490 wrote:

s/suppor/support

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

[clang] [AMDGPU] Correctly determine the toolchain linker (PR #89803)

2024-04-23 Thread Madhur Amilkanthwar via cfe-commits 

madhur13490 wrote:

Thanks for fixing this after our discord chats!

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

[clang] [llvm] [CMake] Preserve clang-prebolt (PR #109351)

2024-09-23 Thread Madhur Amilkanthwar via cfe-commits 

madhur13490 wrote:

This commit is breaking LTO-PGO-BOLT build while optimizing clang with BOLT. 

```
[3064/3065] Merging BOLT fdata
Using legacy profile format.
Profile from 2 files merged.
[3064/3065] Optimizing Clang with BOLT
BOLT-INFO: shared object or position-independent executable detected
BOLT-INFO: Target architecture: aarch64
BOLT-INFO: BOLT version: 51d1d03b17bb8bf66b6422c4482d8d615ab53409
BOLT-INFO: first alloc address is 0x0
BOLT-INFO: enabling relocation mode
BOLT-INFO: pre-processing profile using branch profile reader
BOLT-WARNING: 1 collisions detected while hashing binary objects. Use -v=1 to 
see the list.
BOLT-INFO: number of removed linker-inserted veneers: 0
BOLT-INFO: 11906 out of 212101 functions in the binary (5.6%) have non-empty 
execution profile
BOLT-INFO: 272 functions with profile could not be optimized
BOLT-INFO: profile for 1 objects was ignored
BOLT-INFO: removed 1 empty block
BOLT-INFO: basic block reordering modified layout of 4273 functions (35.89% of 
profiled, 2.01% of total)
BOLT-INFO: UCE removed 1 blocks and 4 bytes of code
BOLT-INFO: 68 Functions were reordered by LoopInversionPass
:0: error: fixup value out of range
:0: error: fixup value out of range
:0: error: fixup value out of range
:0: error: fixup value out of range
:0: error: fixup value out of range
:0: error: fixup value out of range
:0: error: fixup value out of range
:0: error: fixup value out of range
```

More information on LTO-PGO-BOLT can be found on 
[](https://llvm.org/docs/AdvancedBuilds.html)



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

[clang] [llvm] [CMake] Preserve clang-prebolt (PR #109351)

2024-09-23 Thread Madhur Amilkanthwar via cfe-commits 

madhur13490 wrote:

Here are CMAKE variables we use downstream. 
```
-DLLVM_ENABLE_PROJECTS=bolt;clang;openmp;lld




-DLLVM_ENABLE_RUNTIMES=compiler-rt  




-DLLVM_TARGETS_TO_BUILD=AArch64 




-DCLANG_DEFAULT_LINKER=lld  




-DCMAKE_BUILD_TYPE=Release  









-C ../clang/cmake/caches/BOLT-PGO.cmake 



  
-DBOOTSTRAP_LLVM_ENABLE_LLD=ON  




-DBOOTSTRAP_BOOTSTRAP_LLVM_ENABLE_LLD=ON




-DBOOTSTRAP_CLANG_DEFAULT_LINKER=lld




-DBOOTSTRAP_BOOTSTRAP_CLANG_DEFAULT_LINKER=lld  




-DPGO_INSTRUMENT_LTO=Thin   




-DCLANG_BOOTSTRAP_PASSTHROUGH=CMAKE_INSTALL_PREFIX;LLVM_TARGETS_TO_BUILD;CMAKE_BUILD_TYPE;
  
 
```

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

[clang] [llvm] [Clang][Driver] Add an option to control loop-interchange (PR #125830)

2025-02-06 Thread Madhur Amilkanthwar via cfe-commits 

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

[clang] [llvm] [Clang][Driver] Add an option to control loop-interchange (PR #125830)

2025-02-06 Thread Madhur Amilkanthwar via cfe-commits 

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

LGTM

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

[clang] [CMake] Fix variable name (PR #127967)

2025-02-20 Thread Madhur Amilkanthwar via cfe-commits 

madhur13490 wrote:

> > The fix is NOT correct. You need to enclose in quotes as @tstellar mentions 
> > in #126876
> 
> ` llvm_canonicalize_cmake_booleans` converts the string to an integer so you 
> don't need the quotes now that this function is called with the correct 
> variable. This is what the generated file looks like now:
> 
> ```
> config.use_llvm_build = 1
> ```

Oh.. I see. Thanks!

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

[clang] [CMake] Fix variable name (PR #127967)

2025-02-20 Thread Madhur Amilkanthwar via cfe-commits 

madhur13490 wrote:

Please merge this soon. This has broken our CI miserably and has blocked all 
our testing. Thanks!

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

[clang] [llvm] [AArch64][SVE] Improve fixed-length addressing modes. (PR #129732)

2025-03-04 Thread Madhur Amilkanthwar via cfe-commits 


@@ -7380,12 +7380,27 @@ bool 
AArch64DAGToDAGISel::SelectAddrModeIndexedSVE(SDNode *Root, SDValue N,
 return false;
 
   SDValue VScale = N.getOperand(1);
-  if (VScale.getOpcode() != ISD::VSCALE)
+  int64_t MulImm = std::numeric_limits::max();
+  if (VScale.getOpcode() == ISD::VSCALE)

madhur13490 wrote:

This should be enclosed in `{}` to keep it unified with the `else` block per 
coding standards 
[guidelines](https://llvm.org/docs/CodingStandards.html#don-t-use-braces-on-simple-single-statement-bodies-of-if-else-loop-statements).

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

[clang] [AArch64] Remove strict checks from init-aarch64.c (PR #134338)

2025-04-04 Thread Madhur Amilkanthwar via cfe-commits 

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

[clang] [AArch64] Remove strict checks from init-aarch64.c (PR #134338)

2025-04-04 Thread Madhur Amilkanthwar via cfe-commits 

madhur13490 wrote:

Thanks all. Abandoning this change, will find an appropriate solution for 
downstream.

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

[clang] [AArch64] Remove strict checks from init-aarch64.c (PR #134338)

2025-04-03 Thread Madhur Amilkanthwar via cfe-commits 

https://github.com/madhur13490 created 
https://github.com/llvm/llvm-project/pull/134338

The checks in init-aarch64.c expect macros to be back-to-back which seems very 
strict. This change aims to relax this and use just AARCH64 instead of 
AARCH64-NEXT. This way, we maintain the order of the macros but also don't 
require them to be back-to-back.

This aligns with how
1. DARWIN and MSVC checks are done in the same file
2. init-* test for other backends do the checks.

>From 0fa563d169f929fe1e540d2d3227aa73cf68f763 Mon Sep 17 00:00:00 2001
From: Madhur Amilkanthwar 
Date: Wed, 2 Apr 2025 22:01:44 -0700
Subject: [PATCH] [AArch64] Remove strict checks from init-aarch64.c

The checks in init-aarch64.c expect macros to be back-to-back which seems
very strict. This change aims to relax this and use just AARCH64 instead of
AARCH64-NEXT. This way, we maintain the order of the macros but also don't
require them to be back-to-back.

This aligns with how
1. DARWIN and MSVC checks are done in the same file
2. How init-* test for other backends do the checks.
---
 clang/test/Preprocessor/init-aarch64.c | 776 -
 1 file changed, 388 insertions(+), 388 deletions(-)

diff --git a/clang/test/Preprocessor/init-aarch64.c 
b/clang/test/Preprocessor/init-aarch64.c
index 3036b496db25d..307e083455314 100644
--- a/clang/test/Preprocessor/init-aarch64.c
+++ b/clang/test/Preprocessor/init-aarch64.c
@@ -6,398 +6,398 @@
 // RUN: %clang_cc1 -E -dM -triple=arm64 -xc++ /dev/null | FileCheck 
--check-prefixes=AARCH64,AARCH64_LE,AARCH64_CXX --match-full-lines %s
 
 // AARCH64: #define _LP64 1
-// AARCH64_BE-NEXT: #define __AARCH64EB__ 1
-// AARCH64_BE-NEXT: #define __AARCH64_CMODEL_SMALL__ 1
-// AARCH64_BE-NEXT: #define __AARCH_BIG_ENDIAN 1
-// AARCH64_LE-NEXT: #define __AARCH64EL__ 1
-// AARCH64_LE-NEXT: #define __AARCH64_CMODEL_SMALL__ 1
-// AARCH64-NEXT: #define __ARM_64BIT_STATE 1
-// AARCH64-NEXT: #define __ARM_ACLE 202420
-// AARCH64-NEXT: #define __ARM_ACLE_VERSION(year,quarter,patch) (100 * (year) 
+ 10 * (quarter) + (patch))
-// AARCH64-NEXT: #define __ARM_ALIGN_MAX_STACK_PWR 4
-// AARCH64-NEXT: #define __ARM_ARCH 8
-// AARCH64-NEXT: #define __ARM_ARCH_ISA_A64 1
-// AARCH64-NEXT: #define __ARM_ARCH_PROFILE 'A'
-// AARCH64_BE-NEXT: #define __ARM_BIG_ENDIAN 1
-// AARCH64-NEXT: #define __ARM_FEATURE_CLZ 1
-// AARCH64-NEXT: #define __ARM_FEATURE_DIRECTED_ROUNDING 1
-// AARCH64-NEXT: #define __ARM_FEATURE_DIV 1
-// AARCH64-NEXT: #define __ARM_FEATURE_FMA 1
-// AARCH64-NEXT: #define __ARM_FEATURE_IDIV 1
-// AARCH64-NEXT: #define __ARM_FEATURE_LDREX 0xF
-// AARCH64-NEXT: #define __ARM_FEATURE_NUMERIC_MAXMIN 1
-// AARCH64-NEXT: #define __ARM_FEATURE_UNALIGNED 1
-// AARCH64-NEXT: #define __ARM_FP 0xE
-// AARCH64-NEXT: #define __ARM_FP16_ARGS 1
-// AARCH64-NEXT: #define __ARM_FP16_FORMAT_IEEE 1
-// AARCH64-NEXT: #define __ARM_NEON_SVE_BRIDGE 1
-// AARCH64-NEXT: #define __ARM_PCS_AAPCS64 1
-// AARCH64-NEXT: #define __ARM_SIZEOF_MINIMAL_ENUM 4
-// AARCH64-NEXT: #define __ARM_SIZEOF_WCHAR_T 4
-// AARCH64-NEXT: #define __ARM_STATE_ZA 1
-// AARCH64-NEXT: #define __ARM_STATE_ZT0 1
-// AARCH64-NEXT: #define __ATOMIC_ACQUIRE 2
-// AARCH64-NEXT: #define __ATOMIC_ACQ_REL 4
-// AARCH64-NEXT: #define __ATOMIC_CONSUME 1
-// AARCH64-NEXT: #define __ATOMIC_RELAXED 0
-// AARCH64-NEXT: #define __ATOMIC_RELEASE 3
-// AARCH64-NEXT: #define __ATOMIC_SEQ_CST 5
+// AARCH64_BE: #define __AARCH64EB__ 1
+// AARCH64_BE: #define __AARCH64_CMODEL_SMALL__ 1
+// AARCH64_BE: #define __AARCH_BIG_ENDIAN 1
+// AARCH64_LE: #define __AARCH64EL__ 1
+// AARCH64_LE: #define __AARCH64_CMODEL_SMALL__ 1
+// AARCH64: #define __ARM_64BIT_STATE 1
+// AARCH64: #define __ARM_ACLE 202420
+// AARCH64: #define __ARM_ACLE_VERSION(year,quarter,patch) (100 * (year) + 10 
* (quarter) + (patch))
+// AARCH64: #define __ARM_ALIGN_MAX_STACK_PWR 4
+// AARCH64: #define __ARM_ARCH 8
+// AARCH64: #define __ARM_ARCH_ISA_A64 1
+// AARCH64: #define __ARM_ARCH_PROFILE 'A'
+// AARCH64_BE: #define __ARM_BIG_ENDIAN 1
+// AARCH64: #define __ARM_FEATURE_CLZ 1
+// AARCH64: #define __ARM_FEATURE_DIRECTED_ROUNDING 1
+// AARCH64: #define __ARM_FEATURE_DIV 1
+// AARCH64: #define __ARM_FEATURE_FMA 1
+// AARCH64: #define __ARM_FEATURE_IDIV 1
+// AARCH64: #define __ARM_FEATURE_LDREX 0xF
+// AARCH64: #define __ARM_FEATURE_NUMERIC_MAXMIN 1
+// AARCH64: #define __ARM_FEATURE_UNALIGNED 1
+// AARCH64: #define __ARM_FP 0xE
+// AARCH64: #define __ARM_FP16_ARGS 1
+// AARCH64: #define __ARM_FP16_FORMAT_IEEE 1
+// AARCH64: #define __ARM_NEON_SVE_BRIDGE 1
+// AARCH64: #define __ARM_PCS_AAPCS64 1
+// AARCH64: #define __ARM_SIZEOF_MINIMAL_ENUM 4
+// AARCH64: #define __ARM_SIZEOF_WCHAR_T 4
+// AARCH64: #define __ARM_STATE_ZA 1
+// AARCH64: #define __ARM_STATE_ZT0 1
+// AARCH64: #define __ATOMIC_ACQUIRE 2
+// AARCH64: #define __ATOMIC_ACQ_REL 4
+// AARCH64: #define __ATOMIC_CONSUME 1
+// AARCH64: #define __ATOMIC_RELAXED 0
+// AARCH64: #define __ATOMIC_RELEASE 3
+// AARCH64: #define __ATOMIC_SEQ_CST 5
 //

[clang] [AArch64] Remove strict checks from init-aarch64.c (PR #134338)

2025-04-03 Thread Madhur Amilkanthwar via cfe-commits 

madhur13490 wrote:

> The other tests should be strengthened to always use -NEXT. The exact set of 
> macros should be tested; don't want others hiding in the gaps

Thanks, @arsenm. However, the strict checks are creating problems in our 
downstream compiler and rebasing. Our downstream compiler emits some macro(s) 
to identify itself. Thus, we are also required to change `init-arrch64.c` test 
to check our downstream macro and keep CI happy. As we do rebases daily, these 
changes cause merge conflicts frequently.
If I segregate our downstream checks to a new file, `init-aarch64.c` will fail 
because checks require all macros to be back-to-back.

(Unfortunately, we cannot upstream the changes because they are very 
downstream-specific and inappropriate for the upstream. I am proposing this 
change to make our life easy.)

The checks in init-aarch64.c expect macros to be back-to-back, which seems very 
strict. This change aims to relax this and use just `AARCH64` instead of 
`AARCH64-NEXT`. This way, we maintain the order of the macros but also don't 
require them to be back-to-back.

Once this change is committed,  I will separate out the downstream check to a 
new file.
Thus, we will not have merge conflicts, and `init-aarch64.c` will continue to 
pass.

Does this make sense?

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