[clang] [clang:frontend] Move helper functions to common location for SemaSPIRV (PR #125045)

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

[clang] [clang:frontend] Move helper functions to common location for SemaSPIRV (PR #125045)

https://github.com/DavidSpickett commented: Just a drive by style comment. https://github.com/llvm/llvm-project/pull/125045 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang:frontend] Move helper functions to common location for SemaSPIRV (PR #125045)

@@ -0,0 +1,65 @@ +#include "clang/Sema/Common.h" + +namespace clang { DavidSpickett wrote: https://llvm.org/docs/CodingStandards.html#use-namespace-qualifiers-to-implement-previously-declared-functions For example clang::CheckArgTypeIsCorrect instead of opening

[clang] [clang] document that by default FP turned off for ARM baremetal (PR #122881)

https://github.com/DavidSpickett approved this pull request. LGTM https://github.com/llvm/llvm-project/pull/122881 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] document that by default FP turned off for ARM baremetal (PR #122881)

@@ -1071,6 +1071,10 @@ Arm and AArch64 Support - Implementation of SVE2.1 and SME2.1 in accordance with the Arm C Language Extensions (ACLE) is now available. +- For ARM baremetal targets, the frame pointer (FP) is now turned off by + default. To turn on frame pointers for

[clang] [clang] document that by default FP turned off for ARM baremetal (PR #122881)

@@ -1076,6 +1076,8 @@ Arm and AArch64 Support in leaf functions after enabling ``-fno-omit-frame-pointer``, you can do so by adding the ``-momit-leaf-frame-pointer`` option. +- For ARM baremetal targets, the frame pointer (FP) is now turned off by default. --

[clang] [clang] document that by default FP turned off for ARM baremetal (PR #122881)

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

[clang] [Driver][ARM] Fix hardcoding of NEON FPU for armv8 (PR #122969)

DavidSpickett wrote: Yeah, my first impression from the commit message was that you removed the check entirely. https://github.com/llvm/llvm-project/pull/122969 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mai

[clang] [clang] [ARM] Explicitly enable NEON for Windows/Darwin targets (PR #122095)

@@ -659,13 +659,21 @@ llvm::ARM::FPUKind arm::getARMTargetFeatures(const Driver &D, CPUArgFPUKind != llvm::ARM::FK_INVALID ? CPUArgFPUKind : ArchArgFPUKind; (void)llvm::ARM::getFPUFeatures(FPUKind, Features); } else { +bool Generic = true; if (!ForAS) {

[clang] [clang] [ARM] Explicitly enable NEON for Windows/Darwin targets (PR #122095)

https://github.com/DavidSpickett approved this pull request. My understanding is that: * This PR does not conflict with what the Debian patch does. * It in fact will fix a bug in the Debian build. * This does not change the behaviour of an unmodified Clang from a user's perspective, therefore we

[clang] [clang] [ARM] Explicitly enable NEON for Windows/Darwin targets (PR #122095)

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

[clang] [Driver][ARM] Change Android's NEON FPU hardcoding to "== 7" as it pessimizes future ArmV8 code (PR #122969)

DavidSpickett wrote: Make sure to update the *PR Description* as this becomes the commit message when the squash and merge happens. (yes, this is confusing but that's how llvm is set up) But what I read makes sense thank you for rephrasing the commit message. https://github.com/llvm/llvm-proj

[libunwind] [libunwind][X86-64] Handle Linux sigreturn trampoline when DWARF info is missing (PR #103473)

DavidSpickett wrote: Can someone from @llvm/reviewers-libcxx help with the FreeBSD failure? Seems unrelated. https://github.com/llvm/llvm-project/pull/103473 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailma

[clang] [clang][test] Don't require specific alignment in test case (PR #130589)

https://github.com/DavidSpickett created https://github.com/llvm/llvm-project/pull/130589 https://github.com/llvm/llvm-project/pull/129952 / 42d49a77241df73a17cb442973702fc460e7fb90 added this test which is failing on 32-bit ARM because the alignment chosen is 4 not 8. Which would make sense i

[clang] [clang] Reject constexpr-unknown values as constant expressions more consistently (PR #129952)

DavidSpickett wrote: The failure above is real, ABI or 32-bitness issue I think. Looking at it now. https://github.com/llvm/llvm-project/pull/129952 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo

[clang] [clang][test] Don't require specific alignment in test case (PR #130589)

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

[clang] [clang] Reject constexpr-unknown values as constant expressions more consistently (PR #129952)

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

[clang] [llvm] [ARM][Clang] Make `+nosimd` functional for AArch32 Targets (PR #130623)

DavidSpickett wrote: > used to emable or disable enable https://github.com/llvm/llvm-project/pull/130623 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang] [ARM] Ensure FPU Features are collected when using the Clang Assembler (PR #134366)

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

[clang] [Clang][ARM] Ensure FPU Features are parsed when targeting `cc1as` (PR #134612)

@@ -463,6 +466,7 @@ X86 Support Arm and AArch64 Support ^^^ +- For ARM targets, cc1as now considers the FPU's features for the selected CPU or Arch. DavidSpickett wrote: Arch -> architecture https://github.com/llvm/llvm-project/pull/1346

[clang] [Clang][ARM] Ensure FPU Features are parsed when targeting `cc1as` (PR #134612)

https://github.com/DavidSpickett approved this pull request. LGTM https://github.com/llvm/llvm-project/pull/134612 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][test] Don't require specific alignment in test case (PR #130589)

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

[clang] [Clang][ARM] Ensure FPU Features are parsed when targeting `cc1as` (PR #134612)

@@ -679,20 +679,17 @@ llvm::ARM::FPUKind arm::getARMTargetFeatures(const Driver &D, CPUArgFPUKind != llvm::ARM::FK_INVALID ? CPUArgFPUKind : ArchArgFPUKind; (void)llvm::ARM::getFPUFeatures(FPUKind, Features); } else { -bool Generic = true; -if (!ForAS) {

[clang] [Clang][ARM] Ensure FPU Features are parsed when targeting `cc1as` (PR #134612)

@@ -0,0 +1,32 @@ +// REQUIRES: arm-registered-target +// Ensures that when targeting an ARM target with an Asm file, clang DavidSpickett wrote: I have often been asked to use `///` for comments that were actually comments. I think it is marginally easier to read

[clang] [Clang][ARM] Ensure FPU Features are parsed when targeting `cc1as` (PR #134612)

@@ -0,0 +1,32 @@ +// REQUIRES: arm-registered-target +// Ensures that when targeting an ARM target with an Asm file, clang +// collects the features from the FPU. This is critical in the +// activation of NEON for supported targets. The Cortex-R52 will be +// used and tested for V

[clang] [Clang][ARM] Ensure FPU Features are parsed when targeting `cc1as` (PR #134612)

@@ -0,0 +1,32 @@ +// REQUIRES: arm-registered-target +// Ensures that when targeting an ARM target with an Asm file, clang +// collects the features from the FPU. This is critical in the +// activation of NEON for supported targets. The Cortex-R52 will be +// used and tested for V

[clang] [Clang] [ARM] Ensure FPU Features are collected when using the Clang Assembler (PR #134366)

https://github.com/DavidSpickett commented: I see that this would be breaking for code unintentionally relying on the features being omitted, but it makes sense to fix it nevertheless. I would have expected us to add the features all along. What does gcc/binutils do in this scenario? I don't t

[clang] [Clang] [ARM] Ensure FPU Features are collected when using the Clang Assembler (PR #134366)

@@ -38,6 +38,9 @@ Potentially Breaking Changes - Fix missing diagnostics for uses of declarations when performing typename access, such as when performing member access on a '[[deprecated]]' type alias. (#GH58547) +- For ARM targets, when using cc1as, the features included

[clang] [clang] [ARM] Explicitly enable NEON for Windows/Darwin targets (PR #122095)

@@ -659,13 +659,21 @@ llvm::ARM::FPUKind arm::getARMTargetFeatures(const Driver &D, CPUArgFPUKind != llvm::ARM::FK_INVALID ? CPUArgFPUKind : ArchArgFPUKind; (void)llvm::ARM::getFPUFeatures(FPUKind, Features); } else { +bool Generic = true; if (!ForAS) {

[clang] [clang] [ARM] Explicitly enable NEON for Windows/Darwin targets (PR #122095)

@@ -659,13 +659,21 @@ llvm::ARM::FPUKind arm::getARMTargetFeatures(const Driver &D, CPUArgFPUKind != llvm::ARM::FK_INVALID ? CPUArgFPUKind : ArchArgFPUKind; (void)llvm::ARM::getFPUFeatures(FPUKind, Features); } else { +bool Generic = true; if (!ForAS) {

[clang] [llvm] Reland: [llvm][clang] Allocate a new stack instead of spawning a new thread to get more stack space (PR #136046)

DavidSpickett wrote: I've [disabled](https://github.com/llvm/llvm-project/commit/f7fdc8d0cf7cd5caa7d463e1e80e0d5a08c71bb2) the test when threads are disabled. I don't think it needs to be limited to Apple Silicon actually, because a new OS thread should pass the test (and apparently does). Bu

[clang] [llvm] Reland: [llvm][clang] Allocate a new stack instead of spawning a new thread to get more stack space (PR #136046)

DavidSpickett wrote: That build sets `-DLLVM_ENABLE_THREADS=OFF`. `LLVM_HAS_SPLIT_STACKS_AARCH64` and `LLVM_HAS_SPLIT_STACKS` are false, which means we use: ``` void llvm::runOnNewStack(unsigned StackSize, function_ref Fn) { llvm::thread Thread( StackSize == 0 ? std::nullopt : std::optio

[clang] [llvm] Reland: [llvm][clang] Allocate a new stack instead of spawning a new thread to get more stack space (PR #136046)

DavidSpickett wrote: Same sort of thing on our Armv8 32-bit build: https://lab.llvm.org/buildbot/#/builders/122/builds/1478 ``` ../llvm/llvm/unittests/Support/ProgramStackTest.cpp:32 Expected: (StackDistance) > (llvm::sys::Process::getPageSizeEstimate()), actual: 8 vs 4096 ``` https://github.

<    2   3   4   5   6   7