about summary refs log tree commit diff
path: root/src/rustllvm
AgeCommit message (Collapse)AuthorLines
2020-09-09Move `rustllvm` into `rustc_llvm`Vadim Petrochenkov-3857/+0
2020-08-22Write coverage filenames in Version3 formatJosh Stone-7/+9
2020-08-14Auto merge of #75416 - richkadel:llvm-coverage-map-gen-5.3, r=richkadelbors-0/+5
LLVM IR coverage encoding aligns closer to Clang's I found some areas for improvement while attempting to debug the SegFault issue when running rust programs compiled using MSVC, with coverage instrumentation. I discovered that LLVM's coverage writer was generating incomplete function name variable names (that's not a typo: the name of the variable that holds a function name). The existing implementation used one-up numbers to distinguish variables, and correcting the names did not fix the MSVC coverage bug, but the fix in this PR makes the names and resulting LLVM IR easier to follow and more consistent with Clang's implementation. I also changed the way the `-Zinstrument-coverage` option is supported in symbol_export.rs. The original implementation was incorrect, and the corrected version matches the handling for `-Zprofile-generate`, as it turns out. (An argument could be made that maybe `-Zinstrument-coverage` should automatically enable `-Cprofile-generate`. In fact, if `-Cprofile-generate` is analagous to Clang's `-fprofile-generate`, as some documentation implies, Clang always requires this flag for its implementation of source-based code coverage. This would require a little more validation, and if implemented, would probably require updating some of the user-facing messages related to `-Cprofile-generate` to not be so specific to the PGO use case.) None of these changes fixed the MSVC coverage problems, but they should still be welcome improvements. Lastly, I added some additional FIXME comments in instrument_coverage.rs describing issues I found with the generated LLVM IR that would be resolved if the coverage instrumentation is injected with a `Statement` instead of as a new `BasicBlock`. I describe seven advantages of this change, but it requires some discussion before making a change like this. r? @tmandry
2020-08-14LLVM IR coverage encoding aligns closer to Clang'sRich Kadel-0/+5
I found some areas for improvement while attempting to debug the SegFault issue when running rust programs compiled using MSVC, with coverage instrumentation. I discovered that LLVM's coverage writer was generating incomplete function name variable names (that's not a typo: the name of the variable that holds a function name). The existing implementation used one-up numbers to distinguish variables, and correcting the names did not fix the MSVC coverage bug, but the fix in this PR makes the names and resulting LLVM IR easier to follow and more consistent with Clang's implementation. I also changed the way the `-Zinstrument-coverage` option is supported in symbol_export.rs. The original implementation was incorrect, and the corrected version matches the handling for `-Zprofile-generate`, as it turns out. (An argument could be made that maybe `-Zinstrument-coverage` should automatically enable `-Cprofile-generate`. In fact, if `-Cprofile-generate` is analagous to Clang's `-fprofile-generate`, as some documentation implies, Clang always requires this flag for its implementation of source-based code coverage. This would require a little more validation, and if implemented, would probably require updating some of the user-facing messages related to `-Cprofile-generate` to not be so specific to the PGO use case.) None of these changes fixed the MSVC coverage problems, but they should still be welcome improvements. Lastly, I added some additional FIXME comments in instrument_coverage.rs describing issues I found with the generated LLVM IR that would be resolved if the coverage instrumentation is injected with a `Statement` instead of as a new `BasicBlock`. I describe seven advantages of this change, but it requires some discussion before making a change like this.
2020-08-12Remove ArchiveKind::OtherMark Rousskov-1/+0
Also unused since introduction in #35174
2020-08-12Remove CodeGenOptLevel::OtherMark Rousskov-1/+0
Also introduced in #35174, and immediately unused.
2020-08-12Remove AsmDialect::OtherMark Rousskov-1/+0
Added in #35174, this was already unused (and new uses have not been introduced since then).
2020-08-12Remove FileType::OtherMark Rousskov-1/+0
Added in #35174, this was already unused (and new uses have not been introduced since then).
2020-08-11Remove SynchronizationScope::OtherMark Rousskov-1/+0
Added in b7615389978eae2ae9f3cba9a776fd8da3f743ca, it started out already unused.
2020-07-25Fixed coverage map issues; better aligned with LLVM APIsRich Kadel-59/+7
Found some problems with the coverage map encoding when testing with more than one counter per function. While debugging, I realized some better ways to structure the Rust implementation of the coverage mapping generator. I refactored somewhat, resulting in less code overall, expanded coverage of LLVM Coverage Map capabilities, and much closer alignment with LLVM data structures, APIs, and naming. This should be easier to follow and easier to maintain.
2020-07-17Generating the coverage mapRich Kadel-1/+117
rustc now generates the coverage map and can support (limited) coverage report generation, at the function level. Example: $ BUILD=$HOME/rust/build/x86_64-unknown-linux-gnu $ $BUILD/stage1/bin/rustc -Zinstrument-coverage \ $HOME/rust/src/test/run-make-fulldeps/instrument-coverage/main.rs $ LLVM_PROFILE_FILE="main.profraw" ./main called $ $BUILD/llvm/bin/llvm-profdata merge -sparse main.profraw -o main.profdata $ $BUILD/llvm/bin/llvm-cov show --instr-profile=main.profdata main 1| 1|pub fn will_be_called() { 2| 1| println!("called"); 3| 1|} 4| | 5| 0|pub fn will_not_be_called() { 6| 0| println!("should not have been called"); 7| 0|} 8| | 9| 1|fn main() { 10| 1| let less = 1; 11| 1| let more = 100; 12| 1| 13| 1| if less < more { 14| 1| will_be_called(); 15| 1| } else { 16| 1| will_not_be_called(); 17| 1| } 18| 1|}
2020-07-11Rollup merge of #73715 - MaulingMonkey:pr-natvis-tuples, r=AmanieuManish Goregaokar-0/+8
debuginfo: Mangle tuples to be natvis friendly, typedef basic types These changes are meant to unblock rust-lang/rust#70052 "Update hashbrown to 0.8.0" by allowing the use of `tuple<u64, u64>` as a .natvis expression in MSVC style debuggers (MSVC, WinDbg, CDB, etc.) * f8eb81b does the actual mangling of `(u64, u64)` -> `tuple<u64, 64>` * 24a728a allows `u64` to resolve (fixing `$T1` / `$T2` when used to visualize `HashMap<u64, u64, ...>`)
2020-06-25Prepare for LLVM 11Josh Stone-43/+134
2020-06-24debuginfo: Define int/float types in terms of MSVC-recognized types.MaulingMonkey-0/+8
PDB debug information doesn't appear to be emitted for basic types. By defining u32 as a typedef for unsigned __int32 when targeting MSVC, we allow CDB and other debuggers to recognize "u32" as a type/expression. This in turn unblocks rust-lang#70052 "Update hashbrown to 0.8.0" by allowing $T1 ..= $T3 to resolve, which would otherwise fail to resolve when builtin types fail to parse.
2020-06-19Rollup merge of #73347 - tmiasko:incompatible-sanitizers, r=nikicManish Goregaokar-6/+7
Diagnose use of incompatible sanitizers Emit an error when incompatible sanitizer are configured through command line options. Previously the last one configured prevailed and others were silently ignored. Additionally use a set to represent configured sanitizers, making it possible to enable multiple sanitizers at once. At least in principle, since currently all of them are considered to be incompatible with others.
2020-06-19Rollup merge of #73011 - richkadel:llvm-count-from-mir-pass, r=tmandryRalf Jung-0/+6
first stage of implementing LLVM code coverage This PR replaces #70680 (WIP toward LLVM Code Coverage for Rust) since I am re-implementing the Rust LLVM code coverage feature in a different part of the compiler (in MIR pass(es) vs AST). This PR updates rustc with `-Zinstrument-coverage` option that injects the llvm intrinsic `instrprof.increment()` for code generation. This initial version only injects counters at the top of each function, and does not yet implement the required coverage map. Upcoming PRs will add the coverage map, and add more counters and/or counter expressions for each conditional code branch. Rust compiler MCP https://github.com/rust-lang/compiler-team/issues/278 Relevant issue: #34701 - Implement support for LLVMs code coverage instrumentation ***[I put together some development notes here, under a separate branch.](https://github.com/richkadel/rust/blob/cfa0b21d34ee64e4ebee226101bd2ef0c6757865/src/test/codegen/coverage-experiments/README-THIS-IS-TEMPORARY.md)***
2020-06-17add blank line bw sections asrar-1/+1
Separate target features from rust ones with a blank line Co-authored-by: Josh Stone <cuviper@gmail.com>
2020-06-16trim whitespaceroot-3/+3
2020-06-16break long line for formattingroot-1/+5
2020-06-16add header for rust specific featureroot-2/+1
2020-06-15[WIP] injects llvm intrinsic instrprof.increment for coverage reportsRich Kadel-0/+6
This initial version only injects counters at the top of each function. Rust Coverage will require injecting additional counters at each conditional code branch.
2020-06-14Add rust features to print target featuresasrar-0/+3
`crt-static` is a rust specific target feature that's absent from llvm feature table, adding it there.
2020-06-14Diagnose use of incompatible sanitizersTomasz Miąsko-6/+7
Emit an error when incompatible sanitizer are configured through command line options. Previously the last one configured prevailed and others were silently ignored. Additionally use a set to represent configured sanitizers, making it possible to enable multiple sanitizers at once. At least in principle, since currently all of them are considered to be incompatible with others.
2020-06-12Auto merge of #69478 - avr-rust:avr-support-upstream, r=jonas-schievinkbors-0/+7
Enable AVR as a Tier 3 target upstream Tracking issue: #44052. Things intentionally left out of the initial upstream: * The `target_cpu` flag I have made the cleanup suggestions by @jplatte and @jplatte in https://github.com/avr-rust/rust/commit/043550d9db0582add42e5837f636f61acb26b915. Anybody feel free to give the branch a test and see how it fares, or make suggestions on the code patch itself.
2020-06-09Handle assembler warnings properlyAmanieu d'Antras-1/+46
2020-06-09[AVR] Add AVR platform supportJake Goulding-0/+7
2020-05-29Improve inline asm error diagnosticsAmanieu d'Antras-4/+27
2020-05-21rustllvm: Fix warnings about unused function parametersVadim Petrochenkov-6/+3
2020-05-18Implement asm! codegenAmanieu d'Antras-0/+6
2020-05-17Auto merge of #72248 - petrochenkov:codemodel, r=Amanieubors-5/+7
Cleanup and document `-C code-model` r? @Amanieu
2020-05-16rustc_target: Stop using "string typing" for code modelsVadim Petrochenkov-5/+7
Introduce `enum CodeModel` instead.
2020-05-14Consistently use LLVM lifetime markers during codegenTomasz Miąsko-2/+2
Ensure that inliner inserts lifetime markers if they have been emitted during codegen. Otherwise if allocas from inlined functions are merged together, lifetime markers from one function might invalidate load & stores performed by the other one.
2020-05-09Rollup merge of #71234 - maurer:init-array, r=cuviperRalf Jung-1/+3
rustllvm: Use .init_array rather than .ctors LLVM TargetMachines default to using the (now-legacy) .ctors representation of init functions. Mixing .ctors and .init_array representations can cause issues when linking with lld. This happens in practice for: * Our profiling runtime which is currently implicitly built with .init_array since it is built by clang, which sets this field. * External C/C++ code that may be linked into the same process. Fixes: #71233
2020-04-29Auto merge of #71528 - alexcrichton:no-more-bitcode, r=nnethercotebors-0/+28
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-29Use .init_array rather than .ctorsMatthew Maurer-1/+3
LLVM TargetMachines default to using the (now-legacy) .ctors representation of init functions. Mixing .ctors and .init_array representations can cause issues when linking with lld. This happens in practice for: * Our profiling runtime which is currently implicitly built with .init_array since it is built by clang, which sets this field. * External C/C++ code that may be linked into the same process. To support legacy systems which may use .ctors, targets may now specify that they use .ctors via the use_ctors attribute which defaults to false. For debugging and manual control, -Z use-ctors-section=yes/no will allow manual override. Fixes: #71233
2020-04-29Store LLVM bitcode in object files, not compressedAlex Crichton-0/+28
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-26codegen_llvm: `RelocMode` -> `RelocModel`Vadim Petrochenkov-9/+9
2020-04-26rustc_target: Stop using "string typing" for relocation modelsVadim Petrochenkov-4/+1
Introduce `enum RelocModel` instead.
2020-04-14Update the minimum external LLVM to 8Josh Stone-45/+2
LLVM 8 was released on March 20, 2019, over a year ago.
2020-04-02Add hash of source files in debug infoArlo Siemsen-2/+27
* Adds either an MD5 or SHA1 hash to the debug info. * Adds new unstable option `-Z src-hash-algorithm` to control the hashing algorithm.
2020-03-19Update CreateMemSet() usage for LLVM 10Nikita Popov-0/+5
2020-03-19Fix timeTraceProfilerInitialize for LLVM 10Nikita Popov-1/+5
2020-03-11librustc_codegen_llvm: Use slices instead of 0-terminated stringsTomasz Miąsko-21/+26
Changed functions: * LLVMRustGetOrInsertFunction * LLVMRustGetNamedValue * LLVMRustBuildCall (removed unused name argument) * LLVMRustInlineAsm * LLVMRustInlineAsmVerify * LLVMRustAppendModuleInlineAsm
2020-03-09Use slices in preference to 0-terminated stringsTomasz Miąsko-59/+87
Additionally whenever possible match C API provided by the LLVM.
2020-03-05Change DIBuilderCreateEnumerator signature to match LLVM 9Tomasz Miąsko-4/+4
No functional changes intended.
2020-03-03Invoke OptimizerLastEPCallbacks in PreLinkThinLTOTomasz Miąsko-2/+10
The default ThinLTO pre-link pipeline does not include optimizer last extension points. Thus, when using the new LLVM pass manager & ThinLTO & sanitizers on any opt-level different from zero, the sanitizer function passes would be omitted from the pipeline. Add optimizer last extensions points manually to the pipeline, but guard registration with stage check in the case this behaviour changes in the future.
2020-02-13Auto merge of #69144 - Dylan-DPC:rollup-apt6zjj, r=Dylan-DPCbors-2/+2
Rollup of 9 pull requests Successful merges: - #68728 (parse: merge `fn` syntax + cleanup item parsing) - #68938 (fix lifetime shadowing check in GATs) - #69057 (expand: misc cleanups and simplifications) - #69108 (Use HirId in TraitCandidate.) - #69125 (Add comment to SGX entry code) - #69126 (miri: fix exact_div) - #69127 (Enable use after scope detection in the new LLVM pass manager) - #69135 (Spelling error "represening" to "representing") - #69141 (Don't error on network failures) Failed merges: r? @ghost
2020-02-13add selfprofiling for new llvm passmanagerAndreas Jonson-1/+64
2020-02-13Enable use after scope detection in the new LLVM pass managerTomasz Miąsko-2/+2
Implementation of 08a1c566a792dcf9657d293155f7ada87746bb65 for the new LLVM pass manager, support for which landed in the meantime.
2020-02-12Rollup merge of #67954 - nikic:new-pm, r=nagisaDylan DPC-1/+251
Support new LLVM pass manager Add support for the new LLVM pass manager behind a `-Z new-llvm-pass-manager=on` option. Both the pre-link optimization and LTO pipelines use the new pass manager. There's some bits that are not supported yet: * `-C passes`. NewPM requires an entirely different way of specifying custom pass pipelines. We should probably expose that functionality, but it doesn't directly map to what `-C passes` does. * NewPM has no support for custom inline parameters right now. We'd have to add upstream support for that first. * NewPM does not support PGO at O0 in LLVM 9 (which is why those tests fail with NewPM enabled). This is supported in LLVM 10. * NewPM does not support MergeFunctions in LLVM 9. I've landed this upstream just before the cut, so we'll be able to re-enable that with LLVM 10. Closes #64289. r? @ghost
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2025-11-08 18:46:46 +0000