[v2,3/4] LoongArch: add new configure option --with-strict-align-lib
Checks
Commit Message
LoongArch processors may not support memory accesses without natural
alignments. Building libraries with -mstrict-align may help with
toolchain binary compatiblity and performance on these implementations
(e.g. Loongson 2K1000LA).
No significant performance degredation is observed on current mainstream
LoongArch processors when the option is enabled.
gcc/ChangeLog:
* config.gcc: use -mstrict-align for building libraries
if --with-strict-align-lib is given.
---
gcc/config.gcc | 16 +++++++++++++++-
1 file changed, 15 insertions(+), 1 deletion(-)
Comments
On Wed, 2023-08-30 at 09:58 +0800, Yang Yujie wrote:
> LoongArch processors may not support memory accesses without natural
> alignments. Building libraries with -mstrict-align may help with
> toolchain binary compatiblity and performance on these implementations
> (e.g. Loongson 2K1000LA).
>
> No significant performance degredation is observed on current mainstream
> LoongArch processors when the option is enabled.
>
> gcc/ChangeLog:
>
> * config.gcc: use -mstrict-align for building libraries
> if --with-strict-align-lib is given.
Isn't this equivalent to --with-default-multilib=mno-strict-align now?
And I still believe the easiest way for 2K1000LA is adding -march=la264
support so the user can simply configure with --with-arch=la264.
> ---
> gcc/config.gcc | 16 +++++++++++++++-
> 1 file changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/gcc/config.gcc b/gcc/config.gcc
> index 4fae672a3b7..ed70fa63268 100644
> --- a/gcc/config.gcc
> +++ b/gcc/config.gcc
> @@ -4892,7 +4892,7 @@ case "${target}" in
> ;;
>
> loongarch*-*)
> - supported_defaults="abi arch tune fpu simd multilib-
> default"
> + supported_defaults="abi arch tune fpu simd multilib-
> default strict-align-lib"
>
> # Local variables
> unset \
> @@ -5089,6 +5089,17 @@ case "${target}" in
> ;;
> esac
>
> + # Build libraries with -mstrict-align if --with-
> strict-align-lib is given.
> + case ${with_strict_align_lib} in
> + yes) strict_align_opt="/mstrict-align" ;;
> + ""|no) ;;
> + *)
> + echo "Unknown option: --with-strict-align-
> lib=${with_strict_align_lib}" 1>&2
> + exit 1
> + ;;
> + esac
> +
> +
> # Handle --with-multilib-default
> if echo "${with_multilib_default}" \
> | grep -E -e '[[:space:]]' -e '//' -e '/$' -e '^/' >
> /dev/null 2>&1; then
> @@ -5250,6 +5261,9 @@ case "${target}" in
> ;;
> esac
>
> + # Use mstrict-align for building libraries if
> --with-strict-align-lib is given.
> + loongarch_multilib_list_make="${loongarch_mult
> ilib_list_make}${strict_align_opt}"
> +
> # Check for repeated configuration of the same
> multilib variant.
> if echo "${elem_abi_base}/${elem_abi_ext}" \
> | grep -E "^(${all_abis%|})$" >/dev/null
> 2>&1; then
> > LoongArch processors may not support memory accesses without natural
> > alignments. Building libraries with -mstrict-align may help with
> > toolchain binary compatiblity and performance on these implementations
> > (e.g. Loongson 2K1000LA).
> >
> > No significant performance degredation is observed on current mainstream
> > LoongArch processors when the option is enabled.
> >
> > gcc/ChangeLog:
> >
> > * config.gcc: use -mstrict-align for building libraries
> > if --with-strict-align-lib is given.
>
> Isn't this equivalent to --with-default-multilib=mno-strict-align now?
>
> And I still believe the easiest way for 2K1000LA is adding -march=la264
> support so the user can simply configure with --with-arch=la264.
Not exactly -- Options given in --with-multilib-default= will not be applied
to multilib variants that have build options specified in --with-multilib-list,
but --with-strict-align-lib is always effective.
e.g. for the following configuration:
--with-multilib-default=mstrict-align
--with-multilib-list=lp64d/la464,lp64s
The library build options would be:
base/lp64d variant: -mabi=lp64d -march=la464 (no -mstrict-align appended)
base/lp64s variant: -mabi=lp64s -march=abi-default -mstrict-align
Sure, you can do it with --with-arch=la264. It's just a convenient
switch that we can use for building generic toolchains.
On Wed, 2023-08-30 at 14:51 +0800, Yujie Yang wrote:
> > > LoongArch processors may not support memory accesses without natural
> > > alignments. Building libraries with -mstrict-align may help with
> > > toolchain binary compatiblity and performance on these implementations
> > > (e.g. Loongson 2K1000LA).
> > >
> > > No significant performance degredation is observed on current mainstream
> > > LoongArch processors when the option is enabled.
> > >
> > > gcc/ChangeLog:
> > >
> > > * config.gcc: use -mstrict-align for building libraries
> > > if --with-strict-align-lib is given.
> >
> > Isn't this equivalent to --with-default-multilib=mno-strict-align now?
> >
> > And I still believe the easiest way for 2K1000LA is adding -march=la264
> > support so the user can simply configure with --with-arch=la264.
>
> Not exactly -- Options given in --with-multilib-default= will not be applied
> to multilib variants that have build options specified in --with-multilib-list,
> but --with-strict-align-lib is always effective.
>
> e.g. for the following configuration:
>
> --with-multilib-default=mstrict-align
> --with-multilib-list=lp64d/la464,lp64s
>
> The library build options would be:
>
> base/lp64d variant: -mabi=lp64d -march=la464 (no -mstrict-align appended)
> base/lp64s variant: -mabi=lp64s -march=abi-default -mstrict-align
>
> Sure, you can do it with --with-arch=la264. It's just a convenient
> switch that we can use for building generic toolchains.
If you want a generic toolchain, it should default to -mstrict-align as
well. Or it will still do unexpected thing for cases like:
struct foo { char x; int y; } __attribute__ ((packed));
int get (struct foo *foo) { return foo->y; }
So it should be --with-strict-align (it should make the *compiler*
default to -mstrict-align). But them it seems --with-arch=la264 is just
easier...
Or maybe we should add -march=la64-baseline (or another name?) as the
"bottom line" of a LA64 CPU. Currently the definition of -
march=loongarch64 includes unaligned access and 64-bit FP support, so
IMO we should have a baseline definition if we need to support something
"below" loongarch64.
On Wed, Aug 30, 2023 at 04:22:13PM +0800, Xi Ruoyao wrote:
> On Wed, 2023-08-30 at 14:51 +0800, Yujie Yang wrote:
> > > > LoongArch processors may not support memory accesses without natural
> > > > alignments. Building libraries with -mstrict-align may help with
> > > > toolchain binary compatiblity and performance on these implementations
> > > > (e.g. Loongson 2K1000LA).
> > > >
> > > > No significant performance degredation is observed on current mainstream
> > > > LoongArch processors when the option is enabled.
> > > >
> > > > gcc/ChangeLog:
> > > >
> > > > * config.gcc: use -mstrict-align for building libraries
> > > > if --with-strict-align-lib is given.
> > >
> > > Isn't this equivalent to --with-default-multilib=mno-strict-align now?
> > >
> > > And I still believe the easiest way for 2K1000LA is adding -march=la264
> > > support so the user can simply configure with --with-arch=la264.
> >
> > Not exactly -- Options given in --with-multilib-default= will not be applied
> > to multilib variants that have build options specified in --with-multilib-list,
> > but --with-strict-align-lib is always effective.
> >
> > e.g. for the following configuration:
> >
> > --with-multilib-default=mstrict-align
> > --with-multilib-list=lp64d/la464,lp64s
> >
> > The library build options would be:
> >
> > base/lp64d variant: -mabi=lp64d -march=la464 (no -mstrict-align appended)
> > base/lp64s variant: -mabi=lp64s -march=abi-default -mstrict-align
> >
> > Sure, you can do it with --with-arch=la264. It's just a convenient
> > switch that we can use for building generic toolchains.
>
> If you want a generic toolchain, it should default to -mstrict-align as
> well. Or it will still do unexpected thing for cases like:
>
> struct foo { char x; int y; } __attribute__ ((packed));
>
> int get (struct foo *foo) { return foo->y; }
>
> So it should be --with-strict-align (it should make the *compiler*
> default to -mstrict-align). But them it seems --with-arch=la264 is just
> easier...
By "generic" I mean: when you enable "-march=la264"/"-march=la464"
and link statically, you get a binary that's good for running on
LA264/LA464 cores, respectively. It's more of a cross-toolchain case.
@@ -4892,7 +4892,7 @@ case "${target}" in
;;
loongarch*-*)
- supported_defaults="abi arch tune fpu simd multilib-default"
+ supported_defaults="abi arch tune fpu simd multilib-default strict-align-lib"
# Local variables
unset \
@@ -5089,6 +5089,17 @@ case "${target}" in
;;
esac
+ # Build libraries with -mstrict-align if --with-strict-align-lib is given.
+ case ${with_strict_align_lib} in
+ yes) strict_align_opt="/mstrict-align" ;;
+ ""|no) ;;
+ *)
+ echo "Unknown option: --with-strict-align-lib=${with_strict_align_lib}" 1>&2
+ exit 1
+ ;;
+ esac
+
+
# Handle --with-multilib-default
if echo "${with_multilib_default}" \
| grep -E -e '[[:space:]]' -e '//' -e '/$' -e '^/' > /dev/null 2>&1; then
@@ -5250,6 +5261,9 @@ case "${target}" in
;;
esac
+ # Use mstrict-align for building libraries if --with-strict-align-lib is given.
+ loongarch_multilib_list_make="${loongarch_multilib_list_make}${strict_align_opt}"
+
# Check for repeated configuration of the same multilib variant.
if echo "${elem_abi_base}/${elem_abi_ext}" \
| grep -E "^(${all_abis%|})$" >/dev/null 2>&1; then