amdgcn-amd-amdhsa target broken? Fails to build core

[ZuseZ4]

I tried this code:

#![no_std]
fn foo() {}

with
RUSTFLAGS="-Ctarget-cpu=gfx1103 --emit=llvm-bc,llvm-ir" cargo +offload build -Zunstable-options -r -v --target amdgcn-amd-amdhsa -Zbuild-std=core
(As a tier 3 target, build-std is mandatory).

I expected to see this happen: compiles

Instead, this happened:
It fails to compile core:

rustc: /home/manuel/prog/rust_gpu/src/llvm-project/llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp:9502: SDValue llvm::SelectionDAG::getLoad(ISD::MemIndexedMode, ISD::LoadExtType, EVT, const SDLoc &, SDValue, SDValue, SDValue, EVT, MachineMemOperand *): Assertion `(!MMO->getRanges() || (mdconst::extract<ConstantInt>(MMO->getRanges()->getOperand(0)) ->getBitWidth() == MemVT.getScalarSizeInBits() && MemVT.isInteger())) && "Range metadata and load type must match!"' failed.

This is not reproducible on nightly, which doesn't seem surprising given: https://rustc-dev-guide.rust-lang.org/backend/debugging.html?highlight=llvm-assertions#enable-llvm-internal-checks

Meta

rustc --version --verbose:

latest master, build from source

cc @Flakebi

Backtrace

<backtrace>

[Flakebi]

I can reproduce this. It can be fixed by enabling lto in cargo (there’s an open bullet point for this in the amdgcn tracking issue):

# Cargo.toml
# I assume you already had the cdylib
[lib]
crate-type = ["cdylib"]

# This is new to fix compilation
[profile.dev]
lto = true
[profile.release]
lto = true

core then compiles and it fails with due to a missing panic handler, which is simple to add:

// lib.rs
#![no_std]

#[panic_handler]
fn panic(_: &core::panic::PanicInfo) -> ! {
    loop {}
}

fn foo() {}

With this, your command line finishes compilation for me (with and without the --emit=llvm-bc,llvm-ir).

[ZuseZ4]

oh that's awesome. But I'm also slightly confused. A contributor enforce fat-lto usage for autodoff, iirc. didn't you mention there ypu already enforce it? Shall we ask him to addd the check for amdgcn too?

[Flakebi]

The amdgcn target description in rustc forces lto.
However, for some unknown reason, this is not enough and one also needs to enable lto in Cargo.toml, otherwise there’s sometimes strange bugs.
Maybe cargo adds some conflicting flags unless lto is set?

(I encountered strange errors when trying to reproduce this issue and adding -Clto=fat to RUSTLFAGS)

[ZuseZ4]

cc @bjorn3 who could amswer related questions about lto in my autodiff issue.

Do you have a clue why the target mechanism didn't error here?

[ZuseZ4]

@Flakebi related discussion to your RUSTFLAGS: github.com//issues/147487

[bjorn3]

The amdgcn target contains requires_lto, which forces sess.lto() to return Lto::Fat. What I think the issue however is that cargo passes -Cembed-bitcode=no when LTO is not enabled through cargo. And while there is a check that -Cembed-bitcode=no and -Clto=yes are incompatible, this check doesn't take required_lto into account as it reads sess.opts.cg.lto rather than sess.lto():

rust/compiler/rustc_session/src/config.rs

Lines 2776 to 2783 in c90bcb9

	if !cg.embed_bitcode {
	match cg.lto {
	LtoCli::No | LtoCli::Unspecified => {}
	LtoCli::Yes | LtoCli::NoParam | LtoCli::Thin | LtoCli::Fat => {
	early_dcx.early_fatal("options `-C embed-bitcode=no` and `-C lto` are incompatible")
	}
	}
	}

[Flakebi]

Thanks for the hint @bjorn3, that saved me lots of debugging. I put up a potential fix in #149624 (potential because I don’t know if that’s the intended way to fix it, it does fix the problem).