about summary refs log tree commit diff
path: root/src/rustllvm
AgeCommit message (Collapse)AuthorLines
2019-11-06Rollup merge of #66062 - smaeul:patch/pic-level, r=estebankMazdak Farrokhzad-0/+4
Configure LLVM module PIC level As of LLVM 9, this is required for 32-bit PowerPC to properly generate PLT references. Previously, only BigPIC was supported; now LLVM supports both BigPIC and SmallPIC, and there is no default value provided.
2019-11-05Rollup merge of #65953 - keystone-enclave:llvm_abiname, r=alexcrichtonPietro Albini-1/+2
Allow specifying LLVM's MCTargetOptions::ABIName in target specification files This addresses #65024, as it allows RISC-V target specification files to set `"llvm-abiname": "lp64d"`. Other languages (read: C) usually expose this codegen parameter under a compiler argument like `-mabi=<XYZ>`.
2019-11-03Configure LLVM module PIC levelSamuel Holland-0/+4
As of LLVM 9, this is required for 32-bit PowerPC to properly generate PLT references. Previously, only BigPIC was supported; now LLVM supports both BigPIC and SmallPIC, and there is no default value provided.
2019-11-02Add FFI bindings for Module::getInstructionCount()Simon Heath-0/+8
Just to make it useable for profiling and such inside rustc itself. It was vaguely useful in https://wiki.alopex.li/WhereRustcSpendsItsTime and I figured I might as well upstream it; I may or may not ever get around to doing more with it (hopefully I will), but it may be useful for others.
2019-10-29Allow specifying key "llvm-abiname" in target specificationGui Andrade-1/+2
This addresses #65024, as it allows RISC-V target specification files to set "llvm-abiname": "lp64d". In general, it is useful for the programmer to be able to set this codegen parameter, which other languages usually expose under a compiler argument like "-mabi=<XYZ>".
2019-07-20Don't link mcjit/interpreter LLVM componentsNikita Popov-6/+0
2019-07-15Don't add extra passes into the function pass managerNikita Popov-0/+17
Exception for specific cases like linting, additional passes should be going into the module pass manager (even if they are function passes). The separate function pass manager is only used for very early optimization passes. Rather than apparending passes to the MPM, use the OptimizerLast and EnabledOnOptLevel0 pass manager builder extension hooks, which allow adding passes directly before finalization (alias canonicalization and name-anon-globals). The main effect and purpose of this change is to add sanitizer passes at the end of the pipeline, which is where they belong. In LLVM 9 the address sanitizer can't be used as a pass in the early function pass manager, because it has a dependence on a module-level analysis pass.
2019-07-13Update CPU printing for SubtargetSubTypeKVNikita Popov-4/+4
CPUs now use SubtargetSubTypeKV rather than SubtargetFeatureKV and no longer have a description.
2019-07-09Pass type to byval attributesNikita Popov-0/+22
2019-07-09Pass GUIDPreservedSymbols to thinLTOResolvePrevailingInIndex()Nikita Popov-1/+4
2019-04-26Limit internalization in LLVM 8 ThinLTOJosh Stone-1/+4
2019-04-18Remove the unused LLVMRustIsRustLLVMJosh Stone-8/+0
2019-04-06Auto merge of #59710 - alexcrichton:llvm-9-compat, r=sanxiynbors-20/+39
rustc: Start implementing compat with LLVM 9 This commit doesn't actually migrate to LLVM 9, but it brings our own C++ bindings in line with LLVM 9 and able to compile against tip of tree. The changes made were: * The `MainSubprogram` flag for debuginfo moved between flag types. * Iteration of archive members was tweaked slightly and we have to construct the two iterators before constructing the returned `RustArchiveIterator` value. * The `getOrInsertFunction` binding now returns a wrapper which we use `getCallee()` on to get the value we're interested in.
2019-04-05Show better errors for LLVM IR outputJosh Stone-2/+9
I was trying to output LLVM IR directly to the console: $ rustc hello.rs --emit=llvm-ir -o /dev/stdout LLVM ERROR: IO failure on output stream: Bad file descriptor Now `LLVMRustPrintModule` returns an error, and we print: error: failed to write LLVM IR to /dev/stdout.hello.7rcbfp3g-cgu.0.rcgu.ll: Permission denied ... which is more informative.
2019-04-05rustc: Start implementing compat with LLVM 9Alex Crichton-20/+39
This commit doesn't actually migrate to LLVM 9, but it brings our own C++ bindings in line with LLVM 9 and able to compile against tip of tree. The changes made were: * The `MainSubprogram` flag for debuginfo moved between flag types. * Iteration of archive members was tweaked slightly and we have to construct the two iterators before constructing the returned `RustArchiveIterator` value. * The `getOrInsertFunction` binding now returns a wrapper which we use `getCallee()` on to get the value we're interested in.
2019-03-27replace llvm-rebuild-trigger with commit hashAndy Russell-4/+0
2019-03-18Rebase LLVM to 8.0.0 finalJosh Stone-1/+1
2019-02-23Implement ffi_returns_twice attributegnzlbg-0/+3
2019-02-12rustc: Implement incremental "fat" LTOAlex Crichton-4/+4
Currently the compiler will produce an error if both incremental compilation and full fat LTO is requested. With recent changes and the advent of incremental ThinLTO, however, all the hard work is already done for us and it's actually not too bad to remove this error! This commit updates the codegen backend to allow incremental full fat LTO. The semantics are that the input modules to LTO are all produce incrementally, but the final LTO step is always done unconditionally regardless of whether the inputs changed or not. The only real incremental win we could have here is if zero of the input modules changed, but that's so rare it's unlikely to be worthwhile to implement such a code path. cc #57968 cc rust-lang/cargo#6643
2019-01-26Auto merge of #55641 - nagisa:optimize-attr, r=pnkfelixbors-0/+3
Implement optimize(size) and optimize(speed) attributes This PR implements both `optimize(size)` and `optimize(speed)` attributes. While the functionality itself works fine now, this PR is not yet complete: the code might be messy in places and, most importantly, the compiletest must be improved with functionality to run tests with custom optimization levels. Otherwise the new attribute cannot be tested properly. Oh, and not all of the RFC is implemented – attribute propagation is not implemented for example. # TODO * [x] Improve compiletest so that tests can be written; * [x] Assign a proper error number (E9999 currently, no idea how to allocate a number properly); * [ ] Perhaps reduce the duplication in LLVM attribute assignment code…
2019-01-25Set the DICompileUnit emissionKindJosh Stone-2/+23
2019-01-25Rebase to the llvm-project monorepoJosh Stone-9/+93
The new git submodule src/llvm-project is a monorepo replacing src/llvm and src/tools/{clang,lld,lldb}. This also serves as a rebase for these projects to the new 8.x branch from trunk. The src/llvm-emscripten fork is unchanged for now.
2019-01-24Implement optimize(size) and optimize(speed)Simonas Kazlauskas-0/+3
2018-12-25Remove licensesMark Rousskov-50/+0
2018-12-17Auto merge of #56642 - nikic:llvm-6, r=alexcrichtonbors-37/+3
Bump minimum required LLVM version to 6.0 Based on the discussion in #55842, while the overall position of Rust wrt LLVM continues to be contentious, there does seem to be a consensus that there is no need for continued support of LLVM 5. This PR bumps our version requirement to LLVM 6.0 and makes Travis run against that. I hope that this is going to unblock #52694. If I understand correctly, while this issue still exists in LLVM 6, Ubuntu has backported the relevant patch. r? @alexcrichton
2018-12-13Update LLVM submoduleNikita Popov-1/+1
2018-12-09Bump minimum required LLVM version to 6.0Nikita Popov-37/+3
2018-12-03Auto merge of #55010 - tromey:Bug-9224-generic-parameters, r=michaelwoeristerbors-4/+6
Add template parameter debuginfo to generic types This changes debuginfo generation to add template parameters to generic types. With this change the DWARF now has DW_TAG_template_type_param for types, not just for functions, like: <2><40d>: Abbrev Number: 6 (DW_TAG_structure_type) <40e> DW_AT_name : (indirect string, offset: 0x375): Generic<i32> <412> DW_AT_byte_size : 4 <413> DW_AT_alignment : 4 ... <3><41f>: Abbrev Number: 8 (DW_TAG_template_type_param) <420> DW_AT_type : <0x42a> <424> DW_AT_name : (indirect string, offset: 0xa65e): T Closes #9224
2018-11-30Enable -mergefunc-use-aliasesNikita Popov-1/+9
If the Rust LLVM fork is used, enable the -mergefunc-use-aliases flag, which will create aliases for merged functions, rather than inserting a call from one to the other. A number of codegen tests needed to be adjusted, because functions that previously fell below the thunk limit are now being merged. Merging is prevented either using -C no-prepopulate-passes, or by making the functions non-identical. I expect that this is going to break something, somewhere, because it isn't able to deal with aliases properly, but we won't find out until we try :) This fixes #52651.
2018-11-29Add template parameter debuginfo to generic typesTom Tromey-4/+6
This changes debuginfo generation to add template parameters to generic types. With this change the DWARF now has DW_TAG_template_type_param for types, not just for functions, like: <2><40d>: Abbrev Number: 6 (DW_TAG_structure_type) <40e> DW_AT_name : (indirect string, offset: 0x375): Generic<i32> <412> DW_AT_byte_size : 4 <413> DW_AT_alignment : 4 ... <3><41f>: Abbrev Number: 8 (DW_TAG_template_type_param) <420> DW_AT_type : <0x42a> <424> DW_AT_name : (indirect string, offset: 0xa65e): T Closes #9224
2018-11-28Update LLVMNikita Popov-1/+1
In particular to pull in a fix for #56265.
2018-11-25Conditionally compile in only the extra argument.Edd Barrett-7/+4
2018-11-25Make Rustc build with LLVM trunk.Edd Barrett-0/+7
2018-11-25Handle some renamed ThinLTO functionsAlex Crichton-0/+8
2018-11-11Auto merge of #55698 - nikic:remove-llvm-4-support, r=alexcrichtonbors-200/+3
Remove support for building against LLVM 4 With emscripten removed in #55626, we no longer need to support building against LLVM 4.
2018-11-10Auto merge of #55626 - nikic:update-emscripten, r=alexcrichtonbors-1/+1
Update emscripten This updates emscripten to 1.38.15, which is based on LLVM 6.0.1 and would allow us to drop code for handling LLVM 4. The main issue I ran into is that exporting statics through `EXPORTED_FUNCTIONS` no longer works. As far as I understand exporting non-functions doesn't really make sense under emscripten anyway, so I've modified the symbol export code to not even try. Closes #52323.
2018-11-08Rollup merge of #55633 - nikic:memcpy-align, r=nagisaMark Rousskov-0/+34
Support memcpy/memmove with differing src/dst alignment If LLVM 7 is used, generate memcpy/memmove with differing src/dst alignment. I've added new FFI functions to construct these through the builder API, which is more convenient than dealing with differing intrinsic signatures depending on the LLVM version. Fixes #49740.
2018-11-05Remove support for building against LLVM 4Nikita Popov-200/+3
With emscripten removed in #55626, we no longer need to support building against LLVM 4.
2018-11-04Support memcpy/memmove with differing src/dst alignmentNikita Popov-0/+34
If LLVM 7 is used, generate memcpy/memmove with differing src/dst alignment. I've added new FFI functions to construct these through the builder API, which is more convenient than dealing with differing intrinsic signatures depending on the LLVM version.
2018-11-04Update llvm-emscriptenNikita Popov-1/+1
This updates emscripten to version 1.38.15, which is based on LLVM 6.0.1.
2018-11-01Remove checks for LLVM < 4.0Nikita Popov-183/+0
While we still have to support LLVM 4.0 for Emscripten, we can drop checks for LLVM >= 4.0 and < 4.0.
2018-10-30Fix DWARF generation for enumsTom Tromey-2/+47
The DWARF generated for Rust enums was always somewhat unusual. Rather than using DWARF constructs directly, it would emit magic field names like "RUST$ENCODED$ENUM$0$Name" and "RUST$ENUM$DISR". Since PR #45225, though, even this has not worked -- the ad hoc scheme was not updated to handle the wider variety of niche-filling layout optimizations now available. This patch changes the generated DWARF to use the standard tags meant for this purpose; namely, DW_TAG_variant and DW_TAG_variant_part. The patch to implement this went in to LLVM 7. In order to work with older versions of LLVM, and because LLVM doesn't do anything here for PDB, the existing code is kept as a fallback mode. Support for this DWARF is in the Rust lldb and in gdb 8.2. Closes #32920 Closes #32924 Closes #52762 Closes #53153
2018-10-23Revert "rustc: Fix (again) simd vectors by-val in ABI"Alex Crichton-189/+0
This reverts commit 3cc8f738d4247a9b475d8e074b621e602ac2b7be.
2018-10-20Rollup merge of #55073 - alexcrichton:demote-simd, r=nagisaManish Goregaokar-0/+189
The issue of passing around SIMD types as values between functions has seen [quite a lot] of [discussion], and although we thought [we fixed it][quite a lot] it [wasn't]! This PR is a change to rustc to, again, try to fix this issue. The fundamental problem here remains the same, if a SIMD vector argument is passed by-value in LLVM's function type, then if the caller and callee disagree on target features a miscompile happens. We solve this by never passing SIMD vectors by-value, but LLVM will still thwart us with its argument promotion pass to promote by-ref SIMD arguments to by-val SIMD arguments. This commit is an attempt to thwart LLVM thwarting us. We, just before codegen, will take yet another look at the LLVM module and demote any by-value SIMD arguments we see. This is a very manual attempt by us to ensure the codegen for a module keeps working, and it unfortunately is likely producing suboptimal code, even in release mode. The saving grace for this, in theory, is that if SIMD types are passed by-value across a boundary in release mode it's pretty unlikely to be performance sensitive (as it's already doing a load/store, and otherwise perf-sensitive bits should be inlined). The implementation here is basically a big wad of C++. It was largely copied from LLVM's own argument promotion pass, only doing the reverse. In local testing this... Closes #50154 Closes #52636 Closes #54583 Closes #55059 [quite a lot]: https://github.com/rust-lang/rust/pull/47743 [discussion]: https://github.com/rust-lang/rust/issues/44367 [wasn't]: https://github.com/rust-lang/rust/issues/50154
2018-10-19rustc: Fix (again) simd vectors by-val in ABIAlex Crichton-0/+189
The issue of passing around SIMD types as values between functions has seen [quite a lot] of [discussion], and although we thought [we fixed it][quite a lot] it [wasn't]! This PR is a change to rustc to, again, try to fix this issue. The fundamental problem here remains the same, if a SIMD vector argument is passed by-value in LLVM's function type, then if the caller and callee disagree on target features a miscompile happens. We solve this by never passing SIMD vectors by-value, but LLVM will still thwart us with its argument promotion pass to promote by-ref SIMD arguments to by-val SIMD arguments. This commit is an attempt to thwart LLVM thwarting us. We, just before codegen, will take yet another look at the LLVM module and demote any by-value SIMD arguments we see. This is a very manual attempt by us to ensure the codegen for a module keeps working, and it unfortunately is likely producing suboptimal code, even in release mode. The saving grace for this, in theory, is that if SIMD types are passed by-value across a boundary in release mode it's pretty unlikely to be performance sensitive (as it's already doing a load/store, and otherwise perf-sensitive bits should be inlined). The implementation here is basically a big wad of C++. It was largely copied from LLVM's own argument promotion pass, only doing the reverse. In local testing this... Closes #50154 Closes #52636 Closes #54583 Closes #55059 [quite a lot]: https://github.com/rust-lang/rust/pull/47743 [discussion]: https://github.com/rust-lang/rust/issues/44367 [wasn't]: https://github.com/rust-lang/rust/issues/50154
2018-10-12exit with status code 101 on fatal LLVM errorAndy Russell-0/+24
Fixes #54992.
2018-10-11Support for disabling the PLT on ELF targetsGabriel Majeri-0/+3
Disable the PLT where possible to improve performance for indirect calls into shared libraries. This optimization is enabled by default where possible. - Add the `NonLazyBind` attribute to `rustllvm`: This attribute informs LLVM to skip PLT calls in codegen. - Disable PLT unconditionally: Apply the `NonLazyBind` attribute on every function. - Only enable no-plt when full relro is enabled: Ensures we only enable it when we have linker support. - Add `-Z plt` as a compiler option
2018-09-28Auto merge of #54568 - levex:issue-54130, r=nagisabors-0/+5
codegen_llvm: check inline assembly constraints with LLVM ---%<--- Hey all, As issue #54130 highlights, constraints are not checked and passing bad constraints to LLVM can crash it since a `Verify()` call is placed inside an assertion (see: `src/llvm/lib/IR/InlineAsm.cpp:39`). As this is my first PR to the Rust compiler (woot! :tada:), there might be better ways of achieving this result. In particular, I am not too happy about generating an error in codegen; it would be much nicer if we did it earlier. However, @rkruppe [noted on IRC](https://botbot.me/mozilla/rustc/2018-09-25/?msg=104791581&page=1) that this should be fine for an unstable feature and a much better solution than the _status quo_, which is an ICE. Thanks! --->%--- LLVM provides a way of checking whether the constraints and the actual inline assembly make sense. This commit introduces a check before emitting code for the inline assembly. If LLVM rejects the inline assembly (or its constraints), then the compiler emits an error E0668 ("malformed inline assembly"). Fixes: #54130 Signed-off-by: Levente Kurusa \<lkurusa@acm.org\>
2018-09-26add -Z emit-stack-sizesJorge Aparicio-1/+4
2018-09-25codegen_llvm: check inline assembly constraints with LLVMLevente Kurusa-0/+5
LLVM provides a way of checking whether the constraints and the actual inline assembly make sense. This commit introduces a check before emitting code for the inline assembly. If LLVM rejects the inline assembly (or its constraints), then the compiler emits an error E0668 ("malformed inline assembly"). Signed-off-by: Levente Kurusa <lkurusa@acm.org>