about summary refs log tree commit diff
path: root/src/test/codegen
AgeCommit message (Collapse)AuthorLines
2018-09-22add codegen testJorge Aparicio-0/+23
2018-08-31Restrict most uses of `const_fn` to `min_const_fn`Oliver Schneider-1/+1
2018-08-28Use partial but correct vtable layoutOliver Schneider-2/+2
2018-08-21Auto merge of #53080 - hermord:rc-opt, r=alexcrichtonbors-0/+21
Change `Rc::inc_{weak,strong}` to better hint optimization to LLVM As discussed in #13018, `Rc::inc_strong` and `Rc::inc_weak` are changed to allow compositions of `clone` and `drop` to be better optimized. Almost entirely as in [this comment](https://github.com/rust-lang/rust/issues/13018#issuecomment-408642184), except that `abort` on zero is added so that a `drop(t.clone())` does not produce a zero check followed by conditional deallocation. This is different from #21418 in that it doesn't rely on `assume`, avoiding the prohibitive compilation slowdown. [Before and after IR](https://gist.github.com/hermord/266e55451b7fe0bb8caa6e35d17c86e1).
2018-08-20Added explicit optimization flag to testDmytro Shynkevych-0/+2
2018-08-20Renamed test to match actual issue numberDmytro Shynkevych-0/+0
2018-08-19Added testDmytro Shynkevych-0/+19
2018-08-19Auto merge of #52972 - RalfJung:from_raw_parts_align, r=alexcrichtonbors-0/+3
debug_assert to ensure that from_raw_parts is only used properly aligned This does not help nearly as much as I would hope because everybody uses the distributed libstd which is compiled without debug assertions. For this reason, I am not sure if this is even worth it. OTOH, this would have caught the misalignment fixed by https://github.com/rust-lang/rust/issues/42789 *if* there had been any tests actually using ZSTs with alignment >1 (we have a CI runner which has debug assertions in libstd enabled), and it seems to currently [fail in the rg testsuite](https://ci.appveyor.com/project/rust-lang/rust/build/1.0.8403/job/v7dfdcgn8ay5j6sb). So maybe it is worth it, after all. I have seen the attribute `#[rustc_inherit_overflow_checks]` in some places, does that make it so that the *caller's* debug status is relevant? Is there a similar attribute for `debug_assert!`? That could even subsume `rustc_inherit_overflow_checks`: Something like `rustc_inherit_debug_flag` could affect *all* places that change the generated code depending on whether we are in debug or release mode. In fact, given that we have to keep around the MIR for generic functions anyway, is there ever a reason *not* to handle the debug flag that way? I guess currently we apply debug flags like `cfg` so this is dropped early during the MIR pipeline? EDIT: I learned from @eddyb that because of how `debug_assert!` works, this is not realistic. Well, we could still have it for the rustc CI runs and then maybe, eventually, when libstd gets compiled client-side and there is both a debug and a release build... then this will also benefit users.^^
2018-08-12Do not generate assumes for plain integer castsSimonas Kazlauskas-0/+29
2018-08-09Relax the target-cpu-on-function codegen test so it just checks for presence ↵Michael Woerister-2/+1
of the attribute.
2018-08-08Address review comments for #53031 and fix some merge fallout.Michael Woerister-2/+4
2018-08-07Annotate functions in LLVM with target-cpu, same as Clang does.Michael Woerister-0/+28
2018-08-07Add test case for omitting dllimport during cross-lang LTO.Michael Woerister-0/+23
2018-08-07Auto merge of #51007 - AstralSorcerer:master, r=nagisabors-3/+3
Make globals with private linkage unnamed. Fixes #50862. cc @oli-obk @nagisa
2018-08-06inore some codegen tests when debug assertions are enabledRalf Jung-0/+3
2018-08-01Rollup merge of #52908 - lnicola:vec-truncate-opt, r=alexcrichtonPietro Albini-0/+21
Use SetLenOnDrop in Vec::truncate() This avoids a redundant length check in some cases when calling `Vec::truncate` or `Vec::clear`. Fixes #51802 Note that the generated code still seems suboptimal. I tested with the following functions: ```rust #[no_mangle] pub extern fn foo(x: &mut Vec<u8>) { x.clear(); } #[no_mangle] pub extern fn bar(x: &mut Vec<u8>) { x.truncate(5); } #[no_mangle] pub extern fn baz(x: &mut Vec<u8>, n: usize) { x.truncate(n); } #[no_mangle] pub extern fn foo_string(x: &mut Vec<String>) { x.clear(); } #[no_mangle] pub extern fn bar_string(x: &mut Vec<String>) { x.truncate(5); } #[no_mangle] pub extern fn baz_string(x: &mut Vec<String>, n: usize) { x.truncate(n); } ``` <details> <summary>Old output</summary> ```asm 00000000000460a0 <foo>: 460a0: 48 83 7f 10 00 cmpq $0x0,0x10(%rdi) 460a5: 74 08 je 460af <foo+0xf> 460a7: 48 c7 47 10 00 00 00 movq $0x0,0x10(%rdi) 460ae: 00 460af: c3 retq 00000000000460b0 <bar>: 460b0: 48 83 7f 10 06 cmpq $0x6,0x10(%rdi) 460b5: 72 08 jb 460bf <bar+0xf> 460b7: 48 c7 47 10 05 00 00 movq $0x5,0x10(%rdi) 460be: 00 460bf: c3 retq 00000000000460c0 <baz>: 460c0: 48 39 77 10 cmp %rsi,0x10(%rdi) 460c4: 76 04 jbe 460ca <baz+0xa> 460c6: 48 89 77 10 mov %rsi,0x10(%rdi) 460ca: c3 retq 460cb: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1) 00000000000460d0 <foo_string>: 460d0: 41 57 push %r15 460d2: 41 56 push %r14 460d4: 53 push %rbx 460d5: 48 8b 47 10 mov 0x10(%rdi),%rax 460d9: 48 85 c0 test %rax,%rax 460dc: 74 4a je 46128 <foo_string+0x58> 460de: 49 89 fe mov %rdi,%r14 460e1: 48 8b 0f mov (%rdi),%rcx 460e4: 48 8d 14 40 lea (%rax,%rax,2),%rdx 460e8: 48 8d 58 ff lea -0x1(%rax),%rbx 460ec: 4c 8d 3c d1 lea (%rcx,%rdx,8),%r15 460f0: 49 83 c7 f0 add $0xfffffffffffffff0,%r15 460f4: 66 2e 0f 1f 84 00 00 nopw %cs:0x0(%rax,%rax,1) 460fb: 00 00 00 460fe: 66 90 xchg %ax,%ax 46100: 49 89 5e 10 mov %rbx,0x10(%r14) 46104: 49 8b 37 mov (%r15),%rsi 46107: 48 85 f6 test %rsi,%rsi 4610a: 74 0e je 4611a <foo_string+0x4a> 4610c: 49 8b 7f f8 mov -0x8(%r15),%rdi 46110: ba 01 00 00 00 mov $0x1,%edx 46115: e8 a6 e9 ff ff callq 44ac0 <__rust_dealloc@plt> 4611a: 48 83 c3 ff add $0xffffffffffffffff,%rbx 4611e: 49 83 c7 e8 add $0xffffffffffffffe8,%r15 46122: 48 83 fb ff cmp $0xffffffffffffffff,%rbx 46126: 75 d8 jne 46100 <foo_string+0x30> 46128: 5b pop %rbx 46129: 41 5e pop %r14 4612b: 41 5f pop %r15 4612d: c3 retq 4612e: 66 90 xchg %ax,%ax 0000000000046130 <bar_string>: 46130: 41 57 push %r15 46132: 41 56 push %r14 46134: 53 push %rbx 46135: 4c 8b 7f 10 mov 0x10(%rdi),%r15 46139: 49 83 ff 06 cmp $0x6,%r15 4613d: 72 49 jb 46188 <bar_string+0x58> 4613f: 49 89 fe mov %rdi,%r14 46142: 48 8b 07 mov (%rdi),%rax 46145: 4b 8d 0c 7f lea (%r15,%r15,2),%rcx 46149: 48 8d 1c c8 lea (%rax,%rcx,8),%rbx 4614d: 48 83 c3 f0 add $0xfffffffffffffff0,%rbx 46151: 66 2e 0f 1f 84 00 00 nopw %cs:0x0(%rax,%rax,1) 46158: 00 00 00 4615b: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1) 46160: 49 83 c7 ff add $0xffffffffffffffff,%r15 46164: 4d 89 7e 10 mov %r15,0x10(%r14) 46168: 48 8b 33 mov (%rbx),%rsi 4616b: 48 85 f6 test %rsi,%rsi 4616e: 74 0e je 4617e <bar_string+0x4e> 46170: 48 8b 7b f8 mov -0x8(%rbx),%rdi 46174: ba 01 00 00 00 mov $0x1,%edx 46179: e8 42 e9 ff ff callq 44ac0 <__rust_dealloc@plt> 4617e: 48 83 c3 e8 add $0xffffffffffffffe8,%rbx 46182: 49 83 ff 05 cmp $0x5,%r15 46186: 77 d8 ja 46160 <bar_string+0x30> 46188: 5b pop %rbx 46189: 41 5e pop %r14 4618b: 41 5f pop %r15 4618d: c3 retq 4618e: 66 90 xchg %ax,%ax 0000000000046190 <baz_string>: 46190: 41 57 push %r15 46192: 41 56 push %r14 46194: 41 54 push %r12 46196: 53 push %rbx 46197: 50 push %rax 46198: 4c 8b 67 10 mov 0x10(%rdi),%r12 4619c: 49 39 f4 cmp %rsi,%r12 4619f: 76 46 jbe 461e7 <baz_string+0x57> 461a1: 49 89 f6 mov %rsi,%r14 461a4: 49 89 ff mov %rdi,%r15 461a7: 48 8b 07 mov (%rdi),%rax 461aa: 4b 8d 0c 64 lea (%r12,%r12,2),%rcx 461ae: 48 8d 1c c8 lea (%rax,%rcx,8),%rbx 461b2: 48 83 c3 f0 add $0xfffffffffffffff0,%rbx 461b6: 66 2e 0f 1f 84 00 00 nopw %cs:0x0(%rax,%rax,1) 461bd: 00 00 00 461c0: 49 83 c4 ff add $0xffffffffffffffff,%r12 461c4: 4d 89 67 10 mov %r12,0x10(%r15) 461c8: 48 8b 33 mov (%rbx),%rsi 461cb: 48 85 f6 test %rsi,%rsi 461ce: 74 0e je 461de <baz_string+0x4e> 461d0: 48 8b 7b f8 mov -0x8(%rbx),%rdi 461d4: ba 01 00 00 00 mov $0x1,%edx 461d9: e8 e2 e8 ff ff callq 44ac0 <__rust_dealloc@plt> 461de: 48 83 c3 e8 add $0xffffffffffffffe8,%rbx 461e2: 4d 39 f4 cmp %r14,%r12 461e5: 77 d9 ja 461c0 <baz_string+0x30> 461e7: 48 83 c4 08 add $0x8,%rsp 461eb: 5b pop %rbx 461ec: 41 5c pop %r12 461ee: 41 5e pop %r14 461f0: 41 5f pop %r15 461f2: c3 retq 461f3: 90 nop 461f4: 66 2e 0f 1f 84 00 00 nopw %cs:0x0(%rax,%rax,1) 461fb: 00 00 00 461fe: 66 90 xchg %ax,%ax ``` </details> <details> <summary>New output</summary> ```asm 0000000000084d10 <foo>: 84d10: 48 c7 47 10 00 00 00 movq $0x0,0x10(%rdi) 84d17: 00 84d18: c3 retq 84d19: 0f 1f 80 00 00 00 00 nopl 0x0(%rax) 0000000000084d20 <bar>: 84d20: 48 8b 47 10 mov 0x10(%rdi),%rax 84d24: 48 83 f8 05 cmp $0x5,%rax 84d28: b9 05 00 00 00 mov $0x5,%ecx 84d2d: 48 0f 42 c8 cmovb %rax,%rcx 84d31: 48 89 4f 10 mov %rcx,0x10(%rdi) 84d35: c3 retq 84d36: 66 2e 0f 1f 84 00 00 nopw %cs:0x0(%rax,%rax,1) 84d3d: 00 00 00 0000000000084d40 <baz>: 84d40: 48 8b 47 10 mov 0x10(%rdi),%rax 84d44: 48 39 f0 cmp %rsi,%rax 84d47: 48 0f 47 c6 cmova %rsi,%rax 84d4b: 48 89 47 10 mov %rax,0x10(%rdi) 84d4f: c3 retq 0000000000084d50 <foo_string>: 84d50: 41 57 push %r15 84d52: 41 56 push %r14 84d54: 53 push %rbx 84d55: 49 89 fe mov %rdi,%r14 84d58: 4c 8b 7f 10 mov 0x10(%rdi),%r15 84d5c: 4d 85 ff test %r15,%r15 84d5f: 74 2f je 84d90 <foo_string+0x40> 84d61: 49 8b 06 mov (%r14),%rax 84d64: 4b 8d 0c 7f lea (%r15,%r15,2),%rcx 84d68: 48 8d 1c c8 lea (%rax,%rcx,8),%rbx 84d6c: 48 83 c3 f0 add $0xfffffffffffffff0,%rbx 84d70: 48 8b 33 mov (%rbx),%rsi 84d73: 48 85 f6 test %rsi,%rsi 84d76: 74 0e je 84d86 <foo_string+0x36> 84d78: 48 8b 7b f8 mov -0x8(%rbx),%rdi 84d7c: ba 01 00 00 00 mov $0x1,%edx 84d81: e8 1a b1 ff ff callq 7fea0 <__rust_dealloc@plt> 84d86: 48 83 c3 e8 add $0xffffffffffffffe8,%rbx 84d8a: 49 83 c7 ff add $0xffffffffffffffff,%r15 84d8e: 75 e0 jne 84d70 <foo_string+0x20> 84d90: 49 c7 46 10 00 00 00 movq $0x0,0x10(%r14) 84d97: 00 84d98: 5b pop %rbx 84d99: 41 5e pop %r14 84d9b: 41 5f pop %r15 84d9d: c3 retq 84d9e: 66 90 xchg %ax,%ax 0000000000084da0 <bar_string>: 84da0: 41 57 push %r15 84da2: 41 56 push %r14 84da4: 53 push %rbx 84da5: 49 89 fe mov %rdi,%r14 84da8: 4c 8b 7f 10 mov 0x10(%rdi),%r15 84dac: 49 83 ff 06 cmp $0x6,%r15 84db0: 72 44 jb 84df6 <bar_string+0x56> 84db2: 49 8b 06 mov (%r14),%rax 84db5: 4b 8d 0c 7f lea (%r15,%r15,2),%rcx 84db9: 48 8d 1c c8 lea (%rax,%rcx,8),%rbx 84dbd: 48 83 c3 f0 add $0xfffffffffffffff0,%rbx 84dc1: 49 83 c7 fb add $0xfffffffffffffffb,%r15 84dc5: 66 2e 0f 1f 84 00 00 nopw %cs:0x0(%rax,%rax,1) 84dcc: 00 00 00 84dcf: 90 nop 84dd0: 48 8b 33 mov (%rbx),%rsi 84dd3: 48 85 f6 test %rsi,%rsi 84dd6: 74 0e je 84de6 <bar_string+0x46> 84dd8: 48 8b 7b f8 mov -0x8(%rbx),%rdi 84ddc: ba 01 00 00 00 mov $0x1,%edx 84de1: e8 ba b0 ff ff callq 7fea0 <__rust_dealloc@plt> 84de6: 48 83 c3 e8 add $0xffffffffffffffe8,%rbx 84dea: 49 83 c7 ff add $0xffffffffffffffff,%r15 84dee: 75 e0 jne 84dd0 <bar_string+0x30> 84df0: 41 bf 05 00 00 00 mov $0x5,%r15d 84df6: 4d 89 7e 10 mov %r15,0x10(%r14) 84dfa: 5b pop %rbx 84dfb: 41 5e pop %r14 84dfd: 41 5f pop %r15 84dff: c3 retq 0000000000084e00 <baz_string>: 84e00: 41 57 push %r15 84e02: 41 56 push %r14 84e04: 41 54 push %r12 84e06: 53 push %rbx 84e07: 50 push %rax 84e08: 49 89 ff mov %rdi,%r15 84e0b: 48 8b 47 10 mov 0x10(%rdi),%rax 84e0f: 49 89 c4 mov %rax,%r12 84e12: 49 29 f4 sub %rsi,%r12 84e15: 76 3c jbe 84e53 <baz_string+0x53> 84e17: 49 89 f6 mov %rsi,%r14 84e1a: 49 8b 0f mov (%r15),%rcx 84e1d: 48 8d 04 40 lea (%rax,%rax,2),%rax 84e21: 48 8d 1c c1 lea (%rcx,%rax,8),%rbx 84e25: 48 83 c3 f0 add $0xfffffffffffffff0,%rbx 84e29: 0f 1f 80 00 00 00 00 nopl 0x0(%rax) 84e30: 48 8b 33 mov (%rbx),%rsi 84e33: 48 85 f6 test %rsi,%rsi 84e36: 74 0e je 84e46 <baz_string+0x46> 84e38: 48 8b 7b f8 mov -0x8(%rbx),%rdi 84e3c: ba 01 00 00 00 mov $0x1,%edx 84e41: e8 5a b0 ff ff callq 7fea0 <__rust_dealloc@plt> 84e46: 48 83 c3 e8 add $0xffffffffffffffe8,%rbx 84e4a: 49 83 c4 ff add $0xffffffffffffffff,%r12 84e4e: 75 e0 jne 84e30 <baz_string+0x30> 84e50: 4c 89 f0 mov %r14,%rax 84e53: 49 89 47 10 mov %rax,0x10(%r15) 84e57: 48 83 c4 08 add $0x8,%rsp 84e5b: 5b pop %rbx 84e5c: 41 5c pop %r12 84e5e: 41 5e pop %r14 84e60: 41 5f pop %r15 84e62: c3 retq 84e63: 90 nop 84e64: 66 2e 0f 1f 84 00 00 nopw %cs:0x0(%rax,%rax,1) 84e6b: 00 00 00 84e6e: 66 90 xchg %ax,%ax ``` </details> For calling `truncate` with non-zero lengths on non-`Drop` types, it seems that a redundant load and comparison gets replaced with an awkward sequence with a conditional move. In the unknown length case, the new code is no longer awkward. Maybe someone moderately proficient at assembly could tell if this looks like a win or not. --- This came up when discussing replacing `unsafe { vec.set_len(0) }` with `vec.clear()` in a project where the author was worried about potential performance degradation. It might be worth replacing some unsafe code, even it it's trivial to see that it's actually safe.
2018-08-01Rollup merge of #52914 - nagisa:sparc-is-sparc’s-own-business, r=alexcrichtonPietro Albini-0/+1
Only run the sparc-abi test on sparc It is not required for LLVM to have SPARC target support, so it is necessary to only run this test when LLVM does support SPARC. Sadly, it isn’t possible to specify exactly this constraint. Instead, we specify that this test should run on SPARC host only (it surely is sane assumption to make that compiler running on a SPARC can generate SPARC, right?) Since you cannot specify multiple `only-*` to have it run on both 32-bit and 64-bit SPARC we pick 64-bit SPARC, because it is exactly what is being tested by this test. Fixes #52881
2018-08-01Rollup merge of #52825 - RalfJung:codegen, r=alexcrichtonPietro Albini-0/+42
Make sure #47772 does not regress Mostly to make my life in https://github.com/rust-lang/rust/pull/52206 harder.^^ Or should I just add that test there?
2018-07-31Make globals with private linkage unnamed. Fixes #50862.Colin Pronovost-3/+3
2018-07-31Only run the sparc-abi test on sparcSimonas Kazlauskas-0/+1
It is not required for LLVM to have SPARC target support, so it is necessary to only run this test when LLVM does support SPARC. Sadly, it isn’t possible to specify exactly this constraint. Instead, we specify that this test should run on SPARC host only (it surely is sane assumption to make that compiler running on a SPARC can generate SPARC, right?) Since you cannot specify multiple `only-*` to have it run on both 32-bit and 64-bit SPARC we pick 64-bit SPARC, because it is exactly what is being tested by this test. Fixes #52881
2018-07-31Use SetLenOnDrop in Vec::truncate()Laurentiu Nicola-0/+21
This avoids a redundant length check in some cases when calling `Vec::truncate` or `Vec::clear`. Fixes #51802
2018-07-31hopefully make test pass on windowsRalf Jung-6/+6
2018-07-31make sure that the no-panic test tests what it is supposed to testRalf Jung-0/+8
2018-07-29dont hardcode vtable size in codegen testRalf Jung-2/+2
2018-07-29update codegen testsRalf Jung-2/+2
2018-07-29Make sure #47772 does not regressRalf Jung-0/+34
2018-07-26Add a test for sparc64 ABI issueSimonas Kazlauskas-0/+36
2018-07-21Only run the test on x86_64Scott McMurray-0/+1
Smaller platforms don't merge the loads the same way.
2018-07-21Don't use SIMD in mem::swap for types smaller than the block sizeScott McMurray-0/+26
LLVM isn't able to remove the alloca for the unaligned block in the SIMD tail in some cases, so doing this helps SRoA work in cases where it currently doesn't. Found in the `replace_with` RFC discussion.
2018-07-13Auto merge of #51622 - kennytm:three-field-range-inclusive, r=SimonSapinbors-0/+74
Change RangeInclusive to a three-field struct. Fix #45222. This PR also reverts #48012 (i.e. removed the `try_fold`/`try_rfold` specialization for `RangeInclusive`) because LLVM no longer has trouble recognizing a RangeInclusive loop.
2018-07-13Change RangeInclusive to a three-field struct.kennytm-0/+74
Fix #45222.
2018-07-13Auto merge of #52046 - cramertj:fix-generator-mir, r=eddybbors-3/+3
Ensure StorageDead is created even if variable initialization fails Rebase and slight cleanup of https://github.com/rust-lang/rust/pull/51109 Fixes https://github.com/rust-lang/rust/issues/49232 r? @eddyb
2018-07-12Ensure StorageDead is created even if variable initialization failsTaylor Cramer-3/+3
2018-07-11Auto merge of #51966 - alexcrichton:llvm7, r=michaelwoeristerbors-20/+26
Upgrade to LLVM's master branch (LLVM 7) ### Current status ~~Blocked on a [performance regression](https://github.com/rust-lang/rust/pull/51966#issuecomment-402320576). The performance regression has an [upstream LLVM issue](https://bugs.llvm.org/show_bug.cgi?id=38047) and has also [been bisected](https://reviews.llvm.org/D44282) to an LLVM revision.~~ Ready to merge! --- This commit upgrades the main LLVM submodule to LLVM's current master branch. The LLD submodule is updated in tandem as well as compiler-builtins. Along the way support was also added for LLVM 7's new features. This primarily includes the support for custom section concatenation natively in LLD so we now add wasm custom sections in LLVM IR rather than having custom support in rustc itself for doing so. Some other miscellaneous changes are: * We now pass `--gc-sections` to `wasm-ld` * The optimization level is now passed to `wasm-ld` * A `--stack-first` option is passed to LLD to have stack overflow always cause a trap instead of corrupting static data * The wasm target for LLVM switched to `wasm32-unknown-unknown`. * The syntax for aligned pointers has changed in LLVM IR and tests are updated to reflect this. * ~~The `thumbv6m-none-eabi` target is disabled due to an [LLVM bug][llbug]~~ Nowadays we've been mostly only upgrading whenever there's a major release of LLVM but enough changes have been happening on the wasm target that there's been growing motivation for quite some time now to upgrade out version of LLD. To upgrade LLD, however, we need to upgrade LLVM to avoid needing to build yet another version of LLVM on the builders. The revision of LLVM in use here is arbitrarily chosen. We will likely need to continue to update it over time if and when we discover bugs. Once LLVM 7 is fully released we can switch to that channel as well. [llbug]: https://bugs.llvm.org/show_bug.cgi?id=37382 cc #50543
2018-07-10Upgrade to LLVM's master branch (LLVM 7)Alex Crichton-20/+26
This commit upgrades the main LLVM submodule to LLVM's current master branch. The LLD submodule is updated in tandem as well as compiler-builtins. Along the way support was also added for LLVM 7's new features. This primarily includes the support for custom section concatenation natively in LLD so we now add wasm custom sections in LLVM IR rather than having custom support in rustc itself for doing so. Some other miscellaneous changes are: * We now pass `--gc-sections` to `wasm-ld` * The optimization level is now passed to `wasm-ld` * A `--stack-first` option is passed to LLD to have stack overflow always cause a trap instead of corrupting static data * The wasm target for LLVM switched to `wasm32-unknown-unknown`. * The syntax for aligned pointers has changed in LLVM IR and tests are updated to reflect this. * The `thumbv6m-none-eabi` target is disabled due to an [LLVM bug][llbug] Nowadays we've been mostly only upgrading whenever there's a major release of LLVM but enough changes have been happening on the wasm target that there's been growing motivation for quite some time now to upgrade out version of LLD. To upgrade LLD, however, we need to upgrade LLVM to avoid needing to build yet another version of LLVM on the builders. The revision of LLVM in use here is arbitrarily chosen. We will likely need to continue to update it over time if and when we discover bugs. Once LLVM 7 is fully released we can switch to that channel as well. [llbug]: https://bugs.llvm.org/show_bug.cgi?id=37382
2018-07-10Auto merge of #51583 - cuviper:packed_pair-bool, r=Mark-Simulacrumbors-1/+55
Store scalar pair bools as i8 in memory We represent `bool` as `i1` in a `ScalarPair`, unlike other aggregates, to optimize IR for checked operators and the like. With this patch, we still do so when the pair is an immediate value, but we use the `i8` memory type when the value is loaded or stored as an LLVM aggregate. So `(bool, bool)` looks like an `{ i1, i1 }` immediate, but `{ i8, i8 }` in memory. When a pair is a direct function argument, `PassMode::Pair`, it is still passed using the immediate `i1` type, but as a return value it will use the `i8` memory type. Also, `bool`-like` enum tags will now use scalar pairs when possible, where they were previously excluded due to optimization issues. Fixes #51516. Closes #51566. r? @eddyb cc @nox
2018-07-09bump llvm version of failing codegen testgnzlbg-0/+1
2018-07-09bump minimum LLVM version to 5.0gnzlbg-12/+1
2018-07-05Update scalar pairs per review commentsJosh Stone-0/+14
2018-07-05Store scalar pair bools as i8 in memoryJosh Stone-1/+41
We represent `bool` as `i1` in a `ScalarPair`, unlike other aggregates, to optimize IR for checked operators and the like. With this patch, we still do so when the pair is an immediate value, but we use the `i8` memory type when the value is loaded or stored as an LLVM aggregate. So `(bool, bool)` looks like an `{ i1, i1 }` immediate, but `{ i8, i8 }` in memory. When a pair is a direct function argument, `PassMode::Pair`, it is still passed using the immediate `i1` type, but as a return value it will use the `i8` memory type. Also, `bool`-like` enum tags will now use scalar pairs when possible, where they were previously excluded due to optimization issues.
2018-06-30Do not allow LLVM to increase a TLS's alignment on macOS.kennytm-0/+40
2018-06-17test: Ignore some problematic tests on powerpc and powerpc64*John Paul Adrian Glaubitz-0/+8
2018-06-12Stabilize #[repr(transparent)]Simon Sapin-5/+1
Tracking issue FCP: https://github.com/rust-lang/rust/issues/43036#issuecomment-394094318 Reference PR: https://github.com/rust-lang-nursery/reference/pull/353
2018-06-04test: Ignore some problematic tests on sparc and sparc64John Paul Adrian Glaubitz-0/+8
2018-05-28Auto merge of #50521 - gnzlbg:simd_float, r=alexcrichtonbors-1/+1554
Add simd math intrinsics and gather/scatter This PR adds simd math intrinsics for floating-point vectors (sqrt, sin, cos, pow, exp, log, fma, abs, etc.) and the generic simd gather/scatter intrinsics.
2018-05-24std: Ensure OOM is classified as `nounwind`Alex Crichton-0/+21
OOM can't unwind today, and historically it's been optimized as if it can't unwind. This accidentally regressed with recent changes to the OOM handler, so this commit adds in a codegen test to assert that everything gets optimized away after the OOM function is approrpiately classified as nounwind Closes #50925
2018-05-24enable fast-math flagsgnzlbg-98/+98
2018-05-24add gather/scatter run-time testgnzlbg-0/+3
2018-05-24add run-time test and missing codegen testgnzlbg-0/+104
2018-05-24fix tidygnzlbg-0/+2
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-01-18 04:22:53 +0000