public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Xi Ruoyao <xry111@xry111.site>
To: Yujie Yang <yangyujie@loongson.cn>
Cc: gcc-patches@gcc.gnu.org, xuchenghua@loongson.cn,
	chenglulu@loongson.cn,  panchenghui@loongson.cn
Subject: Re: [PATCH v2 3/4] LoongArch: add new configure option --with-strict-align-lib
Date: Wed, 30 Aug 2023 16:22:13 +0800	[thread overview]
Message-ID: <7e29b15bb6096c240c3ffd27a16f7350a7742f97.camel@xry111.site> (raw)
In-Reply-To: <syjoyv5ahjrezu5q6nis3vrr3pjbfohh4ztqhzpgoy5pzesxpl@jsbmnj2qimer>

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.

-- 
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University

  reply	other threads:[~2023-08-30  8:22 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-30  1:58 [PATCH 0/4] LoongArch: target configuration interface update Yang Yujie
2023-08-30  1:58 ` [PATCH v2 1/4] LoongArch: improved target configuration interface Yang Yujie
2023-08-30 21:36   ` Joseph Myers
2023-08-31  3:14     ` Yujie Yang
2023-08-31  7:36       ` Yujie Yang
2023-08-31 17:56       ` Joseph Myers
2023-09-01  1:19         ` Yujie Yang
2023-08-30  1:58 ` [PATCH v2 2/4] LoongArch: define preprocessing macros "__loongarch_{arch,tune}" Yang Yujie
2023-08-30  1:58 ` [PATCH v2 3/4] LoongArch: add new configure option --with-strict-align-lib Yang Yujie
2023-08-30  5:25   ` Xi Ruoyao
2023-08-30  6:51     ` Yujie Yang
2023-08-30  8:22       ` Xi Ruoyao [this message]
2023-08-30 10:01         ` Yujie Yang
2023-08-30  1:58 ` [PATCH v2 4/4] LoongArch: support loongarch*-elf target Yang Yujie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7e29b15bb6096c240c3ffd27a16f7350a7742f97.camel@xry111.site \
    --to=xry111@xry111.site \
    --cc=chenglulu@loongson.cn \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=panchenghui@loongson.cn \
    --cc=xuchenghua@loongson.cn \
    --cc=yangyujie@loongson.cn \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).