On Fri, May 15, 2026 at 6:02 PM Richard Sandiford
<[email protected]> wrote:
>
> Richard Sandiford <[email protected]> writes:
> > "H.J. Lu" <[email protected]> writes:
> >> I found a typo in the v2 patch.   Here is the v3 patch.  I also changed
> >> ix86_original_abi and ix86_alternate_abi implementation:
> >>
> >> /* Return the descriptor of the standard function ABI type.  If
> >>    ABI_TYPE == ABI_ALTERNATE, return the function alternate ABI type.  */
> >>
> >> static const predefined_function_abi &
> >> ix86_standard_abi (int abi_type)
> >> {
> >>   static const char ix86_call_used_regs[] = CALL_USED_REGISTERS;
> >>   auto &standard_abi = function_abis[abi_type];
> >>   if (!standard_abi.initialized_p ())
> >>     {
> >>       HARD_REG_SET full_reg_clobbers = {};
> >>
> >>       /* Add all registers that are clobbered by the call.  NB: If the
> >>          current ABI is SYSV_ABI, the alternate ABI is MS_ABI.   */
> >>       bool is_64bit_ms_abi = (TARGET_64BIT
> >>                               && ix86_abi == (abi_type == ABI_ALTERNATE
> >>                                               ? SYSV_ABI : MS_ABI));
> >>       char c_mask = CALL_USED_REGISTERS_MASK (is_64bit_ms_abi);
> >>       for (int i = 0; i < FIRST_PSEUDO_REGISTER; i++)
> >>         if (global_regs[i]
> >>             || (!fixed_regs[i]
> >>                 && (ix86_call_used_regs[i] == 1
> >>                     || (ix86_call_used_regs[i] & c_mask))))
> >>           SET_HARD_REG_BIT (full_reg_clobbers, i);
> >>
> >>       SET_HARD_REG_BIT (full_reg_clobbers, FLAGS_REG);
> >>       SET_HARD_REG_BIT (full_reg_clobbers, FPSR_REG);
> >>
> >>       standard_abi.initialize (abi_type, full_reg_clobbers);
> >>     }
> >>   return standard_abi;
> >> }
> >>
> >> /* Return the descriptor of the function ABI type without attributes
> >>    on the current function.  */
> >>
> >> static const predefined_function_abi &
> >> ix86_original_abi (void)
> >> {
> >>   return ix86_standard_abi (ABI_ORIGINAL);
> >> }
> >>
> >> /* Return the descriptor of the function alternate ABI type.  */
> >>
> >> static const predefined_function_abi &
> >> ix86_alternate_abi (void)
> >> {
> >>   return ix86_standard_abi (ABI_ALTERNATE);
> >> }
> >
> > Thanks.  I made a start on what I wanted to try today, but realised
> > that I needed a target-independent patch first.  I'll send that in a sec.
>
> Here's what I came up with.  It's split into two parts:
>
> - 3 prepatches to lay some groundwork.  If they're ok, I think they'd
>   make sense independently of the main patch.
>
> - some suggested changes to the main patch.  If versions of these
>   patches are ok, they'd make more sense folded into your patch,
>   rather than treated separately.
>
> So the full sequence is:
>
> - the first 3 of the attached patches (the ones with changelogs)
> - the CALL_INSN_ABI_ID patch that I posted yesterday
> - your LRA patch
> - your main patch (has a minor conflict with the first 3 patches)
> - the rest of the attached patches
>
> Yes, it's a bit of a stack :)
>
> I get three extra failures with this:
>
> FAIL: gcc.target/i386/no-callee-saved-19b.c check-function-bodies start
> FAIL: gcc.target/i386/no-callee-saved-19e.c check-function-bodies start
> FAIL: gcc.target/i386/stack-check-17.c scan-assembler-times pop[ql] 1
>
> The first two fail for both 32-bit and 64-bit.  The last one is
> specific to 64-bit.
>
> In no-callee-saved-19b.c and no-callee-saved-19e.c, the test is expecting
> a call from no_caller_saved_registers to no_callee_saved_registers to
> save the frame pointer.  But both your patch and LLVM seem to agree
> that preserve_none does not change the frame pointer.  For LLVM, see:
> https://godbolt.org/z/KrGePj3or where start does not save or restore
> rbp and clobber does preserve rbp.  So maybe the test could be adjusted?
>
> stack-check-17.c passes in its original form, in that we go back
> to not having a pop for 64-bit.
>
> I'm obviously far from an x86 expert, so there are probably lots of
> details that I've got wrong or missed, but hopefully it's at least
> somewhat useful.
>

I will take a closer look.

Thank you for your help.


-- 
H.J.

Reply via email to