Disable f128 for amdgpu

[Flakebi]

compiler_builtins fails to compile to amdgpu if f128 is enabled. The reason seems to be that compiler_builtins uses libcalls in the implementation. I’m not really familiar with what libcalls are, but the LLVM amdgpu backend explicitly does not support them.

Error message:

LLVM ERROR: unsupported libcall legalization

(The amdgpu target is not yet supported in rustc, there is an open PR here: rust-lang/rust#134740)

[tgross35]

Looks reasonable to me, would you be able to file an LLVM issue and add a link in the comment?

[Flakebi]

Looks reasonable to me, would you be able to file an LLVM issue and add a link in the comment?

Done!

[tgross35]

Thanks for the changes!

[tgross35]

After #731 merges, you can submit a PR to rust-lang/rust to update to 0.1.140. Feel free to r? me there.

[tgross35]

Also @Flakebi if you get the chance, could you post the whole error message / backtrace here? I’m curious where exactly this is failing. I have to expect it’s something like multiplication routines not being able to call addition on f128 (which should just be a libcall to addtf3, also provided in this crate).

I’m not really familiar with what libcalls are

For context, basic operations (add, subtract, etc), intrinsics (in Rust) and builtins (name for intrinsics in C) get sent to the backend as something like f128 c = add a, b. LLVM has the choice to either lower it to an assembly routine or a call to a library function that it expects to be available. Most integers and f32/f64 will be lowered to assembly, but most platforms don’t have hardware f128 so that turns into a “libcall” with a symbol name like __addtf3, __multf3, etc (tf=tetrafloat=f128, don’t ask). These symbols just need to be available when linking, and for Rust it’s this crate that provides them.

I’m not an LLVM expert but I think the error is just saying that it’s trying to turn something like f128 + f128 into a libcall since there is no asm routine, but it hasn’t been taught it can do this by calling __addtf3.

[Flakebi]

I think I made a slight mistake and should have checked for amdgcn instead of amdgpu.
I’ll fix this once the name is final in the Rust PR.

if you get the chance, could you post the whole error message / backtrace here? I’m curious where exactly this is failing.

It fails to compile here, because that’s the (only?) place where compiler-builtins uses a builtin itself:

compiler-builtins/src/float/pow.rs

Lines 41 to 46 in ff0ca1f

	#[cfg(f128_enabled)]
	// FIXME(f16_f128): MSVC cannot build these until `__divtf3` is available in nightly.
	#[cfg(not(target_env = "msvc"))]
	pub extern "C" fn __powitf2(a: f128, b: i32) -> f128 {
	pow(a, b)
	}

More details about why this fails are in llvm/llvm-project#121122

[bjorn3]

The __powitf2 function shouldn't be compiled at all if f128 is correctly disabled.

[Flakebi]

The __powitf2 function shouldn't be compiled at all if f128 is correctly disabled.

Right, compiler-builtins compiles correctly (without __powitf) if f128 is disabled :)

(Sorry, I mixed two points in the previous comment, (1) about the arch name and (2) about your previous question about where exactly it failed without disabling f128.)