On Tue, Nov 5, 2024 at 10:57 AM Jeff Law <jeffreya...@gmail.com> wrote:
>
>
>
> On 11/4/24 7:52 PM, H.J. Lu wrote:
> > On Tue, Nov 5, 2024 at 8:48 AM Jeff Law <jeffreya...@gmail.com> wrote:
> >>
> >>
> >>
> >> On 11/4/24 5:42 PM, H.J. Lu wrote:
> >>> On Tue, Nov 5, 2024 at 8:07 AM Jeff Law <jeffreya...@gmail.com> wrote:
> >>>>
> >>>>
> >>>>
> >>>> On 11/1/24 4:32 PM, H.J. Lu 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 and outgoing arguments are the
> >>>>> same. Use unpromoted incoming integer arguments as outgoing arguments
> >>>>> if incoming integer arguments are the same as outgoing arguments to
> >>>>> avoid unnecessary integer promotion.
> >>>> Is there a particular reason x86 can't use the same mechanisms that
> >>>
> >>> Other targets define TARGET_PROMOTE_PROTOTYPES to return false
> >>> to avoid this issue. Changing x86 TARGET_PROMOTE_PROTOTYPES
> >>> to return false will break LLVM which assumes that incoming char/short
> >>> arguments on x86 are always extended to int. The following targets
> >> Then my suggestion would be to cover this in REE somehow. We started
> >> looking at that a couple years ago and set it aside. But the basic
> >> idea was to expose the ABI guarantees to REE, then let REE do its thing.
> >>
> >> Jeff
> >>
> >
> > For
> >
> > extern int baz (char c1);
> >
> > int
> > foo (char c1)
> > {
> > return baz (c1);
> > }
> >
> > on i386, we get these
> >
> > (insn 7 4 8 2 (set (reg:SI 0 ax [orig:102 c1 ] [102])
> > (sign_extend:SI (mem/c:QI (plus:SI (reg/f:SI 7 sp)
> > (const_int 4 [0x4])) [0 c1+0 S1 A32]))) "x.c":6:10
> > 190 {extendqisi2}
> > (expr_list:REG_EQUIV (mem:SI (reg/f:SI 16 argp) [0 S4 A32])
> > (nil)))
> > (insn 8 7 9 2 (set (mem:SI (plus:SI (reg/f:SI 7 sp)
> > (const_int 4 [0x4])) [0 S4 A32])
> > (reg:SI 0 ax [orig:102 c1 ] [102])) "x.c":6:10 95 {*movsi_internal}
> > (nil))
> > (call_insn/j 9 8 10 2 (set (reg:SI 0 ax)
> > (call (mem:QI (symbol_ref:SI ("baz") [flags 0x41]
> > <function_decl 0x7f27347aae00
> > baz>) [0 baz S1 A8])
> > (const_int 4 [0x4]))) "x.c":6:10 1420 {*sibcall_value}
> > (expr_list:REG_CALL_DECL (symbol_ref:SI ("baz") [flags 0x41]
> > <function_decl 0x7f273
> > 47aae00 baz>)
> > (nil))
> > (expr_list:SI (use (mem:SI (reg/f:SI 16 argp) [0 S4 A32]))
> > (nil)))
> >
> > before REE. How should REE work to elimate
> >
> > (insn 7 4 8 2 (set (reg:SI 0 ax [orig:102 c1 ] [102])
> > (sign_extend:SI (mem/c:QI (plus:SI (reg/f:SI 7 sp)
> > (const_int 4 [0x4])) [0 c1+0 S1 A32]))) "x.c":6:10
> > 190 {extendqisi2}
> > (expr_list:REG_EQUIV (mem:SI (reg/f:SI 16 argp) [0 S4 A32])
> > (nil)))
> > (insn 8 7 9 2 (set (mem:SI (plus:SI (reg/f:SI 7 sp)
> > (const_int 4 [0x4])) [0 S4 A32])
> > (reg:SI 0 ax [orig:102 c1 ] [102])) "x.c":6:10 95 {*movsi_internal}
> > (nil))
> You'll have to write code to describe the ABI how the values in question
> are already extended to REE. It's not going to "just work", you'll have
> to do some development. I'm not inclined to ACK the expansion patch at
> this time given we've got multiple ways to handle extension removal.
>
For char and short parameters, x86 ABI leaves the upper bits in
32 bit fields undefined. If the outgoing arguments are the same
as the incoming arguments, there is no need to extend outgoing
arguments. Also ABI info isn't available in REE. I am not sure if
REE is the best fit here.
--
H.J.
