[Bug target/95134] New: -ffreestanding should avoid libcall

[Bug target/95134] New: -ffreestanding should avoid libcall

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95134

            Bug ID: 95134
           Summary: -ffreestanding should avoid libcall
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: hjl.tools at gmail dot com
                CC: ubizjak at gmail dot com
  Target Milestone: ---
            Target: i386, x86-64

[hjl@gnu-cfl-2 freestand]$ cat x.i 
struct foo
{
  char array[257];
};

extern struct foo x;

void
func (struct foo i)
{
  x = i;
}
[hjl@gnu-cfl-2 freestand]$ make x.s
/export/build/gnu/tools-build/gcc-gitlab-debug/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/tools-build/gcc-gitlab-debug/build-x86_64-linux/gcc/ -O2 -W
-ffreestanding -mtune=pentium -m32 -S x.i
[hjl@gnu-cfl-2 freestand]$ cat x.s
        .file   "x.i"
        .text
        .p2align 4
        .globl  func
        .type   func, @function
func:
.LFB0:
        .cfi_startproc
        subl    $16, %esp
        .cfi_def_cfa_offset 20
        pushl   $257
        .cfi_def_cfa_offset 24
        leal    24(%esp), %eax
        pushl   %eax
        .cfi_def_cfa_offset 28
        pushl   $x
        .cfi_def_cfa_offset 32
        call    memcpy
        addl    $28, %esp
        .cfi_def_cfa_offset 4
        ret
        .cfi_endproc
.LFE0:
        .size   func, .-func
        .ident  "GCC: (GNU) 11.0.0 20200514 (experimental)"
        .section        .note.GNU-stack,"",@progbits
[hjl@gnu-cfl-2 freestand]$ 

x86 backend should avoid libcall if flag_hosted is false.

[Bug target/95134] -ffreestanding should avoid libcall

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95134

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
This is documented this way and has been true for years and documented for
years.

[Bug target/95134] Add a target option to avoid libcall

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95134

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|-ffreestanding should avoid |Add a target option to
                   |libcall                     |avoid libcall
             Status|RESOLVED                    |REOPENED
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2020-05-14
         Resolution|WONTFIX                     |---

--- Comment #2 from H.J. Lu <hjl.tools at gmail dot com> ---
Since -ffreestanding can generate libcall, we should add a target option to
avoid libcall.

[Bug target/95134] Add a target option to avoid libcall

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95134

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |WONTFIX
             Status|REOPENED                    |RESOLVED

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to H.J. Lu from comment #2)
> Since -ffreestanding can generate libcall, we should add a target option to
> avoid libcall.

-minline-all-stringops
-mmemcpy-strategy=
-mmemset-strategy=

From
https://gcc.gnu.org/onlinedocs/gcc-10.1.0/gcc/Standards.html#index-ffreestanding
:
"Most of the compiler support routines used by GCC are present in libgcc, but
there are a few exceptions. GCC requires the freestanding environment provide
memcpy, memmove, memset and memcmp. Finally, if __builtin_trap is used, and the
target does not implement the trap pattern, then GCC emits a call to abort.

"

[Bug target/95134] Add a target option to avoid libcall

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95134

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
https://gcc.gnu.org/onlinedocs/gcc-4.0.4/gcc/Standards.html#index-ffreestanding-58

[Bug target/95134] Add a target option to avoid libcall

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95134

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|WONTFIX                     |---
             Status|RESOLVED                    |NEW
           Assignee|unassigned at gcc dot gnu.org      |hjl.tools at gmail dot com

--- Comment #5 from H.J. Lu <hjl.tools at gmail dot com> ---
Created attachment 48538
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48538&action=edit
A patch to add -mavoid-libcall

The -mgeneral-regs-only option generates code that uses only the
general-purpose registers.  It prevents the compiler from using vector
registers.  But GCC may still generate calls to memcpy, memmove, memset
and memcmp library functions.  In the GNU C library, these library
functions are implementated with vector registers, which makes the
-mgeneral-regs-only option less effective.  The new -mavoid-libcall
option expands memcpy, memmove and memset into REP MOVSB and REP STOSB
sequence.  This option can be further enhanced with a cmpmem pattern
to expand memcmp into REP CMPSB sequence in the future.

[Bug target/95134] Add a target option to avoid libcall

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95134

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |WONTFIX
             Status|NEW                         |RESOLVED

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
As decided by Uros (I agree).