xucheng...@loongson.cn writes:
> From: chenglulu <chengl...@loongson.cn>
>
> 2022-03-04 Chenghua Xu <xucheng...@loongson.cn>
> Lulu Cheng <chengl...@loongson.cn>
>
> * contrib/config-list.mk: Add LoongArch triplet.
> * gcc/doc/install.texi: Add LoongArch options section.
> * gcc/doc/invoke.texi: Add LoongArch options section.
> * gcc/doc/md.texi: Add LoongArch options section.
> ---
> contrib/config-list.mk | 5 +-
> gcc/doc/install.texi | 47 +++++++++-
> gcc/doc/invoke.texi | 202 +++++++++++++++++++++++++++++++++++++++++
> gcc/doc/md.texi | 55 +++++++++++
> 4 files changed, 303 insertions(+), 6 deletions(-)
>
> diff --git a/contrib/config-list.mk b/contrib/config-list.mk
> index 3e1d1321861..ba6f12e4693 100644
> --- a/contrib/config-list.mk
> +++ b/contrib/config-list.mk
> @@ -57,7 +57,10 @@ LIST = aarch64-elf aarch64-linux-gnu aarch64-rtems \
> i686-wrs-vxworksae \
> i686-cygwinOPT-enable-threads=yes i686-mingw32crt ia64-elf \
> ia64-freebsd6 ia64-linux ia64-hpux ia64-hp-vms iq2000-elf lm32-elf \
> - lm32-rtems lm32-uclinux m32c-rtems m32c-elf m32r-elf m32rle-elf \
> + lm32-rtems lm32-uclinux \
> + loongarch64-linux-gnu loongarch64-linux-gnuf64 \
> + loongarch64-linux-gnuf32 loongarch64-linux-gnusf \
If I've understood correctly, loongarch64-linux-gnu defaults to
the same ABI as loongarch64-linux-gnuf64, is that right? If so,
it's probably worth dropping one of them from this list to reduce
duplication. In other words, it feels like there should just be
3 entries here rather than 4.
> […]
> @@ -1254,6 +1255,14 @@ profile. The union of these options is considered
> when specifying both
> @code{-mfloat-abi=hard}
> @end multitable
>
> +@item loongarch*-*-*
> +@var{list} is a comma-separated list of the following ABI identifiers:
> +@code{lp64d[/base]} @code{lp64f[/base]} @code{lp64d[/base]}, where the
> +@code{/base} suffix may be omitted, to enable their respective run-time
> +libraries. If @var{list} is empty, @code{default}
> +or @option{--with-multilib-list} is not specified, then the default ABI
Maybe clearer as:
If @var{list} is empty or @code{default}, or if
@option{--with-multilib-list} is not specified, […]
> +as specified by @option{--with-abi} or implied by @option{--target} is
> selected.
> +
> @item riscv*-*-*
> @var{list} is a single ABI name. The target architecture must be either
> @code{rv32gc} or @code{rv64gc}. This will build a single multilib for the
> […]
> @@ -995,6 +995,16 @@ Objective-C and Objective-C++ Dialects}.
> @gccoptlist{-mbarrel-shift-enabled -mdivide-enabled -mmultiply-enabled @gol
> -msign-extend-enabled -muser-enabled}
>
> +@emph{LoongArch Options}
> +@gccoptlist{-march=@var{cpu-type} -mtune=@var{cpu-type}
> -mabi=@var{base-abi-type} @gol
> +-mfpu=@var{fpu-type} -msoft-float -msingle-float -mdouble-float @gol
> +-mbranch-cost=@var{n} -mcheck-zero-division -mno-check-zero-division @gol
> +-mcond-move-int -mno-cond-move-int @gol
> +-mcond-move-float -mno-cond-move-float @gol
> +-memcpy -mno-memcpy -mstrict-align -mno-strict-align @gol
> +-mmax-inline-memcpy-size=@var{n} @gol
> +-mlra -mcmodel=@var{code-model}}
Following on from earlier comments, please remove -mlra :-)
(Or more specifically, -mno-lra.)
> +
> @emph{M32R/D Options}
> @gccoptlist{-m32r2 -m32rx -m32r @gol
> -mdebug @gol
> @@ -18863,6 +18873,7 @@ platform.
> * HPPA Options::
> * IA-64 Options::
> * LM32 Options::
> +* LoongArch Options::
> * M32C Options::
> * M32R/D Options::
> * M680x0 Options::
> @@ -24378,6 +24389,197 @@ Enable user-defined instructions.
>
> @end table
>
> +@node LoongArch Options
> +@subsection LoongArch Options
> +@cindex LoongArch Options
> +
> +These command-line options are defined for LoongArch targets:
> +
> +@table @gcctabopt
> +@item -march=@var{cpu-type}
> +@opindex -march
> +Generate instructions for the machine type @var{cpu-type}. In contrast to
> +@option{-mtune=@var{cpu-type}}, which merely tunes the generated code
> +for the specified @var{cpu-type}, @option{-march=@var{cpu-type}} allows GCC
> +to generate code that may not run at all on processors other than the one
> +indicated. Specifying @option{-march=@var{cpu-type}} implies
> +@option{-mtune=@var{cpu-type}}, except where noted otherwise.
> +
> +The choices for @var{cpu-type} are:
> +
> +@table @samp
> +@item native
> +This selects the CPU to generate code for at compilation time by determining
> +the processor type of the compiling machine. Using @option{-march=native}
> +enables all instruction subsets supported by the local machine (hence
> +the result might not run on different machines). Using
> @option{-mtune=native}
> +produces code optimized for the local machine under the constraints
> +of the selected instruction set.
> +@item loongarch64
> +A generic CPU with 64-bit extensions.
> +@item la464
> +LoongArch LA464 CPU with LBT, LSX, LASX, LVZ.
> +@end table
> +
> +
> +@item -mtune=@var{cpu-type}
> +@opindex mtune
> +Optimize the output for the given processor, specified by microarchitecture
> +name.
> +
> +@item -mabi=@var{base-abi-type}
> +@opindex mabi
> +Generate code for the specified calling convention. @gol
> +Set base ABI to one of: @gol
Using @gol looks odd here. Maybe:
s/Set base ABI to one of/@var{base-abi-type} can be one of:/
> +@table @samp
> +@item lp64d
> +Uses 64-bit general purpose registers and 32/64-bit floating-point
> +registers for parameter passing. Data model is LP64, where int
> +is 32 bits, while long int and pointers are 64 bits.
@samp{int} and @samp{long int}. Same for the others.
> +@item lp64f
> +Uses 64-bit general purpose registers and 32-bit floating-point
> +registers for parameter passing. Data model is LP64, where int
> +is 32 bits, while long int and pointers are 64 bits.
> +@item lp64s
> +Uses 64-bit general purpose registers and no floating-point
> +registers for parameter passing. Data model is LP64, where int
> +is 32 bits, while long int and pointers are 64 bits.
> +@end table
> +
> +
Very minor, sorry, but it's probably more consistent to have only
a single blank line, even though I realise you're using double
blank lines to separate options into related groups. Same for
the rest of this section.
> +@item -mfpu=@var{fpu-type}
> +@opindex mfpu
> +Generating code for the specified FPU type: @gol
Maybe:
Generate code for the specified FPU type, which can be one of:
(likewise without @gol)
> +@table @samp
> +@item 64
> +Allow the use of hardware floating-point instructions for 32-bit
> +and 64-bit operations.
> +@item 32
> +Allow the use of hardware floating-point instructions for 32-bit
> +operations.
> +@item none
> +@item 0
Going back to the review for part 2: is 0 really supported?
> +Prevent the use of hardware floating-point instructions.
> +@end table
> +
> +
> +@item -msoft-float
> +@opindex msoft-float
> +Force @option{-mfpu=none} and prevents the use of floating-point
> +registers for parameter passing. This option may change the target
> +ABI.
> +
> +@item -msingle-float
> +@opindex -msingle-float
> +Force @option{-mfpu=32} and allow the use of 32-bit floating-point
> +registers for parameter passing. This option may change the target
> +ABI.
> +
> +@item -mdouble-float
> +@opindex -mdouble-float
> +Force @option{-mfpu=64} and allow the use of 32/64-bit floating-point
> +registers for parameter passing. This option may change the target
> +ABI.
> +
> +
> +@item -mbranch-cost=@var{n}
> +@opindex -mbranch-cost
> +Set the cost of branches to roughly n instructions.
Markup nit: @var{n}
> +
> +@item -mcheck-zero-division
> +@itemx -mno-check-zero-divison
> +@opindex -mcheck-zero-division
> +Trap (do not trap) on integer division by zero. The default is '-mcheck-zero-
> +division'.
Markup nit: @option{-mcheck-zero-division}
Same for later options. The option names shouldn't be split across lines.
> +
> +
> +@item -mcond-move-int
> +@itemx -mno-cond-move-int
> +@opindex -mcond-move-int
> +Conditional moves for integer are enabled (disabled). The default is
> +'-mcond-move-float'.
Looks like there's something missing here: there should be a listing
for both the int and the float options. “integer registers” (and
“floating-point registers”) might be clearer than just “integer”.
> +
> +@item -mmemcpy
> +@itemx -mno-memcpy
> +@opindex -mmemcpy
> +Force (do not force) the use of memcpy for non-trivial block moves. The
> default
> +is '-mno-memcpy', which allows GCC to inline most constant-sized copies.
Following on from the earlier review: this should mention that the
option is affected by -Os, if that is the intention.
> +
> +
> +@item -mlra
> +@opindex -mlra
> +Use the new LRA register allocator. By default, the LRA is used.
> +
> +@item -mstrict-align
> +@itemx -mno-strict-align
> +@opindex -mstrict-align
> +Avoid or allow generating memory accesses that may not be aligned on a
> natural
> +object boundary as described in the architecture specification. The default
> is
> +'-mno-strict-align'.
> +
> +@item -msmall-data-limit=@var{number}
> +@opindex -msmall-data-limit
> +Put global and static data smaller than @code{number} bytes into a special
> section (on some targets).
@var{number}
Also (very minor, sorry): the line is longer than the 80 character limit.
Same for some later lines (but not many).
> +Default value is 0.
> +
> +
> +@item -mmax-inline-memcpy-size=@var{n}
> +@opindex -mmax-inline-memcpy-size
> +Set the max size n of memcpy to inline, default n is 1024.
Borrowing form PowerPC, maybe:
Inline all block moves (such as calls to @code{memcpy} or structure
copies) less than or equal to @var{n} bytes. The default value of
@var{n} is 1024.
This makes it clearer that structure copies are included too.
> +
> +@item -mcmodel=@var{code-model}
> +Default code model is normal.
I think it's clearer to put the default after the table instead,
after “normal” has been introduced. Markup-wise it should be:
The default code model is @code{normal}.
> […]
> diff --git a/gcc/doc/md.texi b/gcc/doc/md.texi
> index f3619c505c0..98c2bd67a80 100644
> --- a/gcc/doc/md.texi
> +++ b/gcc/doc/md.texi
> @@ -2747,6 +2747,61 @@ Memory addressed using the small base register ($sb).
> $r1h
> @end table
>
> +@item LoongArch---@file{config/loongarch/constraints.md}
> +@table @code
> +@item a
> +A constant call global and noplt address.
> +@item c
> +A constant call local address.
> +@item e
> +A register that is used as function call.
> +@item f
> +A floating-point register (if available).
> +@item h
> +A constant call plt address.
> +@item j
> +A rester that is used as sibing call.
Typo: register
> +@item k
> +A memory operand whose address is formed by a base register and
> +(optionally scaled) index register.
> +@item l
> +A signed 16-bit constant.
> +@item m
> +A memory operand whose address is formed by a base register and offset
> +that is suitable for use in instructions with the same addressing mode
> +as @code{st.w} and @code{ld.w}.
> +@item q
> +A general-purpose register except for $r0 and $r1 for csr instructions.
> +@item t
> +A constant call weak address.
> +@item u
> +A signed 52bit constant and low 32-bit is zero (for logic instructions).
> +@item v
> +A nsigned 64-bit constant and low 44-bit is zero (for logic instructions).
> +@item w
> +Matches any valid memory.
> +@item z
> +A floating-point condition code register.
> +@item G
> +Floating-point zero.
> +@item I
> +A signed 12-bit constant (for arithmetic instructions).
> +@item J
> +Integer zero.
> +@item K
> +An unsigned 12-bit constant (for logic instructions).
> +@item Yd
> +A constant @code{move_operand} that can be safely loaded using
> +@code{la}.
> +@item ZB
> +An address that is held in a general-purpose register.
> +The offset is zero.
> +@item ZC
> +A memory operand whose address is formed by a base register and offset
> +that is suitable for use in instructions with the same addressing mode
> +as @code{ll.w} and @code{sc.w}.
> +@end table
> +
Are you sure you want to make all of these public? It doesn't look like
they would all be useful to inline assembly programmers, and once a
constraint is public, it can't easily be changed or removed without
breaking backwards compatibility.
“What linux needs” is probably a good starting point :-)
Just a question/suggestion though, no need to change.
Looks good to me otherwise.
Thanks,
Richard
