rust/compiler/rustc_codegen_llvm/src, branch 1.77.0

[Beta 1.77] Fix bootstrapping from 1.76

2024-02-09T02:48:51+00:00

Rollup merge of #120495 - clubby789:remove-amdgpu-kernel, r=oli-obk

2024-01-31T11:10:53+00:00

Remove the `abi_amdgpu_kernel` feature The tracking issue (#51575) has been closed for 3 years, with no activity for 5.

Remove the `abi_amdgpu_kernel` feature

2024-01-30T15:46:40+00:00

add missing potential_query_instability for keys and values in hashmap

2024-01-30T04:43:10+00:00

Auto merge of #120062 - davidtwco:llvm-data-layout-check, r=wesleywiser

2024-01-27T12:19:41+00:00

llvm: change data layout bug to an error and make it trigger more Fixes #33446. Don't skip the inconsistent data layout check for custom LLVMs or non-built-in targets. With #118708, all targets will have a simple test that would trigger this error if LLVM's data layouts do change - so data layouts would be corrected during the LLVM upgrade. Therefore, with builtin targets, this error won't happen with our LLVM because each target will have been confirmed to work. With non-builtin targets, this error is probably useful to have because you can change the data layout in your target and if it is wrong then that could lead to bugs. When using a custom LLVM, the same justification makes sense for non-builtin targets as with our LLVM, the user can update their target to match their LLVM and that's probably a good thing to do. However, with a custom LLVM, the user cannot change the builtin target data layouts if they don't match - though given that the compiler's data layout is used for layout computation and a bunch of other things - you could get some bugs because of the mismatch and probably want to know about that. I'm not sure if this is something that people do and is okay, but I doubt it? `CFG_LLVM_ROOT` was also always set during local development with `download-ci-llvm` so this bug would never trigger locally. In #33446, two points are raised: - In the issue itself, changing this from a `bug!` to a proper error is what is suggested, by using `isCompatibleDataLayout` from LLVM, but that function still just does the same thing that we do and check for equality, so I've avoided the additional code necessary to do that FFI call. - `@Mark-Simulacrum` suggests a different check is necessary to maintain backwards compatibility with old LLVM versions. I don't know how often this comes up, but we can do that with some simple string manipulation + LLVM version checks as happens already for LLVM 17 just above this diff.

Remove unused features

2024-01-25T14:01:33+00:00

Auto merge of #119911 - NCGThompson:is-statically-known, r=oli-obk

2024-01-25T05:16:53+00:00

Replacement of #114390: Add new intrinsic `is_var_statically_known` and optimize pow for powers of two This adds a new intrinsic `is_val_statically_known` that lowers to [``@llvm.is.constant.*`](https://llvm.org/docs/LangRef.html#llvm-is-constant-intrinsic).` It also applies the intrinsic in the int_pow methods to recognize and optimize the idiom `2isize.pow(x)`. See #114390 for more discussion. While I have extended the scope of the power of two optimization from #114390, I haven't added any new uses for the intrinsic. That can be done in later pull requests. Note: When testing or using the library, be sure to use `--stage 1` or higher. Otherwise, the intrinsic will be a noop and the doctests will be skipped. If you are trying out edits, you may be interested in [`--keep-stage 0`](https://rustc-dev-guide.rust-lang.org/building/suggested.html#faster-builds-with---keep-stage). Fixes #47234 Resolves #114390 `@Centri3`

Add new intrinsic `is_constant` and optimize `pow`

2024-01-19T18:46:27+00:00

Fix overflow check Make MIRI choose the path randomly and rename the intrinsic Add back test Add miri test and make it operate on `ptr` Define `llvm.is.constant` for primitives Update MIRI comment and fix test in stage2 Add const eval test Clarify that both branches must have the same side effects guaranteed non guarantee use immediate type instead Co-Authored-By: Ralf Jung

LLVM 18 x86 data layout update

2024-01-19T09:52:01+00:00

With https://reviews.llvm.org/D86310 LLVM now has i128 aligned to 16-bytes on x86 based platforms. This will be in LLVM-18. This patch updates all our spec targets to be 16-byte aligned, and removes the alignment when speaking to older LLVM. This results in Rust overaligning things relative to LLVM on older LLVMs. This alignment change was discussed in rust-lang/compiler-team#683 See #54341 for additional information about why this is happening and where this will be useful in the future. This *does not* stabilize `i128`/`u128` for FFI.

llvm: simplify data layout check

2024-01-18T10:46:03+00:00

Don't skip the inconsistent data layout check for custom LLVMs. With #118708, all targets will have a simple test that would trigger this check if LLVM's data layouts do change - so data layouts would be corrected during the LLVM upgrade. Therefore, with builtin targets, this check won't trigger with our LLVM because each target will have been confirmed to work. With non-builtin targets, this check is probably useful to have because you can change the data layout in your target and if its wrong then that could lead to bugs. When using a custom LLVM, the same justification makes sense for non-builtin targets as with our LLVM, the user can update their target to match their LLVM and that's probably a good thing to do. However, with a custom LLVM, the user cannot change the builtin target data layouts if they don't match - though given that the compiler's data layout is used for layout computation and a bunch of other things - you could get some bugs because of the mismatch and probably want to know about that. `CFG_LLVM_ROOT` was also always set during local development with `download-ci-llvm` so this bug would never trigger locally. Signed-off-by: David Wood