[clang] [llvm] Implement `preserve_none` for 32-bit x86 (PR #150106)

brandtbucher wrote: > Function X86FrameLowering::spillFPBP can do this for clobbered base pointer > and frame pointer. So the `RBX`/`ESI` base pointers can be removed from the callee-saved-regs lists? ```diff diff --git a/llvm/lib/Target/X86/X86CallingConv.td b/llvm/lib/Target/X86/X86Calling

[clang] [llvm] Implement `preserve_none` for 32-bit x86 (PR #150106)

brandtbucher wrote: > LGTM, but I'd like a second set of eyes on this. Maybe @weiguozhi, the author of 64-bit `preserve_none`? https://github.com/llvm/llvm-project/pull/150106 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.

[clang] [llvm] Implement `preserve_none` for 32-bit x86 (PR #150106)

brandtbucher wrote: How about we add the base pointers to both clobber lists here and leave the nest parameter as a future improvement for another PR? The calling convention is ABI-unstable, so we can always tweak it later. https://github.com/llvm/llvm-project/pull/150106 _

[clang] [llvm] Implement `preserve_none` for 32-bit x86 (PR #150106)

brandtbucher wrote: Okay. Both of those concerns already apply to the existing 64-bit flavor, right? Would you prefer to see them addressed here, or in a dedicated follow-up? > For "nest", we can forbid combining it with the preserves_none calling > convention, probably, as long as we can dete

[clang] [llvm] Implement `preserve_none` for 32-bit x86 (PR #150106)

brandtbucher wrote: Thanks @efriedma-quic, I missed that the base pointer is `ESI` (not `EBX`) on 32-bit targets. I forgot about the "nest" parameter (`ECX`), and the GOT pointer (`EBX`) too. How's this for the new parameter list? ```diff diff --git a/llvm/lib/Target/X86/X86CallingConv.td b/

[clang] [llvm] Try to use non-volatile registers for `preserve_none` parameters (PR #88333)

brandtbucher wrote: Anyone available to merge this (now that it's been approved)? https://github.com/llvm/llvm-project/pull/88333 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [AArch64] Support preserve_none calling convention (PR #91046)

brandtbucher wrote: Aw, but that means we only have *twenty-six* registers for argument-passing... ;) https://github.com/llvm/llvm-project/pull/91046 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listin

[clang] [llvm] Try to use non-volatile registers for `preserve_none` parameters (PR #88333)

brandtbucher wrote: The Windows x64 Buildkite CI job is failing, but I can't find any failed tests in the downloaded logs. Any advice? https://github.com/llvm/llvm-project/pull/88333 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lis

[clang] [llvm] Try to use non-volatile registers for `preserve_none` parameters (PR #88333)

brandtbucher wrote: Yep. I also updated the docs with the new register-passing order. https://github.com/llvm/llvm-project/pull/88333 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] Try to use non-volatile registers for `preserve_none` parameters (PR #88333)

https://github.com/brandtbucher updated https://github.com/llvm/llvm-project/pull/88333 >From f797b695ce38f46563f3724dcffee4005c65c659 Mon Sep 17 00:00:00 2001 From: Brandt Bucher Date: Wed, 10 Apr 2024 17:03:19 -0700 Subject: [PATCH 1/2] Prefer non-volatile registers for preserve_none Use non

[clang] [llvm] New calling convention preserve_none (PR #76868)

brandtbucher wrote: Draft PR at https://github.com/llvm/llvm-project/pull/88333. https://github.com/llvm/llvm-project/pull/76868 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] New calling convention preserve_none (PR #76868)

brandtbucher wrote: Thanks for working on this! It's really appreciated. Two follow-up questions: - Is AArch64 support planned soon? - Am I correct in understanding that this missed the LLVM 18 cut, and won't until LLVM 19 in mid-August-ish? https://github.com/llvm/llvm-project/pull/76868 ___