-
-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
LLVM10 changes #4409
LLVM10 changes #4409
Conversation
no-frame-pointer-elim and no-frame-pointer-elim-non-leaf have been deprecated for a while in favour of the newer (and clearer) frame-pointer attribute. Starting with LLVM10 the old attributes are silently ignored, leading to no stack traces in debug mode.
So you want to remove "relax" from the "baseline" feature set, right? Here's how to do that: --- a/lib/std/target/riscv.zig
+++ b/lib/std/target/riscv.zig
@@ -270,7 +270,6 @@ pub const cpu = struct {
.d,
.f,
.m,
- .relax,
}),
};
@@ -284,7 +283,6 @@ pub const cpu = struct {
.d,
.f,
.m,
- .relax,
}),
};
I was the one who made up that "baseline CPU", so let's just take relax out of it. |
Oh I thought it was something from LLVM, I'll send a follow-up patch if you want |
Go for it, because it sounds like you have a follow-up task in mind (enabling some other tests?) |
I'll see if I can reproduce this. When I try to build zig against LLVM 10 RC1 it errors out. I'll try to deduce what the LLVM IR was, but if you can provide it it would help. |
OK, I don't know if it's the same issue but I managed to get an "Unexpected illegal type" assertion with some hand-coded LLVM IR. I'll look into it. |
target datalayout = "e-m:e-p:64:64-i64:64-i128:128-n64-S128"
target triple = "riscv64-unknown-linux-musl"
define void @_start() #1 {
Entry:
%x = alloca float, align 4
store float 0.000000e+00, float* %x, align 4
%0 = atomicrmw xchg float* %x, float 1.000000e+00 seq_cst
ret void
} Compiled using the following cmdline: |
That's the same error I got with the hand-coded .ll file, but it's not a "cannot select" error, as initially reported. I'll look into it, nevertheless. I've never seen floating-point atomics before, I imagine that might be the kind of thing that other frontends deal with by bitcasting to integers first, so this might be off the beaten path. |
That's the error I got with a non-debug LLVM version, this is the one I get with my other build with debug assertions enabled:
|
Ah, right, I was also using a debug build, and got that error. That explains the difference. Thanks, I'll look into this. |
I remember why I added "relax" to the baseline feature set. Here's the diff I just tried to do in the llvm10 branch: diff --git a/lib/std/target/riscv.zig b/lib/std/target/riscv.zig
index efb71a35e..d66cc5742 100644
--- a/lib/std/target/riscv.zig
+++ b/lib/std/target/riscv.zig
@@ -263,7 +263,7 @@ pub const all_features = blk: {
pub const cpu = struct {
pub const baseline_rv32 = Cpu{
.name = "baseline_rv32",
- .llvm_name = "generic-rv32",
+ .llvm_name = null,
.features = featureSet(&[_]Feature{
.a,
.c,
@@ -275,7 +275,7 @@ pub const cpu = struct {
pub const baseline_rv64 = Cpu{
.name = "baseline_rv64",
- .llvm_name = "generic-rv64",
+ .llvm_name = null,
.features = featureSet(&[_]Feature{
.@"64bit",
.a,
@@ -288,14 +288,14 @@ pub const cpu = struct {
pub const generic_rv32 = Cpu{
.name = "generic_rv32",
- .llvm_name = "generic-rv32",
+ .llvm_name = null,
.features = featureSet(&[_]Feature{
.rvc_hints,
}),
};
pub const generic_rv64 = Cpu{
.name = "generic_rv64",
- .llvm_name = "generic-rv64",
+ .llvm_name = null,
.features = featureSet(&[_]Feature{
.@"64bit",
.rvc_hints,
diff --git a/test/tests.zig b/test/tests.zig
index f079b4664..ad84e2c44 100644
--- a/test/tests.zig
+++ b/test/tests.zig
@@ -196,6 +196,41 @@ const test_targets = blk: {
.link_libc = true,
},
+ TestTarget{
+ .target = Target{
+ .Cross = CrossTarget{
+ .os = .linux,
+ .arch = .riscv64,
+ .cpu_features = Target.Arch.riscv64.getBaselineCpuFeatures(),
+ .abi = .none,
+ },
+ },
+ },
+
+ TestTarget{
+ .target = Target{
+ .Cross = CrossTarget{
+ .os = .linux,
+ .arch = .riscv64,
+ .cpu_features = Target.Arch.riscv64.getBaselineCpuFeatures(),
+ .abi = .musl,
+ },
+ },
+ .link_libc = true,
+ },
+
+ TestTarget{
+ .target = Target{
+ .Cross = CrossTarget{
+ .os = .linux,
+ .arch = .riscv64,
+ .cpu_features = Target.Arch.riscv64.getBaselineCpuFeatures(),
+ .abi = .gnu,
+ },
+ },
+ .link_libc = true,
+ },
+
TestTarget{
.target = Target{
.Cross = CrossTarget{ Running it with this command:
Gives this output:
So it looks like musl depends on linker relaxation features. This is a bummer, it means even with LLVM 10 we can't cross compile for
|
I get the impression you're saying you added "relax" to solve this issue but it might be the other way around. Isn't it the case that you compile musl with code relaxation enabled, thus generating Can't you compile musl without generating those align relocations? I don't remember 100% of the top of my head if disabling code relaxations is sufficient to ensure that, but that was my impression. If you don't have the align relocations you can then use LLD, for a pure LLVM toolchain. |
Nothing to see here, move along
baseline_rv64
CPU as-is since lld doesn't support some relocations/relaxations, the trick is to pass an additional-relax
to the default feature set. The feature set API is so damn awkward to use that I had to give up after wrestling with it for a while.And don't forget that #508 can probably be closed too (and its workaround reverted) 🎉