On Thu, Sep 07, 2023 at 07:54:41PM +0800, Yang Yujie wrote:
> On Thu, Sep 07, 2023 at 05:47:36PM +0800, Xi Ruoyao wrote:
> > On Thu, 2023-09-07 at 17:31 +0800, Yang Yujie wrote:
> > > > This is bad. It makes BOOT_CFLAGS=-mlasx or CFLAGS_FOR_TARGET=-mlasx
> > > > silently ignored so we cannot test a LSX/LASX or vectorizer change with
> > > > them.
> > > >
> > > > Why do we need to purge all user-specified -m options here?
> > >
> > > Yes, that is an issue that I haven't considered.
> > >
> > > The purge rules (self_specs) exist to clean up the driver-generated
> > > canonical option tuple. These options are generated before to the
> > > injection of library-building options from --with-multilib-{list,default}.
> > > They are dependent on the default GCC settings and may not be safely
> > > overriden by any injected individual options, so we choose to start
> > > over with a purge.
> > >
> > > Working on a patch now, Thanks!
> >
> > I've made some local experiment too, I think we can add a "-mbuild-
> > multilib" option which does nothing but in the hacked spec we can wrap
> > the line in %{mbuild-multilib:...}:
> >
> > %{mbuild-multilib:%<march=* %<mtune=* %<mcmodel=* %<mfpu=* %<msimd=*
> > %{mabi=lp64d:-march=la464 -mno-strict-align -msimd=lsx}
> > %{mabi=lp64s:-march=abi-default -mfpu=32}}
> >
> > Then we can use -mbuild-multilib -mabi=lp64d for non-default multilibs
> > (or all multilibs unless --disable-multilib?). In the document we can
> > just document mbuild-multilib as "internal use only".
> >
> >
> > --
> > Xi Ruoyao <xry...@xry111.site>
> > School of Aerospace Science and Technology, Xidian University
>
>
> My idea is to move these options out of self_spec by defining a new spec
> rule $(early_self_spec), so that they get processed by the driver before
> the canonicalization.
>
> This also solves the problem that one cannot use -m[no-]lsx/-m[no-]lasx
> in --with-multilib-list (because they are driver-only options that are
> only recognized during the canonicalization).
Some updates on this issue -- With some experiments, I think that the most
practical way to solve this completely might still involve a symmetric
multilib build (where the toplevels are not built and installed). Because
as you proposed, we need to inject an option like "-mbuild-multilib" (maybe
"-fmultiflags" for this purpose) somewhere to distinguish bootstrapping from
building libraries, but overriding the spec seems to always affect both cases.
The next option I can think of would be MULTILIB_EXTRA_OPTS, where -fmultiflags
fit in nicely. However, these options won't reach the toplevel builds, and
tweaking config-ml.in for getting it there would be quite tedious and perhaps
unreliable:
--------
diff --git a/config-ml.in b/config-ml.in
index ad0db078171..ce7f07b94a7 100644
--- a/config-ml.in
+++ b/config-ml.in
@@ -228,6 +228,9 @@ for i in `${CC-gcc} --print-multi-lib 2>/dev/null`; do
fi
done
+# Do not apply MULTILIB_EXTRA_OPTS to the toplevel by default.
+ml_toplevel_apply_extra_opts=no
+
# Target libraries are configured for the host they run on, so we check
# $host here, not $target.
@@ -577,6 +580,19 @@ cat >>Multi.tem <<\EOF
fi
EOF
+# Apply MULTILIB_EXTRA_OPTS to the toplevel build.
+if [ "${ml_toplevel_apply_extra_opts}" = yes ]; then
+cat >>Multi.tem <<\EOF
+
+$(foreach i,$(shell $(CC) --print-multi-lib), \
+$(if $(i:.;%=),,$(eval ml_extra_opts := $(subst @, -,$(i:.;%=%)))))
+
+$(foreach ml_flags, CFLAGS CCASFLAGS CXXFLAGS FCFLAGS FFLAGS \
+ ADAFLAGS GOCFLAGS GDCFLAGS CXXFLAGS LIBCFLAGS LIBCXXFLAGS \
+ LDFLAGS MLTIFLAGS, $(eval override $(ml_flags) += $(ml_extra_opts)))
+EOF
+fi
+
cat ${Makefile} Multi.tem > Makefile.tem
rm -f ${Makefile} Multi.tem
mv Makefile.tem ${Makefile}
--------
Though this patch works, at least the following additional tweaks has to
be done to the toplevel to maintain a correct build / regtest / install
workflow:
- the C++ headers' install path (fixed temporarily && not very elegant)
- the fortran header path before regtests
Compared to patching for each library individually, I'd rather choose something
less painful -- not building the toplevel could save the most effort because all
the facilities are guaranteed to be present for all multilib variants.
As for the layout change of lib/gcc/<arch>/<version> directory after applying
the symmetric multilib patch, I believe the inconvenience caused would be
minimal,
since multisubdir within that directory is private to each gcc instance. If
someone
really has a script that depend on libgcc's path, I would suggest using
--print-multi-dir and --print-file-name=libgcc.a, for you cannot assume the
behavior of the GCC driver without knowing which spec file it is loading
anyways.
(We'd still be keeping --with-abi=* obsolete. That's a good idea, thanks.)
Yujie
