Restore #![no_builtins] crates participation in LTO.

[dianqk]

After #113716, we can make #![no_builtins] crates participate in LTO again.

#![no_builtins] with LTO does not result in undefined references to the error. I believe this type of issue won't happen again.

Fixes #72140. Fixes #112245. Fixes #110606. Fixes #105734. Fixes #96486. Fixes #108853. Fixes #108893. Fixes #78744. Fixes #91158. Fixes rust-lang/cargo#10118. Fixes rust-lang/compiler-builtins#347.

The nightly-2023-07-20 version does not always reproduce problems due to changes in compiler-builtins, core, and user code. That's why this issue recurs and disappears.
Some issues were not tested due to the difficulty of reproducing them.

r? pnkfelix

cc @bjorn3 @japaric @alexcrichton @Amanieu

[dianqk]

Removed opaque pointers for LLVM 14.

[dianqk]

ping? @pnkfelix

[dianqk]

Rebase and remove the DisableSimplifyLibCalls parameter.

[dianqk]

@rustbot ready

[pnkfelix]

@bors r+ rollup=never

[bors]

📌 Commit c1ec76c has been approved by pnkfelix

It is now in the queue for this repository.

[bors]

⌛ Testing commit c1ec76c with merge f4589297857113e2cc3f6437f112d567b4da3694...

[bors]

💔 Test failed - checks-actions

[dianqk]

Based on the error message, I believe #78744, #91158 amd rust-lang/cargo#10118 are also not participating in the LTO issue.
But let me fix the no_builtins issue with wasm first.

It show

  (import "env" "__muloti4" (func $__muloti4 (type 0)))

[dianqk]

@rustbot author

[dianqk]

TL;DR
Using built-in functions like __multi3 does not generate calls during IR optimization.
This call is not generated until the LLVM code generation phase.
https://llvm.godbolt.org/z/aoMK4KTWT is an example.

I renamed wasm-spurious-import to wasm-builtins-import. Because we have found the essence of the problem, and it is the same issue that this PR is trying to solve. (That's why it magically disappeared.)
Now we use this test to check that the built-in functions are not missing.

---

An interesting attempt: I can get correct results using LLVM's LTO in lld.
I just need to change the main.main.7fc14dcaa7e3fa65-cgu.0.rcgu.o to main.main.7fc14dcaa7e3fa65-cgu.0.rcgu.lto.input.bc.

"lld" "-flavor" "wasm" "--rsp-quoting=posix" \
"--export" "multer" "--export=__heap_base" "--export=__data_end" \
"-z" "stack-size=1048576" "--stack-first" "--allow-undefined" "--fatal-warnings" "--no-demangle" "--no-entry" \
"main.main.7fc14dcaa7e3fa65-cgu.0.rcgu.lto.input.bc" \
"-o" "main.wasm" "--gc-sections" "--no-entry" "-O3"

I investigated along with this result why lld's LTO could be successful.
Then I found llvm/llvm-project@e06bac4.

---

Two issues in LLVM (or maybe not).

• The first is InternalizePass should consider built-in functions. InternalizePass should consider built-in functions. llvm/llvm-project#65965
• The second is the no-builtins should work with __multi3. https://llvm.godbolt.org/z/9vcj8dqaY "no-builtins" should work on __multi3? llvm/llvm-project#65031

[bors]

💔 Test failed - checks-actions

[dianqk]

The job x86_64-msvc failed! Check out the build log: (web) (plain)
Click to see the possible cause of the failure (guessed by this bot)

It works. But llvm-dis doesn't work on windows?

[bjorn3]

@bors r=pnkfelix

[bors]

📌 Commit b9f53be has been approved by pnkfelix

It is now in the queue for this repository.

[bors]

⌛ Testing commit b9f53be with merge 8c2b577...

[bors]

☀️ Test successful - checks-actions
Approved by: pnkfelix
Pushing 8c2b577 to master...

[rust-timer]

Finished benchmarking commit (8c2b577): comparison URL.

Overall result: ❌ regressions - ACTION NEEDED

Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please open an issue or create a new PR that fixes the regressions, add a comment linking to the newly created issue or PR, and then add the perf-regression-triaged label to this PR.

@rustbot label: +perf-regression
cc @rust-lang/wg-compiler-performance

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	6.4%	[0.8%, 12.4%]	17
Regressions ❌ (secondary)	5.3%	[0.5%, 12.2%]	72
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	6.4%	[0.8%, 12.4%]	17

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	3.0%	[1.5%, 4.5%]	2
Regressions ❌ (secondary)	3.1%	[2.7%, 3.7%]	3
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.0%	[-3.1%, -1.0%]	2
All ❌✅ (primary)	3.0%	[1.5%, 4.5%]	2

Cycles

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	7.0%	[1.7%, 13.4%]	17
Regressions ❌ (secondary)	6.7%	[1.1%, 13.2%]	60
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	7.0%	[1.7%, 13.4%]	17

Binary size

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	3.7%	[0.4%, 5.8%]	24
Regressions ❌ (secondary)	5.4%	[0.2%, 5.9%]	76
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	3.7%	[0.4%, 5.8%]	24

Bootstrap: 673.541s -> 672.846s (-0.10%)
Artifact size: 313.37 MiB -> 313.94 MiB (0.18%)

[bjorn3]

It seems that linking has become 10-20ms slower and binaries ~260kb bigger. Maybe we no longer gc unused compiler builtins functions?

[nnethercote]

Right, those compile-time regressions are really bad :( Lots of ~5% binary size increases, too. What can be done?

[bjorn3]

I believe I saw something around symbols being marked as "used". If this is currently linker used, maybe we can downgrade it to compiler used?

[dianqk]

Right, those compile-time regressions are really bad :( Lots of ~5% binary size increases, too. What can be done?

I can verify that this indeed preserves builtin functions.

[dianqk]

It seems that linking has become 10-20ms slower and binaries ~260kb bigger. Maybe we no longer gc unused compiler builtins functions?

This should be the right way to go.

I believe I saw something around symbols being marked as "used". If this is currently linker used, maybe we can downgrade it to compiler used?

I will start debugging with your analysis this weekend. :)

[rylev]

#118568 seems to reverse these perf regressions.

@rustbot label: +perf-regression-triaged