[Bug target/113233] New: LoongArch: target options from LTO objects not respected during linking

[Bug target/113233] New: LoongArch: target options from LTO objects not respected during linking

[yangyujie at loongson dot cn]

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

            Bug ID: 113233
           Summary: LoongArch: target options from LTO objects not
                    respected during linking
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: yangyujie at loongson dot cn
  Target Milestone: ---

Compiling LTO objects with certain target options like -march=, -msimd= have no
effect on the final linked binary, since COLLECT_GCC_OPTIONS from the "linker
GCC" driver always overrides these options.

For instance, running the following command:

$ gcc -S -o- -xc - -msimd=lasx  -O3 <<< "void m2 (float *a, int n) { for (int i
= 0; i < n; i++) a[i] += 1; }" | grep vfadd

outputs SIMD instructions (as enabled by -msimd=lasx):

        xvfadd.s        $xr4,$xr4,$xr0
        xvfadd.s        $xr2,$xr2,$xr0
        xvfadd.s        $xr1,$xr1,$xr0
        xvfadd.s        $xr3,$xr3,$xr0
        vfadd.s $vr1,$vr1,$vr0
        vfadd.s $vr1,$vr1,$vr0
        vfadd.s $vr1,$vr1,$vr0
        vfadd.s $vr1,$vr1,$vr0
        vfadd.s $vr1,$vr1,$vr0
        vfadd.s $vr1,$vr1,$vr0
        vfadd.s $vr0,$vr1,$vr0

However, LTO generates code according to the compiler's default config
(-msimd=none).

Running:
$ gcc -flto -c -o test.o -xc - -msimd=lasx -O3 <<< "void m2 (float *a, int n) {
for (int i = 0; i < n; i++) a[i] += 1; }"

and then:
$ gcc -S -o- -xlto test.o | grep vfadd

outputs nothing, indicating that the final code generation have LSX/LASX
disabled.

While:
$ gcc -S -o- -xlto test.o -mlasx | grep vfadd

outputs the same "vfadd" / "xvfadd" instructions as above.

-------------------------------------------------------------------------------------
Proposed solution: implement option save/restore to enable LTO option
streaming.
-------------------------------------------------------------------------------------

[Bug target/113233] LoongArch: target options from LTO objects not respected during linking

[yangyujie at loongson dot cn]

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

--- Comment #1 from Yang Yujie <yangyujie at loongson dot cn> ---
I've already made a patch for this, will push it to gcc-patches@gcc.gnu.org
later.

[Bug target/113233] LoongArch: target options from LTO objects not respected during linking

[xry111 at gcc dot gnu.org]

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

Xi Ruoyao <xry111 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |loongarch*
   Last reconfirmed|                            |2024-01-04
                 CC|                            |xry111 at gcc dot gnu.org
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW

--- Comment #2 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
Confirm.  But option save/restore has been always implemented:

    .section    .gnu.lto_.opts,"",@progbits
    .ascii  "'-fno-openmp' '-fno-openacc' '-fno-pie' '-fcf-protection"
    .ascii  "=none' '-mabi=lp64d' '-march=loongarch64' '-mfpu=64' '-m"
    .ascii  "simd=lasx' '-mcmodel=normal' '-mtune=loongarch64' '-flto"
    .ascii  "'\000"

So -msimd=lasx is correctly recorded.  Not sure why it does not work.

Re: [Bug target/113233] LoongArch: target options from LTO objects not respected during linking

[Jan Hubicka]

> Confirm.  But option save/restore has been always implemented:
> 
>     .section    .gnu.lto_.opts,"",@progbits
>     .ascii  "'-fno-openmp' '-fno-openacc' '-fno-pie' '-fcf-protection"
>     .ascii  "=none' '-mabi=lp64d' '-march=loongarch64' '-mfpu=64' '-m"
>     .ascii  "simd=lasx' '-mcmodel=normal' '-mtune=loongarch64' '-flto"
>     .ascii  "'\000"
> 
> So -msimd=lasx is correctly recorded.  Not sure why it does not work.

