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).
