chrisnc wrote:
I've been fairly busy over the past few months so haven't had time to pursue
this further. One of the issues is that as far as I can tell, there doesn't
seem to be a mechanism to issue a warning from within LLVM codegen, only to
error. The behavior you are describing is already
chrisnc wrote:
> RISC-V has similar checks here:
>
> https://github.com/llvm/llvm-project/blob/ed572f2003275da8e06a634b4d6658b7921e8334/llvm/lib/Target/RISCV/RISCVISelLowering.cpp#L88-L100
>
> So maybe the ARM checks could be added in a similar place? RISC-V handles ABI
> variants in a very cl
https://github.com/chrisnc edited
https://github.com/llvm/llvm-project/pull/111334
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -311,11 +311,15 @@ ARMBaseTargetMachine::getSubtargetImpl(const Function &F)
const {
// function that reside in TargetOptions.
resetTargetOptions(F);
I = std::make_unique(TargetTriple, CPU, FS, *this, isLittle,
-F.hasMinSi
@@ -311,11 +311,15 @@ ARMBaseTargetMachine::getSubtargetImpl(const Function &F)
const {
// function that reside in TargetOptions.
resetTargetOptions(F);
I = std::make_unique(TargetTriple, CPU, FS, *this, isLittle,
-F.hasMinSi
@@ -16,7 +16,7 @@
// RUN: %clang --target=arm-none-eabi -mcpu=cortex-m33 -mfloat-abi=hard -O1 %s
-flto=thin -c -o %t.call_thin.bc -DCALL_LIB
// RUN: %clang --target=arm-none-eabi -mcpu=cortex-m33 -mfloat-abi=hard -O1 %s
-flto=thin -c -o %t.define_thin.bc -DDEFINE_LIB
-// RUN
@@ -16,7 +16,7 @@
// RUN: %clang --target=arm-none-eabi -mcpu=cortex-m33 -mfloat-abi=hard -O1 %s
-flto=thin -c -o %t.call_thin.bc -DCALL_LIB
// RUN: %clang --target=arm-none-eabi -mcpu=cortex-m33 -mfloat-abi=hard -O1 %s
-flto=thin -c -o %t.define_thin.bc -DDEFINE_LIB
-// RUN
@@ -16,7 +16,7 @@
// RUN: %clang --target=arm-none-eabi -mcpu=cortex-m33 -mfloat-abi=hard -O1 %s
-flto=thin -c -o %t.call_thin.bc -DCALL_LIB
// RUN: %clang --target=arm-none-eabi -mcpu=cortex-m33 -mfloat-abi=hard -O1 %s
-flto=thin -c -o %t.define_thin.bc -DDEFINE_LIB
-// RUN
https://github.com/chrisnc edited
https://github.com/llvm/llvm-project/pull/111334
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/chrisnc edited
https://github.com/llvm/llvm-project/pull/111334
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/chrisnc edited
https://github.com/llvm/llvm-project/pull/111334
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
chrisnc wrote:
> One use case I'd want to keep working is where we have two functions in the
> same object that are hardfp with hardware registers, and soft (with or
> without hardware registers). Something like:
>
> ```
> __attribute__((target("arch=cortex-m33"))) __attribute__((pcs("aapcs-vf
https://github.com/chrisnc edited
https://github.com/llvm/llvm-project/pull/111334
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -16,7 +16,7 @@
// RUN: %clang --target=arm-none-eabi -mcpu=cortex-m33 -mfloat-abi=hard -O1 %s
-flto=thin -c -o %t.call_thin.bc -DCALL_LIB
// RUN: %clang --target=arm-none-eabi -mcpu=cortex-m33 -mfloat-abi=hard -O1 %s
-flto=thin -c -o %t.define_thin.bc -DDEFINE_LIB
-// RUN
https://github.com/chrisnc edited
https://github.com/llvm/llvm-project/pull/111334
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/chrisnc edited
https://github.com/llvm/llvm-project/pull/111334
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
chrisnc wrote:
@ostannard or @davemgreen any other feedback on this change?
https://github.com/llvm/llvm-project/pull/111334
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -311,11 +311,15 @@ ARMBaseTargetMachine::getSubtargetImpl(const Function &F)
const {
// function that reside in TargetOptions.
resetTargetOptions(F);
I = std::make_unique(TargetTriple, CPU, FS, *this, isLittle,
-F.hasMinSi
chrisnc wrote:
> There's quite a lot of test changes that I presume needed to make
FWIW, virtually all of the test changes were due to cases where LLVM would
silently use soft-float despite the hard-float ABI being explicitly requested,
which is exactly the incorrect behavior that this PR is m
@@ -459,9 +459,6 @@ def warn_drv_assuming_mfloat_abi_is : Warning<
def warn_drv_unsupported_float_abi_by_lib : Warning<
"float ABI '%0' is not supported by current library">,
InGroup;
-def warn_drv_no_floating_point_registers: Warning<
chrisnc wrote:
`-Wun
chrisnc wrote:
LLVM not checking for this leads to it producing incorrect outputs given
certain inputs and arguments when using `llc` and the like directly. Even in an
ideal world where every frontend is target-aware and implements the rules
itself (or delegates to LLVM to check before attempt
chrisnc wrote:
Friendly bump :) @davemgreen @smithp35
https://github.com/llvm/llvm-project/pull/111334
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
chrisnc wrote:
All unit tests are now updated and passing and this change is ready for review.
Thanks!
https://github.com/llvm/llvm-project/pull/111334
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/list
https://github.com/chrisnc updated
https://github.com/llvm/llvm-project/pull/111334
>From 990320636c8d1aadd61597ab6cfa328beae11382 Mon Sep 17 00:00:00 2001
From: Chris Copeland
Date: Sun, 6 Oct 2024 20:27:48 -0700
Subject: [PATCH] [ARM] Emit an error when the hard-float ABI is enabled but
can'
https://github.com/chrisnc updated
https://github.com/llvm/llvm-project/pull/111334
>From 4bd5ec308b2d99c6a48457f3c9dbd96e70557e04 Mon Sep 17 00:00:00 2001
From: Chris Copeland
Date: Sun, 6 Oct 2024 20:27:48 -0700
Subject: [PATCH] [ARM] Emit an error when the hard-float ABI is enabled but
can'
chrisnc wrote:
I've updated this PR to remove the aforementioned `clang` warning for this
case, and I've updated all `clang` and `llvm` tests that were implicitly using
the soft-float ABI despite requesting hard-float. In some cases, explicitly
testing hard-float seemed to be intended because
https://github.com/chrisnc updated
https://github.com/llvm/llvm-project/pull/111334
>From 5e916c3c4d2579318fa990eca178f4cfd4ab35b0 Mon Sep 17 00:00:00 2001
From: Chris Copeland
Date: Sun, 6 Oct 2024 20:27:48 -0700
Subject: [PATCH] [ARM] Emit an error when the hard-float ABI is enabled but
can'
chrisnc wrote:
Among those options, my preference would be to remove the clang warning and add
the LLVM error so that other frontends can benefit from this checking, as well
as the LLVM tools themselves. The LLVM test failures reveal a few places where
this issue seems to be ignored.
https://
chrisnc wrote:
> It looks like there is already a warning for this in clang, it only triggers
> from -mfloat-abi=hard though: https://godbolt.org/z/dcaz8had4. Could it be
> made to work with any hard-float env? And maybe be made an error
> down-gradable to a warning?
>
> Generally clang-level
chrisnc wrote:
clang tests are passing now, but some llvm tests are not, e.g., invocations of
llc in `CodeGen/ARM/arm-eabi.ll` that specify e.g., `--target=arm-none-eabihf`
don't include enough features to actually use eabihf. Any suggestions on the
right place to address this would be appreci
https://github.com/chrisnc updated
https://github.com/llvm/llvm-project/pull/111334
>From b73e1b342dbbfae004ad0fa62184c106ab00c12a Mon Sep 17 00:00:00 2001
From: Chris Copeland
Date: Sun, 6 Oct 2024 20:27:48 -0700
Subject: [PATCH] [ARM] Emit an error when the hard-float ABI is enabled but
can'
chrisnc wrote:
@ahmedbougacha yes, I think it's correct that calling an
`__attribute__((interrupt))` function is safe to do on M-profile because there
is no difference in the return sequence; all it does is not assume that the
stack is 8-byte aligned initially. Even then, this is only needed w
chrisnc wrote:
@AaronBallman yes, that would be great! I'm just a contributor, not a
collaborator.
https://github.com/llvm/llvm-project/pull/97534
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/
chrisnc wrote:
Rebased and added a test case. I confirmed that the test fails using the
current definition of `ATOMIC_FLAG_INIT`:
```
error: 'expected-error' diagnostics seen but not expected:
Line 38: non-constant-expression cannot be narrowed from type 'int' to
'atomic_bool' (aka '_Atomic(
@@ -750,6 +750,8 @@ Bug Fixes in This Version
- Fixed `static_cast` to array of unknown bound. Fixes (#GH62863).
+- Fixed the definition of ATOMIC_FLAG_INIT in stdatomic.h so it can be used in
C++.
chrisnc wrote:
Done.
https://github.com/llvm/llvm-project/
https://github.com/chrisnc updated
https://github.com/llvm/llvm-project/pull/97534
>From 1b39c59e0ec3cbe1f2cabc650b983883439dde31 Mon Sep 17 00:00:00 2001
From: Chris Copeland
Date: Wed, 3 Jul 2024 00:11:39 -0700
Subject: [PATCH] [clang] Define `ATOMIC_FLAG_INIT` correctly for C++.
---
clang/
chrisnc wrote:
ping
https://github.com/llvm/llvm-project/pull/97534
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
chrisnc wrote:
Thanks!
https://github.com/llvm/llvm-project/pull/91870
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1329,6 +1329,11 @@ void SemaARM::handleInterruptAttr(Decl *D, const
ParsedAttr &AL) {
return;
}
+ const TargetInfo &TI = getASTContext().getTargetInfo();
+ if (TI.hasFeature("vfp")) {
+Diag(D->getLocation(), diag::warn_arm_interrupt_vfp_clobber);
+ }
chrisnc wrote:
Fixed another release notes conflict.
Ping @DavidSpickett @ostannard @jthackray.
https://github.com/llvm/llvm-project/pull/91870
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe
https://github.com/chrisnc updated
https://github.com/llvm/llvm-project/pull/91870
>From 947526935e78dfcb40ffde6aeb273c6120884339 Mon Sep 17 00:00:00 2001
From: Chris Copeland
Date: Sat, 11 May 2024 00:15:50 -0700
Subject: [PATCH 1/2] [clang][ARM] Fix warning for using VFP from interrupts.
Thi
chrisnc wrote:
ping
https://github.com/llvm/llvm-project/pull/97534
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/chrisnc updated
https://github.com/llvm/llvm-project/pull/97534
>From b7857c25e56ea59956d8ae0aac068358bcf67a03 Mon Sep 17 00:00:00 2001
From: Chris Copeland
Date: Wed, 3 Jul 2024 00:11:39 -0700
Subject: [PATCH] [clang] Define ATOMIC_FLAG_INIT correctly for C++.
---
clang/do
chrisnc wrote:
Without this change, trying to use `ATOMIC_FLAG_INIT` in a constant
initialization context yields the following:
https://godbolt.org/z/sTvMs5a95
```
:3:17: error: non-constant-expression cannot be narrowed from type
'int' to 'atomic_bool' (aka '_Atomic(bool)') in initializer li
chrisnc wrote:
Fixed more release notes conflicts.
https://github.com/llvm/llvm-project/pull/91870
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/chrisnc updated
https://github.com/llvm/llvm-project/pull/91870
>From d4908fb17a57ddc75032e838241ff4f0e929cd36 Mon Sep 17 00:00:00 2001
From: Chris Copeland
Date: Sat, 11 May 2024 00:15:50 -0700
Subject: [PATCH 1/2] [clang][ARM] Fix warning for using VFP from interrupts.
Thi
chrisnc wrote:
Clarified the release notes changes and added a test case for the new error.
https://github.com/llvm/llvm-project/pull/91870
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-comm
@@ -336,9 +336,12 @@ def warn_anyx86_excessive_regsave : Warning<
" with attribute 'no_caller_saved_registers'"
" or be compiled with '-mgeneral-regs-only'">,
InGroup>;
-def warn_arm_interrupt_calling_convention : Warning<
- "call to function without interrupt attribute
@@ -448,6 +448,11 @@ Modified Compiler Flags
evaluating to ``true`` and an empty body such as ``while(1);``)
are considered infinite, even when the ``-ffinite-loop`` flag is set.
+- Removed "arm interrupt calling convention" warning that was included in
+ ``-Wextra`` with
https://github.com/chrisnc updated
https://github.com/llvm/llvm-project/pull/91870
>From 88654f834fcf5bccca86f08d1b107c7ec9be41b4 Mon Sep 17 00:00:00 2001
From: Chris Copeland
Date: Sat, 11 May 2024 00:15:50 -0700
Subject: [PATCH 1/2] [clang][ARM] Fix warning for using VFP from interrupts.
Thi
chrisnc wrote:
Rebased to fix release not conflict. @DavidSpickett @llvm/pr-subscribers-arm
https://github.com/llvm/llvm-project/pull/91870
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-comm
https://github.com/chrisnc edited
https://github.com/llvm/llvm-project/pull/91870
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/chrisnc updated
https://github.com/llvm/llvm-project/pull/91870
>From ef65cf4803496f3c0627b488e150fd827657d63d Mon Sep 17 00:00:00 2001
From: Chris Copeland
Date: Sat, 11 May 2024 00:15:50 -0700
Subject: [PATCH 1/2] [clang][ARM] Fix warning for using VFP from interrupts.
Thi
chrisnc wrote:
Updated to just warn if the attribute is used while vfp is enabled, and added
an error for calling an interrupt handler, similar to x86.
https://github.com/llvm/llvm-project/pull/91870
___
cfe-commits mailing list
cfe-commits@lists.llvm
https://github.com/chrisnc edited
https://github.com/llvm/llvm-project/pull/91870
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/chrisnc edited
https://github.com/llvm/llvm-project/pull/91870
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/chrisnc updated
https://github.com/llvm/llvm-project/pull/91870
>From b892c59a27089b4753b7677a1ada1ee8da59301b Mon Sep 17 00:00:00 2001
From: Chris Copeland
Date: Sat, 11 May 2024 00:15:50 -0700
Subject: [PATCH 1/2] [clang][ARM] Fix warning for using VFP from interrupts.
Thi
chrisnc wrote:
While doing some more research and comparing `gcc` and `clang`, I noticed that
`clang` doesn't even save the volatile fp registers in an interrupt handler
when it uses them directly, so there's no point in just checking for function
calls. `gcc` does except for `fpscr`, which it
https://github.com/chrisnc updated
https://github.com/llvm/llvm-project/pull/91870
>From ef212138f895fb95df54798109375402c270c5da Mon Sep 17 00:00:00 2001
From: Chris Copeland
Date: Sat, 11 May 2024 00:15:50 -0700
Subject: [PATCH] [clang][ARM] Fix warning for VFP function calls from
interrupts
https://github.com/chrisnc updated
https://github.com/llvm/llvm-project/pull/91870
>From 16a00f4cf511e6dd96202d3013b41873f8dcba6b Mon Sep 17 00:00:00 2001
From: Chris Copeland
Date: Sat, 11 May 2024 00:15:50 -0700
Subject: [PATCH] [ARM][clang] Fix warning for VFP function calls from
interrupts
chrisnc wrote:
I've rebased, updated the warning text and release notes, and created
https://github.com/llvm/llvm-project/issues/95359 for the future improvement to
warn about calling interrupt handlers.
https://github.com/llvm/llvm-project/pull/91870
__
https://github.com/chrisnc updated
https://github.com/llvm/llvm-project/pull/91870
>From a67b6703d384eb63b947e75c13d6421a5f961f6c Mon Sep 17 00:00:00 2001
From: Chris Copeland
Date: Sat, 11 May 2024 00:15:50 -0700
Subject: [PATCH] [ARM][clang] Fix warning for VFP function calls from
interrupts
chrisnc wrote:
Thank you for the review!
> * Calling a function marked interrupt from a function marked interrupt is
> still UB isn't it? Should there be another warning to cover that scenario as
> well?
Correct. I can create a separate issue to describe such a warning.
> * I see that gcc ha
@@ -384,6 +384,10 @@ Modified Compiler Flags
evaluating to ``true`` and an empty body such as ``while(1);``)
are considered infinite, even when the ``-ffinite-loop`` flag is set.
+- Removed "arm interrupt calling convention" warning that was included in
ch
@@ -336,9 +336,10 @@ def warn_anyx86_excessive_regsave : Warning<
" with attribute 'no_caller_saved_registers'"
" or be compiled with '-mgeneral-regs-only'">,
InGroup>;
-def warn_arm_interrupt_calling_convention : Warning<
- "call to function without interrupt attribute
chrisnc wrote:
Ping @DavidSpickett @jthackray
https://github.com/llvm/llvm-project/pull/91870
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
chrisnc wrote:
Ping
https://github.com/llvm/llvm-project/pull/91870
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
chrisnc wrote:
ping (rebased and fixed another release notes conflict)
https://github.com/llvm/llvm-project/pull/91870
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/chrisnc updated
https://github.com/llvm/llvm-project/pull/91870
>From 846d22ff9d96c64c9b73f0270f49724b7ee1cb70 Mon Sep 17 00:00:00 2001
From: Chris Copeland
Date: Sat, 11 May 2024 00:15:50 -0700
Subject: [PATCH] [ARM][clang] Fix warning for VFP function calls from
interrupts
chrisnc wrote:
Rebased and fixed conflict in release notes.
https://github.com/llvm/llvm-project/pull/91870
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/chrisnc updated
https://github.com/llvm/llvm-project/pull/91870
>From b9aae83e94aab9ebed9b3dc3fe23bee4bd3c0756 Mon Sep 17 00:00:00 2001
From: Chris Copeland
Date: Sat, 11 May 2024 00:15:50 -0700
Subject: [PATCH] [ARM][clang] Fix warning for VFP function calls from
interrupts
chrisnc wrote:
ping @ostannard @smithp35
https://github.com/llvm/llvm-project/pull/91870
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
chrisnc wrote:
I'd like to also address #47815, but I wasn't able to find the right path to
answer "is this M-profile" from `TargetInfo`. Would appreciate any suggestions
on that. I think it may require `dynamic_cast`-ing the `TargetInfo` to an
`ARMTargetInfo`, and then change one of the metho
https://github.com/chrisnc edited
https://github.com/llvm/llvm-project/pull/91870
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/chrisnc updated
https://github.com/llvm/llvm-project/pull/91870
>From b72b63c51b1859e1a7e792eda20549ef93c8d6c0 Mon Sep 17 00:00:00 2001
From: Chris Copeland
Date: Sat, 11 May 2024 00:15:50 -0700
Subject: [PATCH] [ARM][clang] Fix warning for VFP function calls from
interrupts
https://github.com/chrisnc updated
https://github.com/llvm/llvm-project/pull/91870
>From ef08eb6e2526c5d4f97dbcc42715ae5daf74de3d Mon Sep 17 00:00:00 2001
From: Chris Copeland
Date: Sat, 11 May 2024 00:15:50 -0700
Subject: [PATCH] [ARM][clang] Fix warning for VFP function calls from
interrupts
chrisnc wrote:
Here is an example of the existing warning in action.
https://godbolt.org/z/9e84EfeYP
It warns for calling a normal function, but the same function with an interrupt
attribute does not warn. The `subs pc, lr, 4` in `bar_irq` goes back to `bl
bar_irq`, creating an infinite loop,
https://github.com/chrisnc created
https://github.com/llvm/llvm-project/pull/91870
This warning has two issues:
- The interrupt attribute doesn't only change how volatile registers
are treated; it also causes the function to return using an exception
return instruction. This warning allow
chrisnc wrote:
If there's no other feedback, could someone hit the merge button for me?
https://github.com/llvm/llvm-project/pull/88287
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/chrisnc edited
https://github.com/llvm/llvm-project/pull/88287
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
chrisnc wrote:
@smithp35 thanks! Yes, I iterated on the specific direction here after the
feedback about not changing the behavior of `-mcpu=cortex-r52`, but the first
comment in the thread reflects the initial state, so I'll change that. I
believe the cortex-r82 is AArch64-only, and so is not
chrisnc wrote:
Understood. FWIW, `arm-none-eabi-gcc` does not enable any FPU features by
default with `-march=armv8-r` (and will error out if you combine that with
`-mfloat-abi=hard`), which is what the first pass of this PR went for, but I
think where we landed is a decent middle ground.
htt
chrisnc wrote:
Friendly bump. :) @ostannard @davemgreen
https://github.com/llvm/llvm-project/pull/88287
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
chrisnc wrote:
@davemgreen which change? Specifying `-mcpu=cortex-r52` will behave the same
way as before. The original manual for the R52 provided for a no-neon sp-only
variant, and they exist in the wild, and this lets "architecture-generic"
builds automatically support both.
One example wh
chrisnc wrote:
Updated to fix the conflict with the ARM.td refactor. Ready for review.
https://github.com/llvm/llvm-project/pull/88287
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/chrisnc updated
https://github.com/llvm/llvm-project/pull/88287
>From 0a3a3c29b599df0cc6e3066b3388151fdb313cc2 Mon Sep 17 00:00:00 2001
From: Chris Copeland
Date: Fri, 5 Apr 2024 22:40:46 -0700
Subject: [PATCH] [ARM] Armv8-R does not require fp64 or neon.
Specifying cortex-r
https://github.com/chrisnc updated
https://github.com/llvm/llvm-project/pull/88287
>From 46803a6da62b8348f3eb8759c74ec6abf8693c92 Mon Sep 17 00:00:00 2001
From: Chris Copeland
Date: Fri, 5 Apr 2024 22:40:46 -0700
Subject: [PATCH] [ARM] Armv8-R does not require fp64 or neon.
Specifying cortex-r
chrisnc wrote:
Added an item to the release notes and fixed another place where fp64+neon was
being added (the target parser); now I see the expected results when using just
armv8r-none-eabi (sans -mcpu=cortex-r52).
https://github.com/llvm/llvm-project/pull/88287
__
https://github.com/chrisnc updated
https://github.com/llvm/llvm-project/pull/88287
>From 575128cc6b494fed2065cae07754477426cb1c24 Mon Sep 17 00:00:00 2001
From: Chris Copeland
Date: Fri, 5 Apr 2024 22:40:46 -0700
Subject: [PATCH] [ARM] Armv8-R does not require fp64 or neon.
Specifying cortex-r
chrisnc wrote:
Another option is to include `FeatureFPARMv8_D16_SP` in `ARMv8r`. The R-profile
supplement of the Arm manual does say that this is a minimum feature
requirement (as opposed to just being a variant of the R52).
https://github.com/llvm/llvm-project/pull/88287
_
https://github.com/chrisnc updated
https://github.com/llvm/llvm-project/pull/88287
>From a4a27e9db447fde7f38952618b877fc1ff741279 Mon Sep 17 00:00:00 2001
From: Chris Copeland
Date: Fri, 5 Apr 2024 22:40:46 -0700
Subject: [PATCH] [ARM] Armv8-R does not require fp64 or neon.
---
clang/test/Dri
https://github.com/chrisnc updated
https://github.com/llvm/llvm-project/pull/88287
>From 65e44d63a0939a4b91d084a2405f8a091329e311 Mon Sep 17 00:00:00 2001
From: Chris Copeland
Date: Fri, 5 Apr 2024 22:40:46 -0700
Subject: [PATCH] [ARM] Armv8-R does not require fp64 or neon.
---
clang/test/Pre
chrisnc wrote:
I've updated the PR to use the proposed approach of making `"generic"` the
default CPU for armv8r. Let me know if this is alright. I still need to fix up
a few of the tests to match this new behavior.
https://github.com/llvm/llvm-project/pull/88287
__
https://github.com/chrisnc updated
https://github.com/llvm/llvm-project/pull/88287
>From 4681c3016a0d035b4b23fa9349125901f6e8e4d8 Mon Sep 17 00:00:00 2001
From: Chris Copeland
Date: Fri, 5 Apr 2024 22:40:46 -0700
Subject: [PATCH] [ARM] Armv8-R does not require fp64 or neon.
---
clang/test/Pre
https://github.com/chrisnc updated
https://github.com/llvm/llvm-project/pull/88287
>From a021b579f609144c9139d3a8bd0fe87e9d028259 Mon Sep 17 00:00:00 2001
From: Chris Copeland
Date: Fri, 5 Apr 2024 22:40:46 -0700
Subject: [PATCH] [ARM] Armv8-R does not require fp64 or neon.
---
clang/test/Pre
https://github.com/chrisnc updated
https://github.com/llvm/llvm-project/pull/88287
>From ccc30221d11fe137da19c964c75b993368829647 Mon Sep 17 00:00:00 2001
From: Chris Copeland
Date: Fri, 5 Apr 2024 22:40:46 -0700
Subject: [PATCH] [ARM] Armv8-R does not require fp64 or neon.
---
clang/test/Pre
chrisnc wrote:
@davemgreen yes, this does change the cortex-r52 default features as well. The
problem is that the cortex-r52 is the "default" CPU for armv8r (probably
because it's the only one), so if I don't reduce the feature set of that CPU,
armv8r will continue to imply features that are n
chrisnc wrote:
ping @ostannard
https://github.com/llvm/llvm-project/pull/88287
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/chrisnc updated
https://github.com/llvm/llvm-project/pull/88287
>From 9317b1750b5208528ff716cee79e8666bebdba05 Mon Sep 17 00:00:00 2001
From: Chris Copeland
Date: Fri, 5 Apr 2024 22:40:46 -0700
Subject: [PATCH] [ARM] Armv8-R does not require fp64 or neon.
---
clang/test/Pre
https://github.com/chrisnc updated
https://github.com/llvm/llvm-project/pull/88287
>From f707f292a6153f9d23734e490720db3abb5c00ac Mon Sep 17 00:00:00 2001
From: Chris Copeland
Date: Fri, 5 Apr 2024 22:40:46 -0700
Subject: [PATCH] [ARM] Armv8-R does not require fp64 or neon.
---
clang/test/Pre
1 - 100 of 111 matches
Mail list logo
