On Tue, Apr 29, 2025 at 2:33 PM H.J. Lu <hjl.to...@gmail.com> wrote:
>
> On Tue, Apr 29, 2025 at 6:46 PM Richard Biener
> <richard.guent...@gmail.com> wrote:
> >
> > On Tue, Apr 29, 2025 at 12:32 PM H.J. Lu <hjl.to...@gmail.com> wrote:
> > >
> > > On Tue, Apr 29, 2025 at 5:56 PM Richard Biener
> > > <richard.guent...@gmail.com> wrote:
> > > >
> > > > On Tue, Apr 29, 2025 at 10:48 AM H.J. Lu <hjl.to...@gmail.com> wrote:
> > > > >
> > > > > On Tue, Apr 29, 2025 at 4:25 PM Richard Biener
> > > > > <richard.guent...@gmail.com> wrote:
> > > > > >
> > > > > > On Tue, Apr 29, 2025 at 9:39 AM H.J. Lu <hjl.to...@gmail.com> wrote:
> > > > > > >
> > > > > > > For targets, like x86, which define TARGET_PROMOTE_PROTOTYPES to
> > > > > > > return
> > > > > > > true, all integer arguments smaller than int are passed as int:
> > > > > > >
> > > > > > > [hjl@gnu-tgl-3 pr14907]$ cat x.c
> > > > > > > extern int baz (char c1);
> > > > > > >
> > > > > > > int
> > > > > > > foo (char c1)
> > > > > > > {
> > > > > > > return baz (c1);
> > > > > > > }
> > > > > > > [hjl@gnu-tgl-3 pr14907]$ gcc -S -O2 -m32 x.c
> > > > > > > [hjl@gnu-tgl-3 pr14907]$ cat x.s
> > > > > > > .file "x.c"
> > > > > > > .text
> > > > > > > .p2align 4
> > > > > > > .globl foo
> > > > > > > .type foo, @function
> > > > > > > foo:
> > > > > > > .LFB0:
> > > > > > > .cfi_startproc
> > > > > > > movsbl 4(%esp), %eax
> > > > > > > movl %eax, 4(%esp)
> > > > > > > jmp baz
> > > > > > > .cfi_endproc
> > > > > > > .LFE0:
> > > > > > > .size foo, .-foo
> > > > > > > .ident "GCC: (GNU) 14.2.1 20240912 (Red Hat 14.2.1-3)"
> > > > > > > .section .note.GNU-stack,"",@progbits
> > > > > > > [hjl@gnu-tgl-3 pr14907]$
> > > > > > >
> > > > > > > But integer promotion:
> > > > > > >
> > > > > > > movsbl 4(%esp), %eax
> > > > > > > movl %eax, 4(%esp)
> > > > > > >
> > > > > > > isn't necessary if incoming arguments are copied to outgoing
> > > > > > > arguments
> > > > > > > directly.
> > > > > > >
> > > > > > > Add a new target hook, TARGET_GET_SMALL_INTEGER_ARGUMENT_VALUE,
> > > > > > > defaulting
> > > > > > > to return nullptr. If the new target hook returns non-nullptr,
> > > > > > > use it to
> > > > > > > get the outgoing small integer argument. The x86 target hook
> > > > > > > returns the
> > > > > > > value of the corresponding incoming argument as int if it can be
> > > > > > > used as
> > > > > > > the outgoing argument. If callee is a global function, we always
> > > > > > > properly
> > > > > > > extend the incoming small integer arguments in callee. If callee
> > > > > > > is a
> > > > > > > local function, since DECL_ARG_TYPE has the original small
> > > > > > > integer type,
> > > > > > > we will extend the incoming small integer arguments in callee if
> > > > > > > needed.
> > > > > > > It is safe only if
> > > > > > >
> > > > > > > 1. Caller and callee are not nested functions.
> > > > > > > 2. Caller and callee use the same ABI.
> > > > > >
> > > > > > How do these influence the value? TARGET_PROMOTE_PROTOTYPES
> > > > > > should apply to all of them, no?
> > > > >
> > > > > When the arguments are passed in different registers in different
> > > > > ABIs,
> > > > > we have to copy them anyway.
> > > >
> > > > But optimization can elide copies easily, but not easily elide
> > > > sign-/zero-extensions.
> > >
> > > What I meant was that caller and callee have different ABIs.
> > > Optimizer can't elide copies since incoming arguments and outgoing
> > > arguments are in different registers. They have to be moved.
> > >
> > > > > >
> > > > > > > 3. The incoming argument and the outgoing argument are in the same
> > > > > > > location.
> > > > > >
> > > > > > Why's that? Can't we move them but still elide the
> > > > > > sign-/zero-extension?
> > > > >
> > > > > If they aren't in the same locations, we have to move them anyway.
> > > > > This patch tries to avoid necessary moves of incoming arguments to
> > > > > outgoing arguments.
> > > >
> > > > That's not exactly how you presented it, but you convenitently used
> > > > x86 stack argument passing. That might be difficult to elide, but is
> > > > also uncommon for "small integer types" - does the same issue not
> > > > apply to other arguments passed on the stack as well?
> > >
> > > It applies to both passing in registers and on stack. It is an issue
> > > only
> > > for small integer types due to sign-/zero-extensions at call sites. My
> > > patch elides sign-/zero-extensions when incoming arguments and outgoing
> > > arguments are unchanged in the exactly same location, in register or on
> > > stack.
> >
> > Is it possible to dissect this from TARGET_PROMOTE_PROTOTYPES then?
> > That is, this should also work for the case prototypes are not promoted and
> > for modes larger than SImode, even BLKmode.
> >
> > Richard.
>
> Arguments which don't need promotion, including large arguments, are already
> working today. The only issue is sign-/zero-extension of small outgoing
> integer
> arguments on x86. My patch removes unnecessary sign-/zero-extensions. See:
So we're back to square one ... why restrict this sign-/zero-extension
elimination
to the case where you can also elide the copy?
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14907
>
> for more discussions.
>
> --
> H.J.
