https://github.com/tgross35 commented:
LGTM, this matches what I've seen while inspecting the tablegen output
https://github.com/llvm/llvm-project/pull/148782
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.or
@@ -0,0 +1,31 @@
+; RUN: %if aarch64-registered-target %{ llc < %s
-mtriple=aarch64-unknown-linux-gnu| FileCheck %s
--check-prefixes=CHECK-ALL,CHECK-USELD %}
+; RUN: %if aarch64-registered-target %{ llc < %s
-mtriple=aarch64-unknown-linux-musl | FileCheck %s
--check-pref
tgross35 wrote:
> @tgross35 What do you think about merging this PR to the release branch?
I'd be happy to have it but it's certainly not my call. @RolandF77 was the
original reviewer.
https://github.com/llvm/llvm-project/pull/132049
___
llvm-branch-
tgross35 wrote:
> @heiher this would still break the ABI right? so it would still create
> problem for downstream users like rust?
Speaking only from a Rust perspective, don't worry too much about making
breaking changes that fix `f16` or `f128` behavior. The types are nightly-only
for now (p
tgross35 wrote:
> Currently, Rust's compiler-builtins has marked fp16 as available for
> loongarch64, but in fact, the functionality is broken. Even with this patch,
> it is not optimal. Subjectively, I hope these patches can be backported to
> LLVM 19 to avoid ABI incompatibility issues acros
tgross35 wrote:
(I'm not really involved with LLVM but I am doing a lot of f128 work and
requested the backport)
This seems unlikely to be a regression. There have a handful of f128-related
bugs on various ppc platforms so I suspect this is just something that hadn't
been tested before now.
