Files
rust/tests/codegen
bors 3b022d8cee Auto merge of #133852 - x17jiri:cold_path, r=saethlin
improve cold_path()

#120370 added a new instrinsic `cold_path()` and used it to fix `likely` and `unlikely`

However, in order to limit scope, the information about cold code paths is only used in 2-target switch instructions. This is sufficient for `likely` and `unlikely`, but limits usefulness of `cold_path` for idiomatic rust. For example, code like this:

```
if let Some(x) = y { ... }
```

may generate 3-target switch:

```
switch y.discriminator:
0 => true branch
1 = > false branch
_ => unreachable
```

and therefore marking a branch as cold will have no effect.

This PR improves `cold_path()` to work with arbitrary switch instructions.

Note that for 2-target switches, we can use `llvm.expect`, but for multiple targets we need to manually emit branch weights. I checked Clang and it also emits weights in this situation. The Clang's weight calculation is more complex that this PR, which I believe is mainly because `switch` in `C/C++` can have multiple cases going to the same target.
2025-02-18 07:49:09 +00:00
..
2024-05-31 15:56:43 +10:00
2024-10-06 18:12:25 +02:00
2024-05-31 15:56:43 +10:00
2025-01-28 19:10:24 +03: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-05-31 15:56:43 +10:00
2024-04-11 21:42:35 -04:00
2024-05-31 15:56:43 +10: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
2024-05-31 15:56:43 +10:00
2024-05-03 14:32:08 +02: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
2024-07-14 13:48:29 +03:00
2024-12-10 21:41:05 +01: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-01-21 08:27:30 +00:00
2024-08-07 00:41:48 -04:00
2024-05-31 15:56:43 +10: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