https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=perf-tmp 2025-07-22T12:27:48+00:00 2025-07-22T12:27:48+00:00 Guillaume Gomez guillaume1.gomez@gmail.com 2025-07-21T12:22:51+00:00 urn:sha1:ed93c1783b404d728d4809973a0550eb33cd293f 2025-07-20T13:34:08+00:00 Guillaume Gomez guillaume1.gomez@gmail.com 2025-07-20T13:34:08+00:00 urn:sha1:8e7601e10e0e3e3f9d7d4e5cd5ea515cd1c80fcf tests: assembly: cstring-merging: Disable GlobalMerge pass The test relies on LLVM not merging all the globals into one and would currently otherwise fail on powerpc64le. See https://github.com/llvm/llvm-project/blob/release/20.x/llvm/lib/CodeGen/GlobalMerge.cpp and here's the assembly generated prior to disabling the pass: <details> <summary>Expand me</summary> ```asm .abiversion 2 .file "cstring_merging.5aa81ea7b99b31fe-cgu.0" .section .text.cstr,"ax",``@progbits`` .globl cstr .p2align 4 .type cstr,``@function`` cstr: .Lfunc_begin0: .cfi_startproc .Lfunc_gep0: addis 2, 12, .TOC.-.Lfunc_gep0@ha addi 2, 2, .TOC.-.Lfunc_gep0@l .Lfunc_lep0: .localentry cstr, .Lfunc_lep0-.Lfunc_gep0 addis 3, 2, .L_MergedGlobals@toc@ha li 4, 4 addi 3, 3, .L_MergedGlobals@toc@l addi 3, 3, 4 blr .long 0 .quad 0 .Lfunc_end0: .size cstr, .Lfunc_end0-.Lfunc_begin0 .cfi_endproc .section .text.manual_cstr,"ax",``@progbits`` .globl manual_cstr .p2align 4 .type manual_cstr,``@function`` manual_cstr: .Lfunc_begin1: .cfi_startproc .Lfunc_gep1: addis 2, 12, .TOC.-.Lfunc_gep1@ha addi 2, 2, .TOC.-.Lfunc_gep1@l .Lfunc_lep1: .localentry manual_cstr, .Lfunc_lep1-.Lfunc_gep1 addis 3, 2, .L_MergedGlobals@toc@ha li 4, 4 addi 3, 3, .L_MergedGlobals@toc@l addi 3, 3, 8 blr .long 0 .quad 0 .Lfunc_end1: .size manual_cstr, .Lfunc_end1-.Lfunc_begin1 .cfi_endproc .type CSTR,``@object`` .section .data.rel.ro.CSTR,"aw",``@progbits`` .globl CSTR .p2align 3, 0x0 CSTR: .quad .L_MergedGlobals .size CSTR, 8 .type .L_MergedGlobals,``@object`` .section .rodata..L_MergedGlobals,"a",``@progbits`` .L_MergedGlobals: .asciz "foo" .asciz "bar" .asciz "baz" .size .L_MergedGlobals, 12 .set .Lanon.a643e9a6bba67b7953be2b5f96e0e802.0, .L_MergedGlobals .size .Lanon.a643e9a6bba67b7953be2b5f96e0e802.0, 4 .set .Lanon.a643e9a6bba67b7953be2b5f96e0e802.1, .L_MergedGlobals+4 .size .Lanon.a643e9a6bba67b7953be2b5f96e0e802.1, 4 .set .Lanon.a643e9a6bba67b7953be2b5f96e0e802.2, .L_MergedGlobals+8 .size .Lanon.a643e9a6bba67b7953be2b5f96e0e802.2, 4 .ident "rustc version 1.90.0-dev" .section ".note.GNU-stack","",``@progbits`` ``` </details> 2025-07-18T17:45:36+00:00 Jens Reidel adrian@travitia.xyz 2025-07-18T17:44:20+00:00 urn:sha1:2d51acd2fbcbadb6f30709c5dd305494d413d388 The test relies on LLVM not merging all the globals into one and would currently otherwise fail on powerpc64le. Signed-off-by: Jens Reidel <adrian@travitia.xyz> 2025-07-18T07:36:11+00:00 Nikita Popov npopov@redhat.com 2025-07-14T08:29:05+00:00 urn:sha1:a65563e9cd817e2cfd75291bb97529dfb14eb451 The presence of `@add-core-stubs` indicates that this was already intended. 2025-07-18T07:35:50+00:00 Nikita Popov npopov@redhat.com 2025-07-11T08:11:03+00:00 urn:sha1:12b19be741ea07934d7478bd8e450dca8f85afe5 This is no longer implied by -wasm-enable-eh. 2025-07-08T23:09:55+00:00 Folkert de Vries folkert@folkertdev.nl 2025-07-07T17:23:06+00:00 urn:sha1:6fc5d4edda88d0dd28c45ccba1a1e217ddad11c4 2025-07-06T22:10:52+00:00 Jules Bertholet julesbertholet@quoi.xyz 2025-07-06T22:10:52+00:00 urn:sha1:8f86c4abec54ecc06b469fff2cccf0a4182db41d 2025-06-25T07:52:10+00:00 Jubilee Young workingjubilee@gmail.com 2025-06-07T06:07:41+00:00 urn:sha1:1400e2d9f519005161da91d8a1e88e54bc56acab 2025-06-20T06:50:38+00:00 Trevor Gross t.gross35@gmail.com 2025-06-20T06:50:38+00:00 urn:sha1:c117ebefd23c47fa71252291f7fb597555c74daa Extract some shared code from codegen backend target feature handling There's a bunch of code duplication between the GCC and LLVM backends in target feature handling. This moves that into new shared helper functions in `rustc_codegen_ssa`. The first two commits should be purely refactoring. I am fairly sure the LLVM-side behavior stays the same; if the GCC side deliberately diverges from this then I may have missed that. I did account for one divergence, which I do not know is deliberate or not: GCC does not seem to use the `-Ctarget-feature` flag to populate `cfg(target_feature)`. That seems odd, since the `-Ctarget-feature` flag is used to populate the return value of `global_gcc_features` which controls the target features actually used by GCC. ``@GuillaumeGomez`` ``@antoyo`` is there a reason `target_config` ignores `-Ctarget-feature` but `global_gcc_features` does not? The second commit also cleans up a bunch of unneeded complexity added in https://github.com/rust-lang/rust/pull/135927. The third commit extracts some shared logic out of the functions that populate `cfg(target_feature)` and the backend target feature set, respectively. This one actually has some slight functional changes: - Before, with `-Ctarget-feature=-feat`, if there is some other feature `x` that implies `feat` we would *not* add `-x` to the backend target feature set. Now, we do. This fixes rust-lang/rust#134792. - The logic that removes `x` from `cfg(target_feature)` in this case also changed a bit, avoiding a large number of calls to the (uncached) `sess.target.implied_target_features` (if there were a large number of positive features listed before a negative feature) but instead constructing a full inverse implication map when encountering the first negative feature. Ideally this would be done with queries but the backend target feature logic runs before `tcx` so we can't use that... - Previously, if feature "a" implied "b" and "b" was unstable, then using `-Ctarget-feature=+a` would also emit a warning about `b`. I had to remove this since when accounting for negative implications, this emits a ton of warnings in a bunch of existing tests... I assume this was unintentional anyway. The fourth commit increases consistency of the GCC backend with the LLVM backend. The last commit does some further cleanup: - Get rid of RUSTC_SPECIAL_FEATURES. It was only needed for s390x "backchain", but since LLVM 19 that is always a regular target feature so we don't need this hack any more. The hack also has various unintended side-effects so we don't want to keep it. Fixes https://github.com/rust-lang/rust/issues/142412. - Move RUSTC_SPECIFIC_FEATURES handling into the shared parse_rust_feature_flag helper so all consumers of `-Ctarget-feature` that only care about actual target features (and not "crt-static") have it. Previously, we actually set `cfg(target_feature = "crt-static")` twice: once in the backend target feature logic, and once specifically for that one feature. IIUC, some targets are meant to ignore `-Ctarget-feature=+crt-static`, it seems like before this PR that flag still incorrectly enabled `cfg(target_feature = "crt-static")` (but I didn't test this). - Move fixed_x18 handling together with retpoline handling. - Forbid setting fixed_x18 as a regular target feature, even unstably. It must be set via the `-Z` flag. ``@bjorn3`` I did not touch the cranelift backend here, since AFAIK it doesn't really support target features. But if you ever do, please use the new helpers. :) Cc ``@workingjubilee`` 2025-06-19T01:50:03+00:00 Ralf Jung post@ralfj.de 2025-06-14T12:11:00+00:00 urn:sha1:a50a3b8e318594c41783294e440d864763e412ef