Re: [PATCH v8 00/12] Add LoongArch support.

2022-03-16 Thread 程璐璐 



在 2022/3/15 下午10:35, Xi Ruoyao 写道:

On Fri, 2022-03-04 at 15:17 +0800, xucheng...@loongson.cn wrote:


v7 -> v8
1. Add new addressing type ADDRESS_REG_REG support.
2. Modify documentation.
3. Eliminate compile-time warnings.

Hi,

The v8 series does not build LoongArch Linux kernel tree
(https://github.com/loongson/linux, loongarch-next branch) successfully.
This is a regression: the v7 series built the kernel fine.

A testcase reduced from the __get_data_asm macro in uaccess.h:

$ cat t1.c
char *ptr;
int offset;
struct m
{
   char a[2];
};

char
x (void)
{
   char t;
   asm volatile("ld.b %0, %1" : "=r"(t) : "o"(*(struct m *)(ptr + offset)));
   return t;
}

$ ./gcc/cc1 t1.c -nostdinc -O
t1.c: In function ‘x’:
t1.c:12:3: error: impossible constraint in ‘asm’
12 |   asm volatile("ld.b %0, %1" : "=r"(t) : "o"(*(struct m *)(ptr + 
offset)));
   |   ^~~

It seems changing the constraint "o" to "m" can work around this issue.
I'm not sure if this is a compiler bug or a kernel bug.


Hi,

LoongArch supports memory modes as follows:

 mode        memory constraint

1. base  + index "k"

2. base + imm12 "m"

3. base + imm16 (immediate 4-byte alignment) "ZC"

4. base + 0 "ZB"

so, this constraint should be "m".

Re: [PATCH v8 00/12] Add LoongArch support.

2022-03-15 Thread Xi Ruoyao via Gcc-patches 
On Fri, 2022-03-04 at 15:17 +0800, xucheng...@loongson.cn wrote:

> v7 -> v8
> 1. Add new addressing type ADDRESS_REG_REG support.
> 2. Modify documentation.
> 3. Eliminate compile-time warnings.

Hi,

The v8 series does not build LoongArch Linux kernel tree
(https://github.com/loongson/linux, loongarch-next branch) successfully.
This is a regression: the v7 series built the kernel fine.

A testcase reduced from the __get_data_asm macro in uaccess.h:

$ cat t1.c
char *ptr;
int offset;
struct m
{
  char a[2];
};

char
x (void)
{
  char t;
  asm volatile("ld.b %0, %1" : "=r"(t) : "o"(*(struct m *)(ptr + offset)));
  return t;
}

$ ./gcc/cc1 t1.c -nostdinc -O
t1.c: In function ‘x’:
t1.c:12:3: error: impossible constraint in ‘asm’
   12 |   asm volatile("ld.b %0, %1" : "=r"(t) : "o"(*(struct m *)(ptr + 
offset)));
  |   ^~~

It seems changing the constraint "o" to "m" can work around this issue.
I'm not sure if this is a compiler bug or a kernel bug.
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

Re: [PATCH v8 00/12] Add LoongArch support.

2022-03-08 Thread Richard Sandiford via Gcc-patches 
Xi Ruoyao via Gcc-patches  writes:
> On Fri, 2022-03-04 at 15:17 +0800, xucheng...@loongson.cn wrote:
>
>> The binutils has been merged into trunk:
>> https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=560b3fe208255ae909b4b1c88ba9c28b09043307
>> 
>> Note: We split -mabi= into -mabi=lp64d/f/s, the new options not support by 
>> upstream binutils yet,
>> this GCC port requires the following patch applied to binutils to build.
>> https://github.com/loongson/binutils-gdb/commit/aacb0bf860f02aa5a7dcb76dd0e392bf871c7586
>> (will be submitted to upstream after gcc side comfirmed)
>
> I think you don't need a review for binutils change here.  You should
> get it reviewed and applied in binutils-gdb ASAP.  Then in install.texi
> you would add a note like "loongarch64-*-* requires binutils >= 2.39" in
> "Target specific installation notes", as an unpatched 2.38 does not
> work.
>
> And based on the history of RISC-V port
> (https://gcc.gnu.org/pipermail/gcc/2017-January/222595.html) the process
> for a new port seems:
>
> 1. Get a permission from the Steering Committee.
> 2. Add one or two port maintainers into MAINTAINERS file.
> 3. Now the technical reviewing of the patch series just begin.
>
>
> I'm not an expert in software engineering (or social interaction :) and
> I don't know if the process has been changed in these years.

I'm not sure either, but yeah, this is what I understood the process to be.

On the technical side: I've gone through the series and sent comments
about some of the patches.  The ones I didn't reply to looked good as-is.

Generally the series looks in very good shape to me FWIW.  There are no
target-independent changes, so I agree there's no reason to delay the
patches until GCC 13.  If for some reason they don't go in before
GCC 12.1, they would be safe to backport to GCC 12.2.

Thanks,
Richard

Re: [PATCH v8 00/12] Add LoongArch support.

2022-03-05 Thread Xi Ruoyao via Gcc-patches 
On Sat, 2022-03-05 at 09:36 +0800, Paul Hua wrote:
> > 
> > And based on the history of RISC-V port
> > (https://gcc.gnu.org/pipermail/gcc/2017-January/222595.html) the
> > process
> > for a new port seems:
> > 
> > 1. Get a permission from the Steering Committee.
> > 2. Add one or two port maintainers into MAINTAINERS file.
> > 3. Now the technical reviewing of the patch series just begin.
> > 
> 
> Hi Ruoyao,
> Thanks for your advice.  But I don't know how to contact the GCC
> Steering Committee.

https://gcc.gnu.org/steering.html

It says the best place to reach the SC members is the list
g...@gcc.gnu.org.

And Joseph is also a SC member.
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

Re: [PATCH v8 00/12] Add LoongArch support.

2022-03-04 Thread Paul Hua via Gcc-patches 
> > And based on the history of RISC-V port
> > (https://gcc.gnu.org/pipermail/gcc/2017-January/222595.html) the process
> > for a new port seems:
> >
> > 1. Get a permission from the Steering Committee.
> > 2. Add one or two port maintainers into MAINTAINERS file.
> > 3. Now the technical reviewing of the patch series just begin.
> >
>
> Hi Ruoyao,
> Thanks for your advice.  But I don't know how to contact the GCC
> Steering Committee.
>
> Hi David,
> Any suggestions?
Sorry, CCed David Edelsohn.

Re: [PATCH v8 00/12] Add LoongArch support.

2022-03-04 Thread Paul Hua via Gcc-patches 
>
> And based on the history of RISC-V port
> (https://gcc.gnu.org/pipermail/gcc/2017-January/222595.html) the process
> for a new port seems:
>
> 1. Get a permission from the Steering Committee.
> 2. Add one or two port maintainers into MAINTAINERS file.
> 3. Now the technical reviewing of the patch series just begin.
>

Hi Ruoyao,
Thanks for your advice.  But I don't know how to contact the GCC
Steering Committee.

Hi David,
Any suggestions?

Re: [PATCH v8 00/12] Add LoongArch support.

2022-03-04 Thread Xi Ruoyao via Gcc-patches 
On Fri, 2022-03-04 at 15:17 +0800, xucheng...@loongson.cn wrote:

> The binutils has been merged into trunk:
> https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=560b3fe208255ae909b4b1c88ba9c28b09043307
> 
> Note: We split -mabi= into -mabi=lp64d/f/s, the new options not support by 
> upstream binutils yet,
> this GCC port requires the following patch applied to binutils to build.
> https://github.com/loongson/binutils-gdb/commit/aacb0bf860f02aa5a7dcb76dd0e392bf871c7586
> (will be submitted to upstream after gcc side comfirmed)

I think you don't need a review for binutils change here.  You should
get it reviewed and applied in binutils-gdb ASAP.  Then in install.texi
you would add a note like "loongarch64-*-* requires binutils >= 2.39" in
"Target specific installation notes", as an unpatched 2.38 does not
work.

And based on the history of RISC-V port
(https://gcc.gnu.org/pipermail/gcc/2017-January/222595.html) the process
for a new port seems:

1. Get a permission from the Steering Committee.
2. Add one or two port maintainers into MAINTAINERS file.
3. Now the technical reviewing of the patch series just begin.


I'm not an expert in software engineering (or social interaction :) and
I don't know if the process has been changed in these years.
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

[PATCH v8 00/12] Add LoongArch support.

2022-03-03 Thread xuchenghua 
From: chenglulu 

Hi, all:

This is the v8 version of LoongArch Port. Please review.

We know it is stage4, I think it is ok for a new prot.
The kernel side upstream waiting for a approval by gcc side,
if it is blocked by stage4, a approval for GCC13 will be appreciation.

The LoongArch architecture (LoongArch) is an Instruction Set
Architecture (ISA) that has a Reduced Instruction Set Computer (RISC)
style.
The documents are on
https://loongson.github.io/LoongArch-Documentation/README-EN.html

The ELF ABI Documents are on:
https://loongson.github.io/LoongArch-Documentation/LoongArch-ELF-ABI-EN.html

The binutils has been merged into trunk:
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=560b3fe208255ae909b4b1c88ba9c28b09043307

Note: We split -mabi= into -mabi=lp64d/f/s, the new options not support by 
upstream binutils yet,
this GCC port requires the following patch applied to binutils to build.
https://github.com/loongson/binutils-gdb/commit/aacb0bf860f02aa5a7dcb76dd0e392bf871c7586
(will be submitted to upstream after gcc side comfirmed)

We have compiled more than 300 CLFS packages with this compiler.
The CLFS are currently used on Cfarm machines gcc400 and gcc401.

changelog:

v1 -> v2
1. Split patch set.
2. Change some code style.
3. Add -mabi=lp64d/f/s options.
4. Change GLIBC_DYNAMIC_LINKER_LP64 name.

v2 -> v3
1. Change some code style.
2. Bug fix.

v3 -> v4
1. Change some code style.
2. Bug fix.
3. Delete some builtin macros.

v4 -> v5
1. delete wrong insn zero_extendsidi2_internal.
2. Adjust some build options.
3. Change some .c files to .cc.

v5 -> v6
1. Fix compilation issues. The generated files *.opt and *.h
   are generated to $(objdir).

v6 -> v7
1. Bug fix.
2. Change some code style.

v7 -> v8
1. Add new addressing type ADDRESS_REG_REG support.
2. Modify documentation.
3. Eliminate compile-time warnings.

chenglulu (12):
  LoongArch Port: Regenerate configure
  LoongArch Port: gcc build
  LoongArch Port: Regenerate gcc/configure.
  LoongArch Port: Machine description files.
  LoongArch Port: Machine description C files and .h files.
  LoongArch Port: Builtin functions.
  LoongArch Port: Builtin macros.
  LoongArch Port: libgcc
  LoongArch Port: Regenerate libgcc/configure.
  LoongArch Port: libgomp
  LoongArch Port: gcc/testsuite
  LoongArch Port: Add doc.

 config/picflag.m4 |3 +
 configure |   10 +-
 configure.ac  |   10 +-
 contrib/config-list.mk|5 +-
 contrib/gcc_update|2 +
 .../config/loongarch/loongarch-common.cc  |   73 +
 gcc/config.gcc|  410 +-
 gcc/config/host-linux.cc  |2 +
 gcc/config/loongarch/constraints.md   |  204 +
 gcc/config/loongarch/generic.md   |  132 +
 gcc/config/loongarch/genopts/genstr.sh|   91 +
 .../loongarch/genopts/loongarch-strings   |   58 +
 gcc/config/loongarch/genopts/loongarch.opt.in |  189 +
 gcc/config/loongarch/gnu-user.h   |   84 +
 gcc/config/loongarch/la464.md |  132 +
 gcc/config/loongarch/larchintrin.h|  413 ++
 gcc/config/loongarch/linux.h  |   50 +
 gcc/config/loongarch/loongarch-builtins.cc|  511 ++
 gcc/config/loongarch/loongarch-c.cc   |  109 +
 gcc/config/loongarch/loongarch-cpu.cc |  206 +
 gcc/config/loongarch/loongarch-cpu.h  |   30 +
 gcc/config/loongarch/loongarch-def.c  |  164 +
 gcc/config/loongarch/loongarch-def.h  |  151 +
 gcc/config/loongarch/loongarch-driver.cc  |  187 +
 gcc/config/loongarch/loongarch-driver.h   |   69 +
 gcc/config/loongarch/loongarch-ftypes.def |  106 +
 gcc/config/loongarch/loongarch-modes.def  |   29 +
 gcc/config/loongarch/loongarch-opts.cc|  580 ++
 gcc/config/loongarch/loongarch-opts.h |   86 +
 gcc/config/loongarch/loongarch-protos.h   |  240 +
 gcc/config/loongarch/loongarch-str.h  |   57 +
 gcc/config/loongarch/loongarch-tune.h |   72 +
 gcc/config/loongarch/loongarch.cc | 6450 +
 gcc/config/loongarch/loongarch.h  | 1273 
 gcc/config/loongarch/loongarch.md | 3712 ++
 gcc/config/loongarch/loongarch.opt|  189 +
 gcc/config/loongarch/predicates.md|  527 ++
 gcc/config/loongarch/sync.md  |  574 ++
 gcc/config/loongarch/t-linux  |   53 +
 gcc/config/loongarch/t-loongarch  |   68 +
 gcc/configure |   66 +-
 gcc/configure.ac  |   33 +-
 gcc/doc/install.texi  |   47 +-
 gcc/doc/invoke.texi   |  202 +
 gcc/doc/md.texi   |   55 +
 gcc/testsuite/g++.dg/cpp0x/constexpr-rom.C|2 +-
 gcc/testsuite/g++.old-deja/g++.abi/ptrmem.C   |2