Re: [PATCH v3 1/4] LoongArch: improved target configuration interface
On Sat, 2023-09-09 at 14:26 +0800, Yang Yujie wrote: > I remember you were against it because you think non-multilib users > would be punished because the libdir layout changes (no toplevel). > However this directory should be (mostly) private to each gcc instance, > so I don't see real consequences to this unless you have a build script > that relieas on the path of libgcc.a / startfile, which can still (and > should) be revised using $(gcc --print-multi-dir). I guess I can live with it. -- Xi Ruoyao School of Aerospace Science and Technology, Xidian University
Re: [PATCH v3 1/4] LoongArch: improved target configuration interface
On Sat, Sep 09, 2023 at 01:56:57PM +0800, Xi Ruoyao wrote:
> On Sat, 2023-09-09 at 10:46 +0800, Yang Yujie wrote:
> > 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:
>
> I don't think the spec tweak should affect toplevel (or default, if you
> hate the concept of toplevel) library build.
>
> When I build GCC for a specific machine I usually use:
>
> OPT="-O3 -march=native -pipe ..."
> make {STAGE1,BOOT}_CFLAGS="$OPT" {C,CXX}FLAGS_FOR_TARGET="$OPT -g"
>
> If the spec tweak affects the toplevel library build it will eat -march=
> etc. in {C,CXX}FLAGS_FOR_TARGET silently, and I don't want this.
Sorry I didn't make this clear -- Yes, I am removing the spec tweak
*completely*, because I agree it should not affect bootstrapping /
toplevel builds / --disable-multilib builds.
This is achieved by defining MULTILIB_EXTRA_OPTS as -fmultiflags,
which triggers the multilib build options in driver spec rules
-- so nothing happens to the bootstrapping and --disable-multilib
builds.
What I'm explaining is, MULTILIB_EXTRA_OPTS won't be nicely received
by the toplevel (which is exactly the purpose), so in this solution,
multilib-enabled builds still have to exclude the toplevel. This means
I will have to bring back (at least part of) my v1 patch:
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/627275.html
I remember you were against it because you think non-multilib users
would be punished because the libdir layout changes (no toplevel).
However this directory should be (mostly) private to each gcc instance,
so I don't see real consequences to this unless you have a build script
that relieas on the path of libgcc.a / startfile, which can still (and
should) be revised using $(gcc --print-multi-dir).
> --disable-multilib *should just work*. Why should a non-multilib user
> be punished by the cost of supporting the complex multilib
> configuration, esp. today most LoongArch users don't need multilib at
> all?
It should *just work*. I am testing the new patch and will deliver it
as soon as all the test passes.
Re: [PATCH v3 1/4] LoongArch: improved target configuration interface
On Sat, 2023-09-09 at 10:46 +0800, Yang Yujie wrote:
> 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:
I don't think the spec tweak should affect toplevel (or default, if you
hate the concept of toplevel) library build.
When I build GCC for a specific machine I usually use:
OPT="-O3 -march=native -pipe ..."
make {STAGE1,BOOT}_CFLAGS="$OPT" {C,CXX}FLAGS_FOR_TARGET="$OPT -g"
If the spec tweak affects the toplevel library build it will eat -march=
etc. in {C,CXX}FLAGS_FOR_TARGET silently, and I don't want this.
Or at least it should not affect --disable-multilib (IMO with --disable-
multilib the spec hack should be disabled completely). Note that for --
enable-multilib we may use --with-default-multilib=lp64d/march=native,
but (1) this is hard to remember (2) this is not usable with --disable-
multilib.
--disable-multilib *should just work*. Why should a non-multilib user
be punished by the cost of supporting the complex multilib
configuration, esp. today most LoongArch users don't need multilib at
all?
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
Re: [PATCH v3 1/4] LoongArch: improved target configuration interface
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:% > %{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
> > 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// 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
Re: [PATCH v3 1/4] LoongArch: improved target configuration interface
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:% %{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
> 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).
Re: [PATCH v3 1/4] LoongArch: improved target configuration interface
On Thu, 2023-09-07 at 17:47 +0800, Xi Ruoyao wrote:
/* snip */
> 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:% %{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
typo, should be removed
> (or all multilibs unless --disable-multilib?). In the document we can
> just document mbuild-multilib as "internal use only".
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
Re: [PATCH v3 1/4] LoongArch: improved target configuration interface
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:%
School of Aerospace Science and Technology, Xidian University
Re: [PATCH v3 1/4] LoongArch: improved target configuration interface
> 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!
Yujie
Re: [PATCH v3 1/4] LoongArch: improved target configuration interface
On Wed, 2023-09-06 at 09:04 +0800, Yang Yujie wrote:
> On Tue, Sep 05, 2023 at 09:31:56PM +0800, Xi Ruoyao wrote:
> > On Thu, 2023-08-31 at 20:48 +0800, Yang Yujie wrote:
> > > * Support options for LoongArch SIMD extensions:
> > > new configure options --with-simd={none,lsx,lasx};
> > > new compiler option -msimd={none,lsx,lasx};
> > > new driver options -m[no]-l[a]sx.
> >
> > Hmm... In my build (a cross compiler configured with
> > ../gcc/configure --
> > target=loongarch64-linux-gnu --with-system-zlib) I have:
> >
> > $ cat lasx.c
> > int x __attribute__((vector_size(32)));
> > int y __attribute__((vector_size(32)));
> > void test(void) { x += y; }
> > $ gcc/cc1 lasx.c -msimd=lasx -o- -nostdinc -mexplicit-relocs -O2
> >
> > ... ...
> >
> > pcalau12i $r12,%pc_hi20(.LANCHOR0)
> > addi.d $r12,$r12,%pc_lo12(.LANCHOR0)
> > xvld$xr0,$r12,0
> > xvld$xr1,$r12,32
> > xvadd.w $xr0,$xr0,$xr1
> > xvst$xr0,$r12,0
> > jr $r1
> >
> > ... ...
> >
> > This seems perfectly fine. But:
> >
> > $ gcc/xgcc -B gcc lasx.c -mlasx -o- -nostdinc -mexplicit-relocs -O2
> > -S
> >
> > ... ...
> >
> > test:
> > .LFB0 = .
> > pcalau12i $r12,%pc_hi20(.LANCHOR0)
> > addi.d $r12,$r12,%pc_lo12(.LANCHOR0)
> > addi.d $r3,$r3,-16
> > .LCFI0 = .
> > st.d$r23,$r3,8
> > .LCFI1 = .
> > ldptr.w $r7,$r12,0
> > ldptr.w $r23,$r12,32
> > ldptr.w $r6,$r12,8
> >
> > ... ... (no SIMD instructions)
> >
> > Is this a bug in the driver or I missed something?
> >
> > --
> > Xi Ruoyao
> > School of Aerospace Science and Technology, Xidian University
>
> Maybe you can try deleting gcc/specs first.
>
> It contains a modified version of self_specs that is used for building
> the libraries, which purges all user-specified "-m" options.
> This file is automatically restored prior to "make check*".
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?
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
Re: [PATCH v3 1/4] LoongArch: improved target configuration interface
On Tue, Sep 05, 2023 at 09:31:56PM +0800, Xi Ruoyao wrote:
> On Thu, 2023-08-31 at 20:48 +0800, Yang Yujie wrote:
> > * Support options for LoongArch SIMD extensions:
> > new configure options --with-simd={none,lsx,lasx};
> > new compiler option -msimd={none,lsx,lasx};
> > new driver options -m[no]-l[a]sx.
>
> Hmm... In my build (a cross compiler configured with ../gcc/configure --
> target=loongarch64-linux-gnu --with-system-zlib) I have:
>
> $ cat lasx.c
> int x __attribute__((vector_size(32)));
> int y __attribute__((vector_size(32)));
> void test(void) { x += y; }
> $ gcc/cc1 lasx.c -msimd=lasx -o- -nostdinc -mexplicit-relocs -O2
>
> ... ...
>
> pcalau12i $r12,%pc_hi20(.LANCHOR0)
> addi.d $r12,$r12,%pc_lo12(.LANCHOR0)
> xvld$xr0,$r12,0
> xvld$xr1,$r12,32
> xvadd.w $xr0,$xr0,$xr1
> xvst$xr0,$r12,0
> jr $r1
>
> ... ...
>
> This seems perfectly fine. But:
>
> $ gcc/xgcc -B gcc lasx.c -mlasx -o- -nostdinc -mexplicit-relocs -O2 -S
>
> ... ...
>
> test:
> .LFB0 = .
> pcalau12i $r12,%pc_hi20(.LANCHOR0)
> addi.d $r12,$r12,%pc_lo12(.LANCHOR0)
> addi.d $r3,$r3,-16
> .LCFI0 = .
> st.d$r23,$r3,8
> .LCFI1 = .
> ldptr.w $r7,$r12,0
> ldptr.w $r23,$r12,32
> ldptr.w $r6,$r12,8
>
> ... ... (no SIMD instructions)
>
> Is this a bug in the driver or I missed something?
>
> --
> Xi Ruoyao
> School of Aerospace Science and Technology, Xidian University
Maybe you can try deleting gcc/specs first.
It contains a modified version of self_specs that is used for building
the libraries, which purges all user-specified "-m" options.
This file is automatically restored prior to "make check*".
Yujie
Re: [PATCH v3 1/4] LoongArch: improved target configuration interface
On Thu, 2023-08-31 at 20:48 +0800, Yang Yujie wrote:
> * Support options for LoongArch SIMD extensions:
> new configure options --with-simd={none,lsx,lasx};
> new compiler option -msimd={none,lsx,lasx};
> new driver options -m[no]-l[a]sx.
Hmm... In my build (a cross compiler configured with ../gcc/configure --
target=loongarch64-linux-gnu --with-system-zlib) I have:
$ cat lasx.c
int x __attribute__((vector_size(32)));
int y __attribute__((vector_size(32)));
void test(void) { x += y; }
$ gcc/cc1 lasx.c -msimd=lasx -o- -nostdinc -mexplicit-relocs -O2
... ...
pcalau12i $r12,%pc_hi20(.LANCHOR0)
addi.d $r12,$r12,%pc_lo12(.LANCHOR0)
xvld$xr0,$r12,0
xvld$xr1,$r12,32
xvadd.w $xr0,$xr0,$xr1
xvst$xr0,$r12,0
jr $r1
... ...
This seems perfectly fine. But:
$ gcc/xgcc -B gcc lasx.c -mlasx -o- -nostdinc -mexplicit-relocs -O2 -S
... ...
test:
.LFB0 = .
pcalau12i $r12,%pc_hi20(.LANCHOR0)
addi.d $r12,$r12,%pc_lo12(.LANCHOR0)
addi.d $r3,$r3,-16
.LCFI0 = .
st.d$r23,$r3,8
.LCFI1 = .
ldptr.w $r7,$r12,0
ldptr.w $r23,$r12,32
ldptr.w $r6,$r12,8
... ... (no SIMD instructions)
Is this a bug in the driver or I missed something?
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
Re: [PATCH v3 1/4] LoongArch: improved target configuration interface
在 2023/9/5 下午8:17, Xi Ruoyao 写道: On Tue, 2023-09-05 at 20:01 +0800, chenglulu wrote: 在 2023/9/5 下午7:51, Xi Ruoyao 写道: On Thu, 2023-08-31 at 20:48 +0800, Yang Yujie wrote: /* Note: optimize_size may vary across functions, while -m[no]-memcpy imposes a global constraint. */ #define TARGET_DO_OPTIMIZE_BLOCK_MOVE_P loongarch_do_optimize_block_move_p() -#ifndef HAVE_AS_EXPLICIT_RELOCS -#define HAVE_AS_EXPLICIT_RELOCS 0 -#endif - This causes a build failure with older assembler: options.cc:3040:3: error: 'HAVE_AS_EXPLICIT_RELOCS' was not declared in this scope; did you mean 'TARGET_EXPLICIT_RELOCS'? 3040 | HAVE_AS_EXPLICIT_RELOCS, /* TARGET_EXPLICIT_RELOCS */ | ^~~ | TARGET_EXPLICIT_RELOCS Why this is removed? If this is an unintentionally change I'll add it back. Sorry, this was deleted accidentally. Thanks! Added the 3 lines back at r14-3706. Ok. Thanks!
Re: [PATCH v3 1/4] LoongArch: improved target configuration interface
On Tue, 2023-09-05 at 20:01 +0800, chenglulu wrote: > > 在 2023/9/5 下午7:51, Xi Ruoyao 写道: > > On Thu, 2023-08-31 at 20:48 +0800, Yang Yujie wrote: > > > /* Note: optimize_size may vary across functions, > > > while -m[no]-memcpy imposes a global constraint. */ > > > #define TARGET_DO_OPTIMIZE_BLOCK_MOVE_P > > > loongarch_do_optimize_block_move_p() > > > > > > -#ifndef HAVE_AS_EXPLICIT_RELOCS > > > -#define HAVE_AS_EXPLICIT_RELOCS 0 > > > -#endif > > > - > > This causes a build failure with older assembler: > > > > options.cc:3040:3: error: 'HAVE_AS_EXPLICIT_RELOCS' was not declared in > > this scope; did you mean 'TARGET_EXPLICIT_RELOCS'? > > 3040 | HAVE_AS_EXPLICIT_RELOCS, /* TARGET_EXPLICIT_RELOCS */ > > | ^~~ > > | TARGET_EXPLICIT_RELOCS > > > > Why this is removed? If this is an unintentionally change I'll add it > > back. > > > Sorry, this was deleted accidentally. > > Thanks! Added the 3 lines back at r14-3706. -- Xi Ruoyao School of Aerospace Science and Technology, Xidian University
Re: [PATCH v3 1/4] LoongArch: improved target configuration interface
在 2023/9/5 下午7:51, Xi Ruoyao 写道: On Thu, 2023-08-31 at 20:48 +0800, Yang Yujie wrote: /* Note: optimize_size may vary across functions, while -m[no]-memcpy imposes a global constraint. */ #define TARGET_DO_OPTIMIZE_BLOCK_MOVE_P loongarch_do_optimize_block_move_p() -#ifndef HAVE_AS_EXPLICIT_RELOCS -#define HAVE_AS_EXPLICIT_RELOCS 0 -#endif - This causes a build failure with older assembler: options.cc:3040:3: error: 'HAVE_AS_EXPLICIT_RELOCS' was not declared in this scope; did you mean 'TARGET_EXPLICIT_RELOCS'? 3040 | HAVE_AS_EXPLICIT_RELOCS, /* TARGET_EXPLICIT_RELOCS */ | ^~~ | TARGET_EXPLICIT_RELOCS Why this is removed? If this is an unintentionally change I'll add it back. Sorry, this was deleted accidentally. Thanks!
Re: [PATCH v3 1/4] LoongArch: improved target configuration interface
On Thu, 2023-08-31 at 20:48 +0800, Yang Yujie wrote: > /* Note: optimize_size may vary across functions, > while -m[no]-memcpy imposes a global constraint. */ > #define TARGET_DO_OPTIMIZE_BLOCK_MOVE_P > loongarch_do_optimize_block_move_p() > > -#ifndef HAVE_AS_EXPLICIT_RELOCS > -#define HAVE_AS_EXPLICIT_RELOCS 0 > -#endif > - This causes a build failure with older assembler: options.cc:3040:3: error: 'HAVE_AS_EXPLICIT_RELOCS' was not declared in this scope; did you mean 'TARGET_EXPLICIT_RELOCS'? 3040 | HAVE_AS_EXPLICIT_RELOCS, /* TARGET_EXPLICIT_RELOCS */ | ^~~ | TARGET_EXPLICIT_RELOCS Why this is removed? If this is an unintentionally change I'll add it back. -- Xi Ruoyao School of Aerospace Science and Technology, Xidian University
[PATCH v3 1/4] LoongArch: improved target configuration interface
The configure script and the GCC driver are updated so that
it is easier to customize and control GCC builds for targeting
different LoongArch implementations.
* Make --with-abi obsolete, since it might cause different default ABI
under the same target triplet, which is undesirable. The default ABI
is now purely decided by the target triplet.
* Support options for LoongArch SIMD extensions:
new configure options --with-simd={none,lsx,lasx};
new compiler option -msimd={none,lsx,lasx};
new driver options -m[no]-l[a]sx.
* Enforce the priority of configuration paths (for ={fpu,tune,simd}):
-m > -march-implied > --with- > --with-arch-implied.
* Allow the user to control the compiler options used when building
GCC libraries for each multilib variant via --with-multilib-list
and --with-multilib-default. This could become more useful when
we have 32-bit support later.
Example 1: the following configure option
--with-multilib-list=lp64d/la464/mno-strict-align/msimd=lsx,lp64s/mfpu=32
| || |
-mabi=ABI -march=ARCH a list of other options
(mandatory) (optional) (optional)
builds two sets of libraries:
1. lp64d/base ABI (built with "-march=la464 -mno-strict-align -msimd=lsx")
2. lp64s/base ABI (built with "-march=abi-default -mfpu=32")
Example 2: the following 3 configure options
--with-arch=loongarch64
--with-multilib-list=lp64d,lp64f,lp64s/la464
--with-multilib-default=fixed/mno-strict-align/mfpu=64
|| |
-march=ARCH a list of other options
(optional)(optional)
is equivalent to (in terms of building libraries):
--with-multilib-list=\
lp64d/loongarch64/mno-strict-align/mfpu=64,\
lp64f/loongarch64/mno-strict-align/mfpu=64,\
lp64s/la464
Note:
1. the GCC driver and compiler proper does not support
"-march=fixed". "fixed" that appear here acts as a placeholder for
"use whatever ARCH in --with-arch=ARCH" (or the default value
of --with-arch=ARCH if --with-arch is not explicitly configured).
2. if the ARCH part is omitted, "-march=abi-default"
is used for building all library variants, which
practically means enabling the minimal ISA features
that can support the given ABI.
ChangeLog:
* config-ml.in: Do not build the multilib library variant
that is duplicate with the toplevel one.
gcc/ChangeLog:
* config.gcc: Make --with-abi= obsolete, decide the default ABI
with target triplet. Allow specifying multilib library build
options with --with-multilib-list and --with-multilib-default.
* config/loongarch/t-linux: Likewise.
* config/loongarch/genopts/loongarch-strings: Likewise.
* config/loongarch/loongarch-str.h: Likewise.
* doc/install.texi: Likewise.
* config/loongarch/genopts/loongarch.opt.in: Introduce
-m[no-]l[a]sx options. Only process -m*-float and
-m[no-]l[a]sx in the GCC driver.
* config/loongarch/loongarch.opt: Likewise.
* config/loongarch/la464.md: Likewise.
* config/loongarch/loongarch-c.cc: Likewise.
* config/loongarch/loongarch-cpu.cc: Likewise.
* config/loongarch/loongarch-cpu.h: Likewise.
* config/loongarch/loongarch-def.c: Likewise.
* config/loongarch/loongarch-def.h: Likewise.
* config/loongarch/loongarch-driver.cc: Likewise.
* config/loongarch/loongarch-driver.h: Likewise.
* config/loongarch/loongarch-opts.cc: Likewise.
* config/loongarch/loongarch-opts.h: Likewise.
* config/loongarch/loongarch.cc: Likewise.
* doc/invoke.texi: Likewise.
---
config-ml.in | 10 +
gcc/config.gcc| 379 ++
.../loongarch/genopts/loongarch-strings | 8 +-
gcc/config/loongarch/genopts/loongarch.opt.in | 62 +--
gcc/config/loongarch/la464.md | 32 +-
gcc/config/loongarch/loongarch-c.cc | 19 +-
gcc/config/loongarch/loongarch-cpu.cc | 263 +++-
gcc/config/loongarch/loongarch-cpu.h | 3 +-
gcc/config/loongarch/loongarch-def.c | 67 ++--
gcc/config/loongarch/loongarch-def.h | 57 +--
gcc/config/loongarch/loongarch-driver.cc | 208 +-
gcc/config/loongarch/loongarch-driver.h | 40 +-
gcc/config/loongarch/loongarch-opts.cc| 372 -
gcc/config/loongarch/loongarch-opts.h | 59 +--
gcc/config/loongarch/loongarch-str.h | 7 +-
gcc/config/loongarch/loongarch.cc | 87 ++--
gcc/config/loongarch/loongarch.opt| 60 ++-
gcc/config/loongarch/t-linux | 32 +-
gcc/doc/install.texi | 52 ++-
gcc/doc/invoke.texi
