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

["yangyujie at loongson dot cn" <gcc-bugzilla@gcc.gnu.org>]

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.