With LTO we need to mix code compiled with different sets of options.
For this reason we imply for every function defition and optimization
and target attribute which record the flags.  So it seems target
attribute is likely broken for this flag.

[Bug target/113233] LoongArch: target options from LTO objects not respected during linking

[hubicka at ucw dot cz]

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

--- Comment #3 from Jan Hubicka <hubicka at ucw dot cz> ---
> Confirm.  But option save/restore has been always implemented:
> 
>     .section    .gnu.lto_.opts,"",@progbits
>     .ascii  "'-fno-openmp' '-fno-openacc' '-fno-pie' '-fcf-protection"
>     .ascii  "=none' '-mabi=lp64d' '-march=loongarch64' '-mfpu=64' '-m"
>     .ascii  "simd=lasx' '-mcmodel=normal' '-mtune=loongarch64' '-flto"
>     .ascii  "'\000"
> 
> So -msimd=lasx is correctly recorded.  Not sure why it does not work.

With LTO we need to mix code compiled with different sets of options.
For this reason we imply for every function defition and optimization
and target attribute which record the flags.  So it seems target
attribute is likely broken for this flag.

[Bug target/113233] LoongArch: target options from LTO objects not respected during linking

[xry111 at gcc dot gnu.org]

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

--- Comment #4 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
(In reply to Jan Hubicka from comment #3)
> > Confirm.  But option save/restore has been always implemented:
> > 
> >     .section    .gnu.lto_.opts,"",@progbits
> >     .ascii  "'-fno-openmp' '-fno-openacc' '-fno-pie' '-fcf-protection"
> >     .ascii  "=none' '-mabi=lp64d' '-march=loongarch64' '-mfpu=64' '-m"
> >     .ascii  "simd=lasx' '-mcmodel=normal' '-mtune=loongarch64' '-flto"
> >     .ascii  "'\000"
> > 
> > So -msimd=lasx is correctly recorded.  Not sure why it does not work.
> 
> With LTO we need to mix code compiled with different sets of options.
> For this reason we imply for every function defition and optimization
> and target attribute which record the flags.  So it seems target
> attribute is likely broken for this flag.

Target attribute is not implemented for LoongArch.  And I don't think it's a
good idea to implement it in stage 3.

[Bug target/113233] LoongArch: target options from LTO objects not respected during linking

[xry111 at gcc dot gnu.org]

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

--- Comment #5 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
Note that x86 also passes the recorded -mavx2 etc. to lto1.

[Bug target/113233] LoongArch: target options from LTO objects not respected during linking

[yangyujie at loongson dot cn]

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

--- Comment #6 from Yang Yujie <yangyujie at loongson dot cn> ---
(In reply to Xi Ruoyao from comment #4)
> (In reply to Jan Hubicka from comment #3)
> > > Confirm.  But option save/restore has been always implemented:
> > > 
> > >     .section    .gnu.lto_.opts,"",@progbits
> > >     .ascii  "'-fno-openmp' '-fno-openacc' '-fno-pie' '-fcf-protection"
> > >     .ascii  "=none' '-mabi=lp64d' '-march=loongarch64' '-mfpu=64' '-m"
> > >     .ascii  "simd=lasx' '-mcmodel=normal' '-mtune=loongarch64' '-flto"
> > >     .ascii  "'\000"
> > > 
> > > So -msimd=lasx is correctly recorded.  Not sure why it does not work.
> > 
> > With LTO we need to mix code compiled with different sets of options.
> > For this reason we imply for every function defition and optimization
> > and target attribute which record the flags.  So it seems target
> > attribute is likely broken for this flag.
> 
> Target attribute is not implemented for LoongArch.  And I don't think it's a
> good idea to implement it in stage 3.

Yes, target attribute may have to wait.  But save/restore can be implemented
without target attributes of functions.  By marking options as "Save" in .opt
or implementing custom TARGET_OPTION_{SAVE,RESTORE} hooks, we can stream the
target configuration (which may come from the command line / the target
attributes / #pragma GCC target) into the per-function LTO bytecode, so that
lto1 can pick up and use them later when generating code for each function.

[Bug target/113233] LoongArch: target options from LTO objects not respected during linking

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by LuluCheng <chenglulu@gcc.gnu.org>:

https://gcc.gnu.org/g:ea2a9c76a1dcffbbec6e53655bef9236d3a8e691

commit r14-7134-gea2a9c76a1dcffbbec6e53655bef9236d3a8e691
Author: Yang Yujie <yangyujie@loongson.cn>
Date:   Thu Jan 11 09:07:10 2024 +0800

    LoongArch: Implement option save/restore

    LTO option streaming and target attributes both require per-function
    target configuration, which is achieved via option save/restore.

    We implement TARGET_OPTION_{SAVE,RESTORE} to switch the la_target
    context in addition to other automatically maintained option states
    (via the "Save" option property in the .opt files).

    Tested on loongarch64-linux-gnu without regression.

            PR target/113233

    gcc/ChangeLog:

            * config/loongarch/genopts/loongarch.opt.in: Mark options with
            the "Save" property.
            * config/loongarch/loongarch.opt: Same.
            * config/loongarch/loongarch-opts.cc: Refresh -mcmodel= state
            according to la_target.
            * config/loongarch/loongarch.cc: Implement TARGET_OPTION_{SAVE,
            RESTORE} for the la_target structure; Rename option conditions
            to have the same "la_" prefix.
            * config/loongarch/loongarch.h: Same.

[Bug target/113233] LoongArch: target options from LTO objects not respected during linking

[cvs-commit at gcc dot gnu.org]

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

--- Comment #8 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-13 branch has been updated by LuluCheng
<chenglulu@gcc.gnu.org>:

https://gcc.gnu.org/g:4736b317047ae6b04f7609843f21cb68fef6a0c1

commit r13-8545-g4736b317047ae6b04f7609843f21cb68fef6a0c1
Author: Lulu Cheng <chenglulu@loongson.cn>
Date:   Fri Mar 15 16:23:05 2024 +0800

    LoongArch: gcc13: Implement option save/restore.

    LTO option streaming and target attributes both require per-function
    target configuration, which is achieved via option save/restore.

    We implement TARGET_OPTION_{SAVE,RESTORE} to switch the la_target
    context in addition to other automatically maintained option states
    (via the "Save" option property in the .opt files).

            PR target/113233

    gcc/ChangeLog:

            * config/loongarch/genopts/loongarch.opt.in: Mark options with
            the "Save" property.
            * config/loongarch/loongarch-opts.cc
            (loongarch_update_gcc_opt_status): Update the value of the
            la_target to global_options.
            * config/loongarch/loongarch-opts.h
            (loongarch_update_gcc_opt_status): Add a function declaration.
            * config/loongarch/loongarch.cc
            (loongarch_option_override_internal): Call the function
            loongarch_update_gcc_opt_status.
            (loongarch_option_save): New functions.
            (loongarch_option_restore): Likewise.
            (TARGET_OPTION_SAVE): Define macro.
            (TARGET_OPTION_RESTORE): Likewise.
            * config/loongarch/loongarch.opt: Regenerate.

    (cherry picked from commit ea2a9c76a1dcffbbec6e53655bef9236d3a8e691)

[Bug target/113233] LoongArch: target options from LTO objects not respected during linking

[cvs-commit at gcc dot gnu.org]

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

--- Comment #9 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-12 branch has been updated by LuluCheng
<chenglulu@gcc.gnu.org>:

https://gcc.gnu.org/g:bf0b32d7929f8b4b15b21658d572b89ded03d8f8

commit r12-10303-gbf0b32d7929f8b4b15b21658d572b89ded03d8f8
Author: Lulu Cheng <chenglulu@loongson.cn>
Date:   Fri Mar 15 16:41:20 2024 +0800

    LoongArch: gcc12: Implement option save/restore.

    LTO option streaming and target attributes both require per-function
    target configuration, which is achieved via option save/restore.

    We implement TARGET_OPTION_{SAVE,RESTORE} to switch the la_target
    context in addition to other automatically maintained option states
    (via the "Save" option property in the .opt files).

            PR target/113233

    gcc/ChangeLog:

            * config/loongarch/genopts/loongarch.opt.in: Mark options with
            the "Save" property.
            * config/loongarch/loongarch-opts.cc
            (loongarch_update_gcc_opt_status): Update the value of the
            la_target to global_options.
            * config/loongarch/loongarch-opts.h
            (loongarch_update_gcc_opt_status): Add a function declaration.
            * config/loongarch/loongarch.cc
            (loongarch_option_override_internal): Call the function
            loongarch_update_gcc_opt_status.
            (loongarch_option_save): New functions.
            (loongarch_option_restore): Likewise.
            (TARGET_OPTION_SAVE): Define macro.
            (TARGET_OPTION_RESTORE): Likewise.
            * config/loongarch/loongarch.opt: Regenerate.

    (cherry picked from commit ea2a9c76a1dcffbbec6e53655bef9236d3a8e691)

[Bug target/113233] LoongArch: target options from LTO objects not respected during linking

[xry111 at gcc dot gnu.org]

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

Xi Ruoyao <xry111 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |12.4
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED

--- Comment #10 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
So fixed for all branches.

[Bug target/113233] LoongArch: target options from LTO objects not respected during linking

[xry111 at gcc dot gnu.org]

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

Xi Ruoyao <xry111 at gcc dot gnu.org> changed:

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

--- Comment #11 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
I misunderstood the last change and this is not fixed:
https://gcc.gnu.org/pipermail/gcc-patches/2024-April/648921.html

[Bug target/113233] LoongArch: target options from LTO objects not respected during linking

[xry111 at gcc dot gnu.org]

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

Xi Ruoyao <xry111 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|12.4                        |---

[Bug target/113233] LoongArch: target options from LTO objects not respected during linking

[cvs-commit at gcc dot gnu.org]

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

--- Comment #12 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by LuluCheng <chenglulu@gcc.gnu.org>:

https://gcc.gnu.org/g:8657d76d583f0f87000e9003ba75922f2bbe4455

commit r14-9866-g8657d76d583f0f87000e9003ba75922f2bbe4455
Author: Yang Yujie <yangyujie@loongson.cn>
Date:   Mon Apr 8 16:45:13 2024 +0800

    LoongArch: Enable switchable target

    This patch fixes the back-end context switching in cases where functions
    should be built with their own target contexts instead of the
    global one, such as LTO linking and functions with target attributes (TBD).

            PR target/113233

    gcc/ChangeLog:

            * config/loongarch/loongarch.cc (loongarch_reg_init):
            Reinitialize the loongarch_regno_mode_ok cache.
            (loongarch_option_override): Same.
            (loongarch_save_restore_target_globals): Restore target globals.
            (loongarch_set_current_function): Restore the target contexts
            for functions.
            (TARGET_SET_CURRENT_FUNCTION): Define.
            * config/loongarch/loongarch.h (SWITCHABLE_TARGET): Enable
            switchable target context.
            * config/loongarch/loongarch-builtins.cc (loongarch_init_builtins):
            Initialize all builtin functions at startup.
            (loongarch_expand_builtin): Turn assertion of builtin availability
            into a test.

    gcc/testsuite/ChangeLog:

            * lib/target-supports.exp: Define condition loongarch_sx_as.
            * gcc.dg/lto/pr113233_0.c: New test.

[Bug target/113233] LoongArch: target options from LTO objects not respected during linking

[xry111 at gcc dot gnu.org]

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

--- Comment #13 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
Will we back port the fix to 13 and 12?

[Bug target/113233] LoongArch: target options from LTO objects not respected during linking

[yangyujie at loongson dot cn]

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

--- Comment #14 from Yang Yujie <yangyujie at loongson dot cn> ---
Is it not really necessary for now, since there is no LSX/LASX support in GCC
12 / 13?

[Bug target/113233] LoongArch: target options from LTO objects not respected during linking

[xry111 at gcc dot gnu.org]

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

Xi Ruoyao <xry111 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|---                         |14.0

--- Comment #15 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
(In reply to Yang Yujie from comment #14)
> Is it not really necessary for now, since there is no LSX/LASX support in
> GCC 12 / 13?

So closing the ticket as fixed.