about summary refs log tree commit diff
path: root/compiler/rustc_codegen_llvm/src
AgeCommit message (Collapse)AuthorLines
2025-02-12Rollup merge of #135549 - oli-obk:push-tmxtpnrloyqu, r=compiler-errorsMatthias Krüger-147/+110
Document some safety constraints and use more safe wrappers Lots of unsafe codegen_llvm code has safe wrappers already, so I used some of them and added some where applicable. I stopped here because this diff is large enough and should probably be reviewed independently of other changes.
2025-02-11Document some safety constraints and use more safe wrappersOli Scherer-59/+50
2025-02-11Add a safe wrapper for `WriteBitcodeToFile`Oli Scherer-8/+10
2025-02-11Remove an unsafe closure invariant by inlining the closure wrapper into the ↵Oli Scherer-80/+50
called function
2025-02-11Rollup merge of #136813 - mrkajetanp:aarch32-fp16-target-feature, r=davidtwcoJacob Pratt-0/+1
rustc_target: Add the fp16 target feature for AArch32 As in the commit description. The feature is already available in rustc for AArch64.
2025-02-11Rollup merge of #136721 - dpaoliello:cleanllvm2, r=ZalatharJacob Pratt-8/+8
cg_llvm: Reduce visibility of some items outside the `llvm` module Next piece of #135502 This reduces the visibility of items (other than those in the `llvm` module) so that dead code analysis will correctly identify unused items.
2025-02-10rustc_codegen_llvm: Mark items as pub(crate) outside of the llvm moduleDaniel Paoliello-8/+8
2025-02-10Rollup merge of #136419 - EnzymeAD:autodiff-tests, r=onur-ozkan,jieyouxuMatthias Krüger-49/+64
adding autodiff tests I'd like to get started with upstreaming some tests, even though I'm still waiting for an answer on how to best integrate the enzyme pass. Can we therefore temporarily support the -Z llvm-plugins here without too much effort? And in that case, how would that work? I saw you can do remapping, e.g. `rust-src-base`, but I don't think that will give me the path to libEnzyme.so. Do you have another suggestion? Other than that this test simply checks that the derivative of `x*x` is `2.0 * x`, which in this case is computed as `%0 = fadd fast double %x.0.val, %x.0.val` (I'll add a few more tests and move it to an autodiff folder if we can use the -Z flag) r? ``@jieyouxu`` Locally at least `-Zllvm-plugins=${PWD}/build/x86_64-unknown-linux-gnu/enzyme/build/Enzyme/libEnzyme-19.so` seems to work if I copy the command I get from x.py test and run it manually. However, running x.py test itself fails. Tracking: - https://github.com/rust-lang/rust/issues/124509 Zulip discussion: https://rust-lang.zulipchat.com/#narrow/channel/326414-t-infra.2Fbootstrap/topic/Enzyme.20build.20changes
2025-02-10Rollup merge of #136053 - Zalathar:defer-counters, r=saethlinJubilee-48/+31
coverage: Defer part of counter-creation until codegen Follow-up to #135481 and #135873. One of the pleasant properties of the new counter-assignment algorithm is that we can stop partway through the process, store the intermediate state in MIR, and then resume the rest of the algorithm during codegen. This lets it take into account which parts of the control-flow graph were eliminated by MIR opts, resulting in fewer physical counters and simpler counter expressions. Those improvements end up completely obsoleting much larger chunks of code that were previously responsible for cleaning up the coverage metadata after MIR opts, while also doing a more thorough cleanup job. (That change also unlocks some further simplifications that I've kept out of this PR to limit its scope.)
2025-02-10remove outdated *First autodiff variants for higher-order adManuel Drehwald-2/+0
2025-02-10move second opt run to lto phase and cleanup codeManuel Drehwald-46/+55
2025-02-09Auto merge of #136751 - bjorn3:update_rustfmt, r=Mark-Simulacrumbors-264/+290
Update bootstrap compiler and rustfmt The rustfmt version we previously used formats things differently from what the latest nightly rustfmt does. This causes issues for subtrees that get formatted both in-tree and in their own repo. Updating the rustfmt used in-tree solves those issues. Also bumped the bootstrap compiler as the stage0 update command always updates both at the same time.
2025-02-09Auto merge of #136754 - Urgau:rollup-qlkhjqr, r=Urgaubors-1/+5
Rollup of 5 pull requests Successful merges: - #134679 (Windows: remove readonly files) - #136213 (Allow Rust to use a number of libc filesystem calls) - #136530 (Implement `x perf` directly in bootstrap) - #136601 (Detect (non-raw) borrows of null ZST pointers in CheckNull) - #136659 (Pick the max DWARF version when LTO'ing modules with different versions ) r? `@ghost` `@rustbot` modify labels: rollup
2025-02-08Rollup merge of #136706 - workingjubilee:finish-up-rustc-abi-updates, ↵Jubilee-6/+5
r=compiler-errors compiler: mostly-finish `rustc_abi` updates This almost-finishes all the updates in the compiler to use `rustc_abi` and removes some of the reexports of `rustc_abi` items in `rustc_target` that were previously available. r? ```@compiler-errors```
2025-02-09Rollup merge of #136659 - wesleywiser:dwarf_version_lto_merge_behavior, ↵Urgau-1/+5
r=jieyouxu Pick the max DWARF version when LTO'ing modules with different versions Currently, when rustc compiles code with `-Clto` enabled that was built with different choices for `-Zdwarf-version`, a warning will be reported. It's very easy to observe this by compiling most anything (eg, "hello world") and specifying `-Clto -Zdwarf-version=5` since the standard library is distributed with `-Zdwarf-version=4`. This behavior isn't actually useful for a few reasons: - From observation, LLVM chooses to pick the highest DWARF version anyway after issuing the warning. - Clang specifies that in this case, the max version should be picked without a warning and as a general principle, we want to support x-lang LTO with Clang which implies using the same module flag merge behaviors. - Debuggers need to be able to handle a variety of versions within the same debugging session as you can easily have some parts of a binary (or some dynamic libraries within an application) all compiled with different DWARF versions. This commit changes the module flag merge behavior to match Clang and use the highest version of DWARF. It also adds a test to ensure this behavior is respected in the case of two crates being LTO'd together and adds a test to ensure no warning is printed. Fixes #130041 which fails due to these warnings being printed cc #103057
2025-02-08Rustfmtbjorn3-264/+290
2025-02-08Pick the max DWARF version when LTO'ing modules with different versionsWesley Wiser-1/+5
Currently, when rustc compiles code with `-Clto` enabled that was built with different choices for `-Zdwarf-version`, a warning will be reported. It's very easy to observe this by compiling most anything (eg, "hello world") and specifying `-Clto -Zdwarf-version=5` since the standard library is distributed with `-Zdwarf-version=4`. This behavior isn't actually useful for a few reasons: - from observation, LLVM chooses to pick the highest DWARF version anyway after issuing the warning - Clang specifies that in this case, the max version should be picked without a warning and as a general principle, we want to support x-lang LTO with Clang which implies using the same module flag merge behaviors - Debuggers need to be able to handle a variety of versions withing the same debugging session as you can easily have some parts of a binary (or some dynamic libraries within an application) all compiled with different DWARF versions This commit changes the module flag merge behavior to match Clang and use the highest version of DWARF. It also adds a test to ensure this behavior is respected in the case of two crates being LTO'd together and updates the test added in the previous commit to ensure no warning is printed.
2025-02-07fix non-enzyme buildsManuel Drehwald-1/+4
2025-02-08Rollup merge of #136691 - bjorn3:linkage_cleanup, r=jieyouxuMatthias Krüger-6/+1
Remove Linkage::Private and Linkage::Appending Neither of them has any use case. Neither known nor theoretical.
2025-02-08Rollup merge of #136640 - Zalathar:debuginfo-align-bits, r=compiler-errorsMatthias Krüger-8/+5
Debuginfo for function ZSTs should have alignment of 8 bits, not 1 bit In #116096, function ZSTs were made to have debuginfo that gives them an alignment of “1”. But because alignment in LLVM debuginfo is denoted in *bits*, not bytes, this resulted in an alignment specification of 1 bit instead of 1 byte. I don't know whether this has any practical consequences, but I noticed that a test started failing when I accidentally fixed the mistake while working on #136632, so I extracted the fix (and the test adjustment) to this PR.
2025-02-07compiler: remove reexports from rustc_target::callconvJubilee Young-6/+5
2025-02-07rustc_target: Add the fp16 target feature for AArch32Kajetan Puchalski-0/+1
2025-02-07Remove Linkage::Appendingbjorn3-1/+0
It can only be used for certain LLVM internal variables like llvm.global_ctors which users are not allowed to define.
2025-02-07Remove Linkage::Privatebjorn3-5/+1
This is the same as Linkage::Internal except that it doesn't emit any symbol. Some backends may not support it and it isn't all that useful anyway.
2025-02-06Remove dead code from rustc_codegen_llvm and the LLVM wrapperDaniel Paoliello-29/+0
2025-02-06Debuginfo for function ZSTs should have alignment of 8 bits, not 1 bitZalathar-8/+5
2025-02-06Auto merge of #136471 - safinaskar:parallel, r=SparrowLiibors-2/+2
tree-wide: parallel: Fully removed all `Lrc`, replaced with `Arc` tree-wide: parallel: Fully removed all `Lrc`, replaced with `Arc` This is continuation of https://github.com/rust-lang/rust/pull/132282 . I'm pretty sure I did everything right. In particular, I searched all occurrences of `Lrc` in submodules and made sure that they don't need replacement. There are other possibilities, through. We can define `enum Lrc<T> { Rc(Rc<T>), Arc(Arc<T>) }`. Or we can make `Lrc` a union and on every clone we can read from special thread-local variable. Or we can add a generic parameter to `Lrc` and, yes, this parameter will be everywhere across all codebase. So, if you think we should take some alternative approach, then don't merge this PR. But if it is decided to stick with `Arc`, then, please, merge. cc "Parallel Rustc Front-end" ( https://github.com/rust-lang/rust/issues/113349 ) r? SparrowLii `@rustbot` label WG-compiler-parallel
2025-02-06coverage: Remove the old code for simplifying counters after MIR optsZalathar-19/+10
2025-02-06coverage: Defer part of counter-creation until codegenZalathar-23/+10
2025-02-06coverage: Store BCB node IDs in mappings, and resolve them in codegenZalathar-12/+17
Even though the coverage graph itself is no longer available during codegen, its nodes can still be used as opaque IDs.
2025-02-06Remove some unused glob re-exportsZalathar-4/+0
These were detected by temporarily making `mod llvm` non-public.
2025-02-06Remove the `mod llvm_` hack, which should no longer be necessaryZalathar-8/+3
2025-02-05fix fwd-mode autodiff caseManuel Drehwald-3/+8
2025-02-05Rollup merge of #136375 - Zalathar:llvm-di-builder, r=workingjubileeLeón Orell Valerian Liehr-62/+121
cg_llvm: Replace some DIBuilder wrappers with LLVM-C API bindings (part 1) Part of #134001, follow-up to #136326, extracted from #134009. This PR performs an arbitrary subset of the LLVM-C binding migrations from #134009, which should make it less tedious to review. The remaining migrations can occur in one or more subsequent PRs.
2025-02-04Auto merge of #135760 - scottmcm:disjoint-bitor, r=WaffleLapkinbors-0/+17
Add `unchecked_disjoint_bitor` per ACP373 Following the names from libs-api in https://github.com/rust-lang/libs-team/issues/373#issuecomment-2085686057 Includes a fallback implementation so this doesn't have to update cg_clif or cg_gcc, and overrides it in cg_llvm to use `or disjoint`, which [is available in LLVM 18](https://releases.llvm.org/18.1.0/docs/LangRef.html#or-instruction) so hopefully we don't need any version checks.
2025-02-03tree-wide: parallel: Fully removed all `Lrc`, replaced with `Arc`Askar Safin-2/+2
2025-02-02Handle the case where the `or disjoint` folds immediately to a constantScott McMurray-1/+7
2025-02-02Rollup merge of #136426 - oli-obk:push-nkpuulwurykn, r=compiler-errorsMatthias Krüger-2/+8
Explain why we retroactively change a static initializer to have a different type I keep getting confused about it and in turn confused `@GuillaumeGomez` while trying to explain it badly
2025-02-01Explain why we retroactively change a static initializer to have a different ↵Oli Scherer-2/+8
type
2025-01-31Override `disjoint_or` in the LLVM backendScott McMurray-0/+11
2025-02-01Explain why (some) pointer/length strings are `*const c_uchar`Zalathar-0/+12
2025-02-01Add FIXME for auditing optional parameters passed to DIBuilderZalathar-0/+4
2025-02-01Use `LLVMDIBuilderCreateDebugLocation`Zalathar-7/+9
The LLVM-C binding takes an explicit context, whereas our binding obtained the context from the scope argument.
2025-02-01Use `LLVMDIBuilderCreateLexicalBlockFile`Zalathar-10/+17
2025-02-01Use `LLVMDIBuilderCreateLexicalBlock`Zalathar-9/+9
2025-02-01Use `LLVMDIBuilderCreateNameSpace`Zalathar-17/+18
2025-02-01Use `LLVMDIBuilderFinalize`Zalathar-3/+3
2025-02-01Introduce `DIBuilderBox`, an owning pointer to `DIBuilder`Zalathar-20/+53
2025-01-31Add link attribute for Enzyme's FFIBen Kimock-2/+7
2025-01-31Auto merge of #136332 - jhpratt:rollup-aa69d0e, r=jhprattbors-9/+11
Rollup of 9 pull requests Successful merges: - #132156 (When encountering unexpected closure return type, point at return type/expression) - #133429 (Autodiff Upstreaming - rustc_codegen_ssa, rustc_middle) - #136281 (`rustc_hir_analysis` cleanups) - #136297 (Fix a typo in profile-guided-optimization.md) - #136300 (atomic: extend compare_and_swap migration docs) - #136310 (normalize `*.long-type.txt` paths for compare-mode tests) - #136312 (Disable `overflow_delimited_expr` in edition 2024) - #136313 (Filter out RPITITs when suggesting unconstrained assoc type on too many generics) - #136323 (Fix a typo in conventions.md) r? `@ghost` `@rustbot` modify labels: rollup
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-25 12:20:27 +0000