rust/compiler/rustc_codegen_llvm/src, branch 1.85.0https://github.com/rust-lang/rust
http://git.dreamy.place/mirrors/rust/atom?h=1.85.02025-01-23T16:45:35+00:00When LLVM's location discriminator value limit is exceeded, emit locations with dummy spans instead of dropping them entirely2025-01-23T16:45:35+00:00Kyle Hueykhuey@kylehuey.com2025-01-17T17:44:09+00:00urn:sha1:4595e112d0c76cd2717f56f6a596f7ebc35f1461
Revert most of #133194 (except the test and the comment fixes). Then refix
not emitting locations at all when the correct location discriminator value
exceeds LLVM's capacity.
(cherry picked from commit 45ef92731b637a60cbad7cecf5382361bbf40531)
Remove range-metadata amdgpu workaround2025-01-02T14:45:04+00:00Flakebiflakebi@t-online.de2025-01-02T12:10:51+00:00urn:sha1:56bf673f0a1698a4ebcd2d29bfbcc2c0220148ac
Range metadata was disabled for amdgpu due to a backend bug. I did not
encounter any problems when removing the workaround to enable range
metadata (tried compiling `core` and `alloc`), so I assume this has
been fixed in LLVM in the last years.
Remove the workaround to re-enable range metadata.
upstream rustc_codegen_llvm changes for enzyme/autodiff2025-01-01T20:42:45+00:00Manuel Drehwaldgit@manuel.drehwald.info2025-01-01T20:42:45+00:00urn:sha1:d753cbf7793f20229ed7a151d060456a9e1396e9add llvm_floatabi field to target spec that controls FloatABIType2024-12-30T20:59:05+00:00Ralf Jungpost@ralfj.de2024-12-30T18:08:03+00:00urn:sha1:a0dbb37ebd7919df4b698deb356e024a741283ecrustc_llvm: expose FloatABIType target machine parameter2024-12-30T17:10:59+00:00Ralf Jungpost@ralfj.de2024-12-30T17:10:59+00:00urn:sha1:fff026c8e572809cfce7202ec1ad63897b72c5b0make -Csoft-float have an effect on all ARM targets2024-12-29T10:10:36+00:00Ralf Jungpost@ralfj.de2024-12-29T10:10:36+00:00urn:sha1:62bb35ab5d99dc0b7d6cc77687b09e94ccd228c6Override `carrying_mul_add` in cg_llvm2024-12-27T16:17:40+00:00Scott McMurrayscottmcm@users.noreply.github.com2024-11-30T06:51:46+00:00urn:sha1:4669c0d756ddfbd3df0ee1d5c7a4b1cdaabf5945Remove some dead code around import library generation2024-12-20T15:20:15+00:00bjorn317426603+bjorn3@users.noreply.github.com2024-12-20T15:20:15+00:00urn:sha1:c02c311d84a919f6be3b797866100214c91c5b68
This was missed when replacing the usage of LLVM for generating import
libraries.
Rollup merge of #134497 - Zalathar:spans, r=jieyouxu2024-12-19T14:26:16+00:00Matthias Krügermatthias.krueger@famsik.de2024-12-19T14:26:16+00:00urn:sha1:57cbd078f2748d9af7ef76694becc7c9096140b9
coverage: Store coverage source regions as `Span` until codegen (take 2)
This is an attempt to re-land #133418:
> Historically, coverage spans were converted into line/column coordinates during the MIR instrumentation pass.
> This PR moves that conversion step into codegen, so that coverage spans spend most of their time stored as Span instead.
> In addition to being conceptually nicer, this also reduces the size of coverage mappings in MIR, because Span is smaller than 4x u32.
That PR was reverted by #133608, because in some circumstances not covered by our test suite we were emitting coverage metadata that was causing `llvm-cov` to exit with an error (#133606).
---
The implementation here is *mostly* the same, but adapted for subsequent changes in the relevant code (e.g. #134163).
I believe that the changes in #134163 should be sufficient to prevent the problem that required the original PR to be reverted. But I haven't been able to reproduce the original breakage in a regression test, and the `llvm-cov` error message is extremely unhelpful, so I can't completely rule out the possibility of this breaking again.
r? jieyouxu (reviewer of the original PR)
coverage: Add a synthetic test for when all spans are discarded2024-12-19T11:03:43+00:00ZalatharZalathar@users.noreply.github.com2024-12-19T10:53:10+00:00urn:sha1:aced4dcf1047aab08b769b34fae9d4ba7de87f04