rust/compiler/rustc_llvm/llvm-wrapper/PassWrapper.cpp, branch 1.72.0https://github.com/rust-lang/rust
http://git.dreamy.place/mirrors/rust/atom?h=1.72.02023-05-18T01:35:41+00:00Auto merge of #111364 - cuviper:unhack-thinlto, r=nikic2023-05-18T01:35:41+00:00borsbors@rust-lang.org2023-05-18T01:35:41+00:00urn:sha1:77fb0cd3aa276919e00397f526616c5036562ea1
Remove the ThinLTO CU hack
This reverts #46722, commit e0ab5d5feb4eb2d8af11b8dd9446c2b45fada8af.
Since #111167, commit 10b69dde3fd15334ea2382d2dc9e9a261de1afaf, we are
generating DWARF subprograms in a way that is meant to be more compatible
with LLVM's expectations, so hopefully we don't need this workaround
rewriting CUs anymore.
Usage of atomic counters for llvm code coverage2023-05-11T22:40:04+00:00Evgeniy A. Dushistovdushistov@mail.ru2023-05-11T14:35:01+00:00urn:sha1:6b58ff5cdf47da9460871a87cf43e5e8adfab9a8Remove the ThinLTO CU hack2023-05-08T17:34:15+00:00Josh Stonejistone@redhat.com2023-05-05T00:20:49+00:00urn:sha1:c836c24994f0113effd0409d8d063b4f4e68f5b6
This reverts #46722, commit e0ab5d5feb4eb2d8af11b8dd9446c2b45fada8af.
Since #111167, commit 10b69dde3fd15334ea2382d2dc9e9a261de1afaf, we are
generating DWARF subprograms in a way that is meant to be more compatible
with LLVM's expectations, so hopefully we don't need this workaround
rewriting CUs anymore.
Expand the LLVM coverage of `--print target-cpus`2023-05-06T00:27:59+00:00Josh Stonejistone@redhat.com2023-05-06T00:27:59+00:00urn:sha1:67ae38a336599a7e0d2898a5ea3416b947458f5d
We've been relying on a custom patch to add `MCSubtargetInfo::getCPUTable`
for `rustc --print target-cpus`, and just printing that it's not supported
on external LLVM builds. LLVM `main` now has `getAllProcessorDescriptions`
that can replace ours, so now we try to use that. In addition, the fallback
path can at least print the native and default cpu options.
There were also some mismatches in the function signatures here between
`LLVM_RUSTLLVM` and otherwise; this is now mitigated by sharing these
functions and only using cpp to adjust the function bodies.
change expect() to unwrap_or_else() and update msg2023-05-05T00:29:38+00:00James Dietzjamesthespeedy@gmail.com2023-04-30T13:47:29+00:00urn:sha1:cb74cd524f2798a098943425c271d9eada8d901emoved default CPU message inline2023-05-05T00:29:38+00:00James Dietzjamesthespeedy@gmail.com2023-04-28T21:23:40+00:00urn:sha1:9aa596a014d2582c1c51166953bd3fd85c71cca8`--print target-cpus` shows default target cpu, updated docs2023-05-05T00:29:38+00:00James Dietzjamesthespeedy@gmail.com2023-04-27T01:11:14+00:00urn:sha1:ea17aa9141cde9f26ec09b423ca2efe8aa08cc33[LLVM17] Adapt to `ExplicitEmulatedTLS` removal.2023-04-24T08:45:15+00:00Tim Neumanntimnn@google.com2023-04-24T08:30:05+00:00urn:sha1:047ed32148a39bc38ad18363ded9ab845dd313eeRollup merge of #110668 - ehuss:fix-native-cpu-list, r=cuviper2023-04-23T18:06:32+00:00Matthias Krügermatthias.krueger@famsik.de2023-04-23T18:06:32+00:00urn:sha1:12a539f484f5bd29e7fcdccbecd53d9e3aeb04cf
Fix printing native CPU on cross-compiled compiler.
If `rustc` is cross-compiled from a different host, then the "native" entry in `rustc --print=target-cpus` would not appear. There is a check in the printing code that will avoid printing the "native" entry if the user has passed `--target`. However, that check was comparing the `--target` value with the `LLVM_TARGET_TRIPLE` which is the triple of the host that `rustc` was built on (the "build" target in Rust lingo), not the target it was being built for (the "host" in Rust lingo). This fixes it to use the target that LLVM was built for (which I'm pretty sure this is the correct function to determine that).
This fixes the cpu listing for aarch64-apple-darwin which is built on CI using the x86_64-apple-darwin host.
Fix printing native CPU on cross-compiled compiler.2023-04-23T16:35:56+00:00Eric Husseric@huss.org2023-04-22T02:29:32+00:00urn:sha1:e4e4110dc6a0dcd2bade2fd789e81a518618e9c0