Files
rust/tests/codegen
bors 5f3b84a421 Auto merge of #137278 - heiseish:101210-extra-codegen-tests, r=scottmcm
added some new test to check for result and options opt

Apologies for the delay. Finally have some time to get back into contributing.

## Context
- Added some tests to show optimization on result and options for 64 and 128 bits
- Relevant issue https://github.com/rust-lang/rust/issues/101210

## Some newb questions from me
- [x] My local llvm IR has `nuw` in `result_nop_match_128` etc whereas [godbolt version](https://rust.godbolt.org/z/Td9zoT5zn) doesn't have. So I put optional there, but not sure if it's desirable (maybe I'm not using the compiled llvm in the repo). I ran the test with
```bash
./x test tests/codegen/try_question_mark_nop.rs
```
- [x] Unless I'm reading it wrongly, but `option_nop_match_128` and `option_nop_traits_128` look to be **not** optimized away?

Update:
Here's the test for future reference
```rust
// CHECK-LABEL: `@option_nop_match_128`
#[no_mangle]
pub fn option_nop_match_128(x: Option<i128>) -> Option<i128> {
    // CHECK: start:
    // CHECK-NEXT: %trunc = trunc nuw i128 %0 to i1
    // CHECK-NEXT: br i1 %trunc, label %bb3, label %bb4
    // CHECK: bb3:
    // CHECK-NEXT: %2 = getelementptr inbounds {{(nuw )?}}i8, ptr %_0, i64 16
    // CHECK-NEXT: store i128 %1, ptr %2, align 16
    // CHECK: bb4:
    // CHECK-NEXT: %storemerge = phi i128 [ 1, %bb3 ], [ 0, %start ]
    // CHECK-NEXT: store i128 %storemerge, ptr %_0, align 16
    // CHECK-NEXT: ret void
    match x {
        Some(x) => Some(x),
        None => None,
    }
}
```

r? `@scottmcm`
2025-03-16 05:17:07 +00:00
..
2024-05-31 15:56:43 +10:00
2025-02-24 09:26:54 +00:00
2025-02-24 09:26:54 +00:00
2024-05-31 15:56:43 +10:00
2025-03-14 01:45:10 +01:00
2025-02-24 09:26:54 +00:00
2025-02-24 09:26:54 +00:00
2025-02-24 09:26:54 +00:00
2025-02-24 09:26:54 +00:00
2025-02-24 09:26:54 +00:00
2025-02-24 09:26:54 +00:00
2025-02-24 09:26:54 +00:00
2025-02-24 09:26:54 +00:00
2025-02-24 09:26:54 +00:00
2025-02-24 09:26:54 +00:00
2024-05-31 15:56:43 +10:00
2024-05-31 15:56:43 +10:00
2024-05-31 15:56:43 +10:00
2024-05-31 15:56:43 +10:00
2024-04-11 21:42:35 -04:00
2025-02-21 21:51:20 -05:00
2024-05-31 15:56:43 +10:00
2025-02-24 09:26:54 +00:00
2025-02-24 09:26:54 +00:00
2025-02-24 09:26:54 +00:00
2024-05-31 15:56:43 +10:00
2024-04-24 13:12:33 +01:00
2024-09-09 19:39:43 -07:00
2025-02-03 10:39:32 -05:00
2024-05-31 15:56:43 +10:00
2024-05-31 15:56:43 +10:00
2025-02-24 09:26:54 +00:00
2024-05-31 15:56:43 +10:00
2025-02-24 09:26:54 +00:00
2024-05-31 15:56:43 +10:00
2025-02-24 09:26:54 +00:00
2025-02-24 09:26:54 +00:00
2024-07-14 13:48:29 +03:00
2025-02-24 09:26:54 +00:00
2024-05-31 15:56:43 +10:00
2024-07-14 13:48:29 +03:00
2024-12-10 21:41:05 +01:00
2025-02-24 09:26:54 +00:00
2024-05-31 15:56:43 +10:00
2024-07-14 13:48:29 +03:00
2024-05-31 15:56:43 +10:00
2025-02-24 09:26:54 +00:00
2025-02-24 09:26:54 +00:00
2025-03-02 18:53:49 +00:00
2025-02-24 09:26:54 +00:00
2024-08-07 00:41:48 -04:00
2024-05-31 15:56:43 +10:00
2025-02-19 11:36:52 -08:00
2024-09-09 19:39:43 -07:00

The files here use the LLVM FileCheck framework, documented at https://llvm.org/docs/CommandGuide/FileCheck.html.

One extension worth noting is the use of revisions as custom prefixes for FileCheck. If your codegen test has different behavior based on the chosen target or different compiler flags that you want to exercise, you can use a revisions annotation, like so:

// revisions: aaa bbb
// [bbb] compile-flags: --flags-for-bbb

After specifying those variations, you can write different expected, or explicitly unexpected output by using <prefix>-SAME: and <prefix>-NOT:, like so:

// CHECK: expected code
// aaa-SAME: emitted-only-for-aaa
// aaa-NOT:                        emitted-only-for-bbb
// bbb-NOT:  emitted-only-for-aaa
// bbb-SAME:                       emitted-only-for-bbb