about summary refs log tree commit diff
path: root/src/librustc_codegen_ssa
AgeCommit message (Collapse)AuthorLines
2020-05-15Rollup merge of #72062 - overdrivenpotato:psp, r=jonas-schievinkDylan DPC-0/+25
Add built in PSP target This adds a new target, `mipsel-sony-psp`, corresponding to the Sony PSP. The linker script is necessary to handle special sections, which are required by the target. This has been tested with my [rust-psp] crate and I can confirm it works as intended. The linker script is taken from [here]. It has been slightly adapted to work with rust and LLD. The `stdarch` submodule was also updated in order for `libcore` to build successfully. [rust-psp]: https://github.com/overdrivenpotato/rust-psp [here]: https://github.com/pspdev/pspsdk/blob/master/src/base/linkfile.prx.in
2020-05-14Rollup merge of #72126 - nnethercote:change-WorkProduct-saved_files, ↵Dylan DPC-9/+5
r=alexcrichton Change `WorkProduct::saved_files` to an `Option`. Because there is at most one file. r? @bjorn3
2020-05-12Change `WorkProduct::saved_files` to an `Option`.Nicholas Nethercote-9/+5
Because there is at most one file.
2020-05-12Remove ty::UnnormalizedProjectionJack Huey-1/+0
2020-05-10Run rustfmtMarko Mijalkovic-6/+1
2020-05-10Renamed lld_link_script to link_script and support all GNU-like linkersMarko Mijalkovic-10/+9
2020-05-10Auto merge of #71825 - contrun:cg-option-strip, r=petrochenkovbors-34/+53
add codegen option strip closes https://github.com/rust-lang/rust/issues/71757 I don't know if the flags added here works for all linkers. I only tested on my Linux pc. I also don't know what is the best for emlinker, PtxLinker, MsvcLinker. The option for WasmLd is copied from https://aransentin.github.io/cwasm/.
2020-05-10Add lld_link_script to TargetOptionsMarko Mijalkovic-0/+31
2020-05-10add linking option stripYI-34/+53
move strip option to "Z" add more strip options, remove strip-debuginfo-if-disabled merge strip and debuginfo
2020-05-10Auto merge of #72020 - alexcrichton:fix-incremental-linker-plugin-lto, r=oli-obkbors-35/+54
Fix disagreeement about CGU reuse and LTO This commit fixes an issue where the codegen backend's selection of LTO disagreed with what the codegen later thought was being done. Discovered in #72006 we have a longstanding issue where if `-Clinker-plugin-lto` in optimized mode is compiled incrementally it will always panic on the second compilation. The underlying issue turned out to be that the production of the original artifact determined that LTO should not be done (because it's being postponed to the linker) but the CGU reuse selection thought that LTO was done so it was trying to load pre-LTO artifacts which were never generated. The fix here is to ensure that the logic when generating code which determines what kind of LTO is being done is shared amongst the CGU reuse decision and the backend actually doing LTO. This means that they'll both be in agreement about whether the previous compilation did indeed produce incremental pre-LTO artifacts. Closes #72006
2020-05-09Fix disagreeement about CGU reuse and LTOAlex Crichton-35/+54
This commit fixes an issue where the codegen backend's selection of LTO disagreed with what the codegen later thought was being done. Discovered in #72006 we have a longstanding issue where if `-Clinker-plugin-lto` in optimized mode is compiled incrementally it will always panic on the second compilation. The underlying issue turned out to be that the production of the original artifact determined that LTO should not be done (because it's being postponed to the linker) but the CGU reuse selection thought that LTO was done so it was trying to load pre-LTO artifacts which were never generated. The fix here is to ensure that the logic when generating code which determines what kind of LTO is being done is shared amongst the CGU reuse decision and the backend actually doing LTO. This means that they'll both be in agreement about whether the previous compilation did indeed produce incremental pre-LTO artifacts. Closes #72006
2020-05-09Rollup merge of #71555 - cjgillot:nameless, r=matthewjasperRalf Jung-3/+2
Remove ast::{Ident, Name} reexports. The reexport of `Symbol` into `Name` confused me.
2020-05-09Rollup merge of #71508 - oli-obk:alloc_map_unlock, r=RalfJungRalf Jung-1/+1
Simplify the `tcx.alloc_map` API This PR changes all functions that require manually locking the `alloc_map` to functions on `TyCtxt` that lock the map internally. In the same step we make the `TyCtxt::alloc_map` field private. r? @RalfJung
2020-05-08Rollup merge of #71970 - thombles:ios-bitcode-improvements, r=alexcrichtonDylan DPC-15/+9
Improve bitcode generation for Apple platforms Some improvements for iOS bitcode support suggested by Alex over at https://github.com/getditto/rust-bitcode/issues/9. r? @alexcrichton This improves Rust's bitcode generation so that provided you have a compatible LLVM version, Rust targeting iOS should work out of the box when compiled into bitcode-enabled apps, and when submitted to the App Store. I've tested these changes using Xcode 11.4.1 and Apple's vendored LLVM, [tag `swift-5.2.3-RELEASE`](https://github.com/apple/llvm-project/releases/tag/swift-5.2.3-RELEASE). 1. Force `aarch64-apple-ios` and `aarch64-apple-tvos` targets to always emit full bitcode sections, even when cargo is trying to optimise by invoking `rustc` with `-Cembed-bitcode=no`. Since Apple recommends bitcode on iOS and requires it on tvOS it is likely that this is what developers intend. Currently you need to override the codegen options with `RUSTFLAGS`, which is far from obvious. 2. Provide an LLVM cmdline in the target spec. Apple's bitcode verification process looks for some arguments. For Rust modules to be accepted we must pretend they were produced similarly. A suitable default is provided in `TargetOptions` for iOS, copied directly from the a clang equivalent section. In the context of Apple platforms, the predominant purpose of bitcode is App Store submissions, so simulator and 32-bit targets are not relevant. I'm hoping that the cmdline strings will not be a maintenance burden to keep up-to-date. If the event of any future incompatibilities, hopefully a custom target config would offer enough flexibility to work around it. It's impossible to say for sure. Due to unrelated build errors I haven't been able to build and test a full tvOS toolchain. I've stopped short of providing a similar `bitcode_llvm_cmdline` until I can actually test it.
2020-05-08Remove ast::{Ident, Name} reexports.Camille GILLOT-3/+2
2020-05-08Simplify the `tcx.alloc_map` APIOliver Scherer-1/+1
2020-05-08Simplify bitcode embedding - either None or FullTom Karpiniec-16/+6
2020-05-07Provide configurable LLVM cmdline section via target specTom Karpiniec-0/+2
The App Store performs certain sanity checks on bitcode, including that an acceptable set of command line arguments was used when compiling a given module. For Rust code to be distributed on the app store with bitcode rustc must pretend to have the same command line arguments.
2020-05-07Force embed-bitcode on non-simulator iOS/tvOS targetsTom Karpiniec-0/+2
At this time Apple recommends Bitcode be included for iOS apps, and requires it for tvOS. It is unlikely that a developer would want to disable bitcode when building for these targets, yet by default it will not be generated. This presents a papercut for developers on those platforms. Introduces a new TargetOption boolean key for specific triples to indicate that bitcode should be generated, even if cargo attempts to optimise with -Cembed-bitcode=no.
2020-05-06Rollup merge of #71269 - Mark-Simulacrum:sat-float-casts, r=nikicDylan DPC-1/+1
Define UB in float-to-int casts to saturate This closes #10184 by defining the behavior there to saturate infinities and values exceeding the integral range (on the lower or upper end). `NaN` is sent to zero.
2020-05-06Define UB in float-to-int casts to saturateMark Rousskov-1/+1
- Round to zero, and representable values cast directly. - `NaN` goes to 0 - Values beyond the limits of the type are saturated to the "nearest value" (essentially rounding to zero, in some sense) in the integral type, so e.g. `f32::INFINITY` would go to `{u,i}N::MAX.`
2020-05-04Auto merge of #71754 - alexcrichton:no-bitcode-in-cache, r=nnethercotebors-21/+6
Don't copy bytecode files into the incr. comp. cache. It's no longer necessary now that bitcode is embedded into object files. This change meant that `WorkProductFileKind::Bytecode` is no longer necessary, which means that type is no longer necessary, which allowed several places in the code to become simpler. This commit was written by @nnethercote in https://github.com/rust-lang/rust/pull/70458 but that didn't land. In the meantime though we managed to land it in https://github.com/rust-lang/rust/pull/71528 and that doesn't seem to be causing too many fires, so I'm re-sending this patch!
2020-05-03Add `MutatingUseContext::Yield`Dylan MacKenzie-1/+2
...emulating `MutatingUseContext::Call`
2020-05-02Rollup merge of #71787 - tshepang:rustdoc-warnings, r=varkorDylan DPC-1/+1
fix rustdoc warnings
2020-05-02Rollup merge of #71777 - petrochenkov:crtype, r=Mark-SimulacrumDylan DPC-52/+49
cleanup: `config::CrateType` -> `CrateType`
2020-05-02Rollup merge of #71772 - cjgillot:ensure, r=petrochenkovDylan DPC-1/+1
Mark query function as must_use. And use the `ensure()` version when the result is not needed.
2020-05-02cleanup: `config::CrateType` -> `CrateType`Vadim Petrochenkov-52/+49
2020-05-02fix rustdoc warningsTshepang Lekhonkhobe-1/+1
2020-05-02Auto merge of #71716 - alexcrichton:bitcode-follow-up, r=nnethercotebors-2/+2
Rename `bitcode-in-rlib` option to `embed-bitcode` This commit finishes work first pioneered in #70458 and started in #71528. The `-C bitcode-in-rlib` option, which has not yet reached stable, is renamed to `-C embed-bitcode` since that more accurately reflects what it does now anyway. Various tests and such are updated along the way as well. This'll also need to be backported to the beta channel to ensure we don't accidentally stabilize `-Cbitcode-in-rlib` as well.
2020-05-01Rollup merge of #71747 - spastorino:safety-scheme-around-consts-cleanup, ↵Dylan DPC-19/+3
r=oli-obk Remove deadcode in eval_mir_constant_to_operand r? @oli-obk @RalfJung
2020-05-01Rename `bitcode-in-rlib` option to `embed-bitcode`Alex Crichton-2/+2
This commit finishes work first pioneered in #70458 and started in #71528. The `-C bitcode-in-rlib` option, which has not yet reached stable, is renamed to `-C embed-bitcode` since that more accurately reflects what it does now anyway. Various tests and such are updated along the way as well. This'll also need to be backported to the beta channel to ensure we don't accidentally stabilize `-Cbitcode-in-rlib` as well.
2020-05-01Mark query function as must_use.Camille GILLOT-1/+1
2020-05-01Don't copy bytecode files into the incr. comp. cache.Nicholas Nethercote-21/+6
It's no longer necessary now that bitcode is embedded into object files. This change meant that `WorkProductFileKind::Bytecode` is no longer necessary, which means that type is no longer necessary, which allowed several places in the code to become simpler.
2020-05-01Remove deadcode in eval_mir_constant_to_operandSantiago Pastorino-19/+3
2020-05-01Auto merge of #71623 - petrochenkov:localink, r=estebankbors-1/+16
Disable localization for all linkers We previously disabled non-English output from `link.exe` due to encoding issues (#35785). In https://github.com/rust-lang/rust/pull/70740 it was pointed out that it also prevents correct inspection of the linker output, which we have to do occasionally. So this PR disables localization for all linkers.
2020-05-01Auto merge of #70674 - cjgillot:query-arena-all, r=matthewjasperbors-9/+6
Have the per-query caches store the results on arenas This PR leverages the cache for each query to serve as storage area for the query results. It introduces a new cache `ArenaCache`, which moves the result to an arena, and only stores the reference in the hash map. This allows to remove a sizeable part of the usage of the global `TyCtxt` arena. I only migrated queries that already used arenas before.
2020-04-30Auto merge of #70175 - Amanieu:remove_nlp, r=pnkfelixbors-2/+2
Remove -Z no-landing-pads flag Since #67502, `-Z no-landing-pads` will cause all attempted unwinds to abort since we don't generate a `try` / `catch`. This previously worked because `__rust_try` was located in libpanic_unwind which is always compiled with `-C panic=unwind`, but `__rust_try` is now directly inline into the crate that uses `catch_unwind`. As such, `-Z no-landing-pads` is now mostly useless and people should use `-C panic=abort` instead.
2020-04-29Auto merge of #71528 - alexcrichton:no-more-bitcode, r=nnethercotebors-65/+7
Store LLVM bitcode in object files, not compressed This commit is an attempted resurrection of #70458 where LLVM bitcode emitted by rustc into rlibs is stored into object file sections rather than in a separate file. The main rationale for doing this is that when rustc emits bitcode it will no longer use a custom compression scheme which makes it both easier to interoperate with existing tools and also cuts down on compile time since this compression isn't happening. The blocker for this in #70458 turned out to be that native linkers didn't handle the new sections well, causing the sections to either trigger bugs in the linker or actually end up in the final linked artifact. This commit attempts to address these issues by ensuring that native linkers ignore the new sections by inserting custom flags with module-level inline assembly. Note that this does not currently change the API of the compiler at all. The pre-existing `-C bitcode-in-rlib` flag is co-opted to indicate whether the bitcode should be present in the object file or not. Finally, note that an important consequence of this commit, which is also one of its primary purposes, is to enable rustc's `-Clto` bitcode loading to load rlibs produced with `-Clinker-plugin-lto`. The goal here is that when you're building with LTO Cargo will tell rustc to skip codegen of all intermediate crates and only generate LLVM IR. Today rustc will generate both object code and LLVM IR, but the object code is later simply thrown away, wastefully.
2020-04-29Store LLVM bitcode in object files, not compressedAlex Crichton-65/+7
This commit is an attempted resurrection of #70458 where LLVM bitcode emitted by rustc into rlibs is stored into object file sections rather than in a separate file. The main rationale for doing this is that when rustc emits bitcode it will no longer use a custom compression scheme which makes it both easier to interoperate with existing tools and also cuts down on compile time since this compression isn't happening. The blocker for this in #70458 turned out to be that native linkers didn't handle the new sections well, causing the sections to either trigger bugs in the linker or actually end up in the final linked artifact. This commit attempts to address these issues by ensuring that native linkers ignore the new sections by inserting custom flags with module-level inline assembly. Note that this does not currently change the API of the compiler at all. The pre-existing `-C bitcode-in-rlib` flag is co-opted to indicate whether the bitcode should be present in the object file or not. Finally, note that an important consequence of this commit, which is also one of its primary purposes, is to enable rustc's `-Clto` bitcode loading to load rlibs produced with `-Clinker-plugin-lto`. The goal here is that when you're building with LTO Cargo will tell rustc to skip codegen of all intermediate crates and only generate LLVM IR. Today rustc will generate both object code and LLVM IR, but the object code is later simply thrown away, wastefully.
2020-04-29Remove Session::no_landing_pads()Amanieu d'Antras-2/+2
2020-04-28Use the query system to allocate.Camille GILLOT-9/+6
2020-04-27Change return type of `entry_fn` query to return a `LocalDefId`marmeladema-3/+3
2020-04-27Disable localization for all linkersVadim Petrochenkov-1/+16
2020-04-26codegen_llvm: Simplify logic for relaxing PIC into PIEVadim Petrochenkov-5/+1
2020-04-26rustc_target: Stop using "string typing" for relocation modelsVadim Petrochenkov-11/+2
Introduce `enum RelocModel` instead.
2020-04-26Rollup merge of #71392 - ecstatic-morse:body-predecessor-cache-arc, ↵Dylan DPC-1/+1
r=nikomatsakis Don't hold the predecessor cache lock longer than necessary #71044 returns a `LockGuard` with the predecessor cache to callers of `Body::predecessors`. As a result, the lock around the predecessor cache could be held for an arbitrarily long time. This PR uses reference counting for ownership of the predecessor cache, meaning the lock is only ever held within `PredecessorCache::compute`. Checking this API for potential sources of deadlock is much easier now, since we no longer have to consider its consumers, only its internals. This required removing `predecessors_for`, since there is no equivalent to `LockGuard::map` for `Arc` and `Rc`. I believe this could be emulated with `owning_ref::{Arc,Rc}Ref`, but I don't think it's necessary. Also, we continue to return an opaque type from `Body::predecessors` with the lifetime of the `Body`, not `'static`. This depends on #71044. Only the last two commits are new. r? @nikomatsakis
2020-04-25Rollup merge of #71544 - cuviper:filter_map_next, r=Mark-SimulacrumDylan DPC-5/+1
Replace filter_map().next() calls with find_map() These are semantically the same, but `find_map()` is more concise.
2020-04-25Rollup merge of #71364 - Amanieu:zprofile_compiler_builtins, r=cramertjDylan DPC-5/+18
Ignore -Zprofile when building compiler_builtins #70846 made the `compiler_builtins` crate ignore the default codegen-units setting and instead always split each function into a different codegen unit. This unfortunately breaks `-Zprofile` which requires a single codegen unit per crate (see #71283). You can notice this when building with `cargo -Zbuild-std` and `RUSTFLAGS` containing `-Zprofile`. This PR works around this issue by just ignoring `-Zprofile` for the `compiler-builtins` crate.
2020-04-24Replace filter_map().next() calls with find_map()Josh Stone-5/+1
These are semantically the same, but `find_map()` is more concise.
2020-04-24Auto merge of #70820 - spastorino:replace-fragile-erroneous-const-sys, r=oli-obkbors-0/+14
Replace fragile erroneous const sys Closes #67191 r? @oli-obk
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-26 06:01:04 +0000