| Age | Commit message (Collapse) | Author | Lines |
|
|
|
|
|
|
|
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
|
|
Enable -mergefunc-use-aliases
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 in various ways now.
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.
r? @rkruppe
|
|
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.
|
|
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
|
|
|
|
|
|
|
|
|
|
IntPredicate moved
|
|
|
|
|
|
|
|
Moved common enums to common
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Remove support for building against LLVM 4
With emscripten removed in #55626, we no longer need to support building against LLVM 4.
|
|
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.
|
|
refactor: use shorthand fields
refactor: use shorthand for single fields everywhere (excluding tests).
|
|
|
|
With emscripten removed in #55626, we no longer need to support
building against LLVM 4.
|
|
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.
|
|
While we still have to support LLVM 4.0 for Emscripten, we can
drop checks for LLVM >= 4.0 and < 4.0.
|
|
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
|
|
This reverts commit 3cc8f738d4247a9b475d8e074b621e602ac2b7be.
|
|
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
|
|
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
|
|
|
|
Fix LLVMRustInlineAsmVerify return type mismatch
Fixes https://github.com/rust-lang/rust/issues/54918.
r? @rkruppe
cc @levex
|
|
Cleanup the rest of codegen_llvm
- improve common patterns
- convert string literals with `to_owned`
- remove explicit `return`s
- whitespace & formatting improvements
|
|
|
|
Fixes #54992.
|
|
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
|
|
|
|
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\>
|
|
|
|
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>
|
|
|
|
|
|
This fixes a regression from #53031 where specifying `-C target-cpu=native` is
printing a lot of warnings from LLVM about `native` being an unknown CPU. It
turns out that `native` is indeed an unknown CPU and we have to perform a
mapping to an actual CPU name, but this mapping is only performed in one
location rather than all locations we inform LLVM about the target CPU.
This commit centralizes the mapping of `native` to LLVM's value of the native
CPU, ensuring that all locations we inform LLVM about the `target-cpu` it's
never `native`.
Closes #53322
|
|
|
|
Make LLVM emit assembly comments with -Z asm-comments
Fixes #35741, and makes `-Z asm-comments` actually do something useful.
Before:
```
.section .text.main,"ax",@progbits
.globl main
.p2align 4, 0x90
.type main,@function
main:
.cfi_startproc
pushq %rax
.cfi_def_cfa_offset 16
movslq %edi, %rax
leaq _ZN1t4main17he95a7d4f1843730eE(%rip), %rdi
movq %rsi, (%rsp)
movq %rax, %rsi
movq (%rsp), %rdx
callq _ZN3std2rt10lang_start17h3121da83b2bc3697E
movl %eax, %ecx
movl %ecx, %eax
popq %rcx
.cfi_def_cfa_offset 8
retq
.Lfunc_end8:
.size main, .Lfunc_end8-main
.cfi_endproc
```
After:
```
.section .text.main,"ax",@progbits
.globl main # -- Begin function main
.p2align 4, 0x90
.type main,@function
main: # @main
.cfi_startproc
# %bb.0:
pushq %rax
.cfi_def_cfa_offset 16
movslq %edi, %rax
leaq _ZN1t4main17he95a7d4f1843730eE(%rip), %rdi
movq %rsi, (%rsp) # 8-byte Spill
movq %rax, %rsi
movq (%rsp), %rdx # 8-byte Reload
callq _ZN3std2rt10lang_start17h3121da83b2bc3697E
movl %eax, %ecx
movl %ecx, %eax
popq %rcx
.cfi_def_cfa_offset 8
retq
.Lfunc_end8:
.size main, .Lfunc_end8-main
.cfi_endproc
# -- End function
```
|