Re: [tip: x86/asm] x86/asm: Make ASM_CALL_CONSTRAINT conditional on frame pointers

[Josh Poimboeuf]

On Mon, Mar 03, 2025 at 08:28:10AM -1000, Linus Torvalds wrote:
> On Mon, 3 Mar 2025 at 01:02, tip-bot2 for Josh Poimboeuf
> <tip-bot2@xxxxxxxxxxxxx> wrote:
> >
> > x86/asm: Make ASM_CALL_CONSTRAINT conditional on frame pointers
> >
> > With frame pointers enabled, ASM_CALL_CONSTRAINT is used in an inline
> > asm statement with a call instruction to force the compiler to set up
> > the frame pointer before doing the call.
> >
> > Without frame pointers, no such constraint is needed.  Make it
> > conditional on frame pointers.
> 
> Can we please explain *why* this is done?
> 
> It may not be required, but it makes the source code uglier and adds a
> conditional. What's the advantage of adding this extra logic?
> 
> I'm sure there is some reason for this change, but that reason should
> be explained.
> 
> Because "we don't need it" cuts both ways. Maybe we don't need the
> ASM_CALL_CONSTRAINT, but it also didn't use to hurt us.
> 
> The problems seems entirely caused by the change to use a strictly
> inferior version of ASM_CALL_CONSTRAINT.
> 
> Is there really no better option? Because the new ASM_CALL_CONSTRAINT
> seems actively horrendous.

The original ASM_CALL_CONSTRAINT was already pretty horrendous, can you
clarify why you think the new one is even worse?

On thing that's nicer, now that it's an input constraint, it can be
appended to other constraints without affecting the constraint ordering.

As far as making it conditional, the code generation seems better.
Before, it was forcing some functions to set up the frame pointer even
with ORC.

Also it nicely confines the hack to a little CONFIG_FRAME_POINTER
corner.  Frame pointers are very much deprecated on x86-64 anyway, maybe
we can just eventually get rid of that option.

-- 
Josh