f16 and f128 step 4: basic library support

[tgross35]

This is the next step after #121926, another portion of #114607

Tracking issue: #116909

This PR adds the most basic operations to f16 and f128 that get lowered as LLVM intrinsics. This is a very small step but it seemed reasonable enough to add unopinionated basic operations before the larger modules that are built on top of them.

r? @Amanieu since you were pretty involved in the RFC
cc @compiler-errors
@rustbot label +T-libs-api +S-blocked +F-f16_and_f128

[tgross35]

@bjorn3 @antoyo do both GCC and Clif have CI covered enough that breaking library builds isn't a concern, as long as CI passes?

Contrasting this to #114607 (comment) which is from a while ago. Most of the inlines needed there were for formatting, which I do not intend to add until a few weeks from now anyway.

[bjorn3]

do both GCC and Clif have CI covered enough that breaking library builds isn't a concern, as long as CI passes?

cg_clif doesn't build the standard library in CI. It reuses the one built by LLVM, so no CI passing is not enough. You also have to set cranelift as sole codegen backend in config.toml and then try a build to make it compile the standard library with cg_clif.

[antoyo]

@bjorn3 @antoyo do both GCC and Clif have CI covered enough that breaking library builds isn't a concern, as long as CI passes?

I would assume it is the same as cg_cranelift, but cc-ing @GuillaumeGomez since he added the CI for cg_gcc.

[GuillaumeGomez]

Just for information, we run a small subset of tests currently. You can see them here. I can add more if you want?

[tgross35]

Thanks all for the info. Is there any reason the backends couldn't try building the libraries in CI, even if tests can't be run for any reason?

I can check locally but it would probably be good to have that feedback readily available, even beyond this change

[tgross35]

#121926 landed so I rebased, LLVM tests pass now. I cannot seem to get the different backends working though - running ./x t --stage 2 library/core/ library/std with codegen-backends = ["llvm", "cranelift"] passes, but I can't get cranelift alone to compile. These errors look more like a config issue than something caused by the changes in this PR, e.g. with codegen-backends = ["cranelift"] I get:

error: unsupported builtin codegen backend `llvm`

error: unsupported builtin codegen backend `llvm`

error: Failed to assemble `.globl __inline_asm_compiler_builtins__df7f94933c94f82c_cgu__000_n0
       .type __inline_asm_compiler_builtins__df7f94933c94f82c_cgu__000_n0,@function
       .section .text.__inline_asm_compiler_builtins__df7f94933c94f82c_cgu__000_n0,"ax",@progbits
       __inline_asm_compiler_builtins__df7f94933c94f82c_cgu__000_n0:
       .intel_syntax noprefix
...

And with codegen-backends = ["cranelift", "llvm"]:

   Compiling core v0.0.0 (/home/tmgross/projects/rust/rustc/library/core)
    Finished release [optimized] target(s) in 23.37s
     Running tests/lib.rs (build/x86_64-unknown-linux-gnu/stage1-std/x86_64-unknown-linux-gnu/release/deps/coretests-c2a4ac97d8e0ebe7)

running 1666 tests
fatal runtime error: failed to initiate panic, error 5
error: test failed, to rerun pass `-p core --test coretests`

Caused by:
  process didn't exit successfully: `/home/tmgross/projects/rust/rustc/build/x86_64-unknown-linux-gnu/stage1-std/x86_64-unknown-linux-gnu/release/deps/coretests-c2a4ac97d8e0ebe7 --quiet -Z unstable-options --format json` (signal: 6, SIGABRT: process abort signal)
Build completed unsuccessfully in 0:05:24

I didn't yet try the GCC backend. Is there a more automated way to test with GCC now that it is in tree, like with the LLVM submodule? Or does it still need to be built separately

[GuillaumeGomez]

I didn't yet try the GCC backend. Is there a more automated way to test with GCC now that it is in tree, like with the LLVM submodule? Or does it still need to be built separately

Still needs to be built separately for now. Once the vendoring PR is merged, I'll be able to start adding config so you can specify which backend to use.

[bors]

☔ The latest upstream changes (presumably #122754) made this pull request unmergeable. Please resolve the merge conflicts.

[tgross35]

@rustbot label +rla-silenced

[rust-log-analyzer]

A job failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

[compiler-errors]

@craterbot run mode=check-only start=master#aa067fb984d36462548bb785da221bfaf38253f0 end=try#530e69408e76a29e47f25e5aedaf0e3fdf629e5b

[craterbot]

👌 Experiment pr-122470 created and queued.
🔍 You can check out the queue and this experiment's details.

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

[craterbot]

🚧 Experiment pr-122470 is now running

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

[Mark-Simulacrum]

@craterbot abort

[craterbot]

🗑️ Experiment pr-122470 deleted!

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

[Mark-Simulacrum]

@craterbot run mode=check-only start=master#aa067fb984d36462548bb785da221bfaf38253f0 end=try#707d6562f55b55a7aab4ab3a904997116b358314

Trying with an actually existing commit from the unrolled build.

[craterbot]

👌 Experiment pr-122470 created and queued.
🔍 You can check out the queue and this experiment's details.

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

[craterbot]

🚧 Experiment pr-122470 is now running

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

[craterbot]

🎉 Experiment pr-122470 is completed!
📊 1691 regressed and 1 fixed (437764 total)
📰 Open the full report.

⚠️ If you notice any spurious failure please add them to the blacklist!
ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more