On Mon, Aug 14, 2023 at 01:58:24PM +0800, Xi Ruoyao wrote:
> On Mon, 2023-08-14 at 11:57 +0800, Yang Yujie wrote:
> > * Support options for LoongArch SIMD extensions:
> > new configure options --with-simd={none,lsx,lasx};
> > new driver options -m[no]-l[a]sx / -msimd={none,lsx,lasx}.
>
> I suggest to rename --with-simd= to --with-ext= and accept a comma-
> separated ISA extension list, because we have non-SIMD ISA extensions.
> For example, "--with-ext=lasx,lbt" will make -mlasx, -mlsx (implied),
> and -mlbt the default. I prefer "-mlasx" over "-msimd=lasx" because "-
> mlasx" is shorter anyway (if there is no real reason to make -mlasx and
> -msimd=lasx two different things).
>
> --
> Xi Ruoyao <xry...@xry111.site>
> School of Aerospace Science and Technology, Xidian University
Thanks for the suggestion, --with-ext seems a good idea. I will
consider adding it later.
-msimd=lasx and -mlasx are the same if you only use them once, but things
gets complicated if you also want -mno-lsx to cancel the effect of -mlasx.
In short, -msimd= is *necessary* for a correct (and convenient) implementation
of the "legacy" -m[no-]l[a]sx options. Let's hope I can explain this clearly:
I assume we all want:
(1) -mlasx -mlsx -> enable LSX and LASX
(2) -mlasx -mno-lsx -> disable LSX and LASX
(3) -mno-lsx -mlasx -> enable LSX and LASX
Unless we declare -mlsx / -mlasx as driver deferred, AFAIK there is no other
way for
us to know the actual order of appearnce of all -m[no-]l[a]sx options on the
command
line. All we know from GCC's option system would be a final on/off state of
"lsx"
and a final on/off state of "lasx".
These states results from independent processing of -m[no-]lsx and -m[no-]lasx
options
in the order they appear, respectively. So we can't distinguish between (2)
and (3).
Another seemingly viable approach is to declare three options -mlsx / -mlasx /
-mno-lsx
and making them mutually exclusive. In this way GCC would only consider the
last one
appearing on the command line. But we lost (1) in this case.
So, it seems that GCC is forbidding a compiler option to express a "state
change"
rather than a independent configuration state itself. This makes sense since
"-grecord-gcc-switches" and the LTO objects prefers that a target configuration
can be uniquely expressed in a "tuple of coordinates", rather than a series of
"connected vectors", so that they can be easily compared.
Now what we want is clear:
1. support convenient options like -mlsx / -mlasx (maybe something like
-m32 / -m64 in the future) that express state changes that interferes with
the effect of prior flags with different names.
2. the options passed to the compiler proper has a clear one-one
correspondence to the target configuration.
The implementation: canonicalize everything in the GCC driver, process the
"flags"
that express state changes in the order they appear into a group of independent
parameters. If the parameters they have overlapping semantics, the priority
is hard-coded, like -march and -msimd.
(This is also necessary for multilib since this is where the multilib selection
happens and final ABI needs to be decided before that.)
For this purpose, -msimd= is the canonicalized parameter form of the state
of SIMD extension, and -m[no-]l[a]sx are defined as convenient driver-only
flags.
