r332222 - [RISCV][NFC] Use more appropriate label for CHECK lines

2018-05-14 Thread Alex Bradbury via cfe-commits
Author: asb
Date: Mon May 14 02:14:43 2018
New Revision: 33

URL: http://llvm.org/viewvc/llvm-project?rev=33&view=rev
Log:
[RISCV][NFC] Use more appropriate label for CHECK lines

'CC1' was a misleading prefix. Committing so as to simplify the diff for a 
patch I'm about to put up for review.

Modified:
cfe/trunk/test/Driver/riscv32-toolchain.c

Modified: cfe/trunk/test/Driver/riscv32-toolchain.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/riscv32-toolchain.c?rev=33&r1=332221&r2=33&view=diff
==
--- cfe/trunk/test/Driver/riscv32-toolchain.c (original)
+++ cfe/trunk/test/Driver/riscv32-toolchain.c Mon May 14 02:14:43 2018
@@ -8,31 +8,31 @@
 // RUN:   -target riscv32-linux-unknown-elf \
 // RUN:   --gcc-toolchain=%S/Inputs/multilib_riscv_linux_sdk \
 // RUN:   --sysroot=%S/Inputs/multilib_riscv_linux_sdk/sysroot 2>&1 \
-// RUN:   | FileCheck -check-prefix=CC1-RV32-LINUX-ILP32 %s
+// RUN:   | FileCheck -check-prefix=C-RV32-LINUX-MULTI-ILP32 %s
 
-// CC1-RV32-LINUX-ILP32: 
"{{.*}}/Inputs/multilib_riscv_linux_sdk/lib/gcc/riscv64-unknown-linux-gnu/7.2.0/../../../../riscv64-unknown-linux-gnu/bin{{/|}}ld"
-// CC1-RV32-LINUX-ILP32: 
"--sysroot={{.*}}/Inputs/multilib_riscv_linux_sdk/sysroot"
-// CC1-RV32-LINUX-ILP32: "-m" "elf32lriscv"
-// CC1-RV32-LINUX-ILP32: "-dynamic-linker" "/lib/ld-linux-riscv32-ilp32.so.1"
-// CC1-RV32-LINUX-ILP32: 
"{{.*}}/Inputs/multilib_riscv_linux_sdk/lib/gcc/riscv64-unknown-linux-gnu/7.2.0/lib32/ilp32{{/|}}crtbegin.o"
-// CC1-RV32-LINUX-ILP32: 
"-L{{.*}}/Inputs/multilib_riscv_linux_sdk/lib/gcc/riscv64-unknown-linux-gnu/7.2.0/lib32/ilp32"
-// CC1-RV32-LINUX-ILP32: 
"-L{{.*}}/Inputs/multilib_riscv_linux_sdk/sysroot/lib32/ilp32"
-// CC1-RV32-LINUX-ILP32: 
"-L{{.*}}/Inputs/multilib_riscv_linux_sdk/sysroot/usr/lib32/ilp32"
+// C-RV32-LINUX-MULTI-ILP32: 
"{{.*}}/Inputs/multilib_riscv_linux_sdk/lib/gcc/riscv64-unknown-linux-gnu/7.2.0/../../../../riscv64-unknown-linux-gnu/bin{{/|}}ld"
+// C-RV32-LINUX-MULTI-ILP32: 
"--sysroot={{.*}}/Inputs/multilib_riscv_linux_sdk/sysroot"
+// C-RV32-LINUX-MULTI-ILP32: "-m" "elf32lriscv"
+// C-RV32-LINUX-MULTI-ILP32: "-dynamic-linker" 
"/lib/ld-linux-riscv32-ilp32.so.1"
+// C-RV32-LINUX-MULTI-ILP32: 
"{{.*}}/Inputs/multilib_riscv_linux_sdk/lib/gcc/riscv64-unknown-linux-gnu/7.2.0/lib32/ilp32{{/|}}crtbegin.o"
+// C-RV32-LINUX-MULTI-ILP32: 
"-L{{.*}}/Inputs/multilib_riscv_linux_sdk/lib/gcc/riscv64-unknown-linux-gnu/7.2.0/lib32/ilp32"
+// C-RV32-LINUX-MULTI-ILP32: 
"-L{{.*}}/Inputs/multilib_riscv_linux_sdk/sysroot/lib32/ilp32"
+// C-RV32-LINUX-MULTI-ILP32: 
"-L{{.*}}/Inputs/multilib_riscv_linux_sdk/sysroot/usr/lib32/ilp32"
 
 // RUN: %clang %s -### -no-canonical-prefixes -fuse-ld=ld \
 // RUN:   -target riscv32-linux-unknown-elf -march=rv32imafd -mabi=ilp32d \
 // RUN:   --gcc-toolchain=%S/Inputs/multilib_riscv_linux_sdk \
 // RUN:   --sysroot=%S/Inputs/multilib_riscv_linux_sdk/sysroot 2>&1 \
-// RUN:   | FileCheck -check-prefix=CC1-RV32-LINUX-ILP32D %s
+// RUN:   | FileCheck -check-prefix=C-RV32-LINUX-MULTI-ILP32D %s
 
-// CC1-RV32-LINUX-ILP32D: 
"{{.*}}/Inputs/multilib_riscv_linux_sdk/lib/gcc/riscv64-unknown-linux-gnu/7.2.0/../../../../riscv64-unknown-linux-gnu/bin{{/|}}ld"
-// CC1-RV32-LINUX-ILP32D: 
"--sysroot={{.*}}/Inputs/multilib_riscv_linux_sdk/sysroot"
-// CC1-RV32-LINUX-ILP32D: "-m" "elf32lriscv"
-// CC1-RV32-LINUX-ILP32D: "-dynamic-linker" "/lib/ld-linux-riscv32-ilp32d.so.1"
-// CC1-RV32-LINUX-ILP32D: 
"{{.*}}/Inputs/multilib_riscv_linux_sdk/lib/gcc/riscv64-unknown-linux-gnu/7.2.0/lib32/ilp32d{{/|}}crtbegin.o"
-// CC1-RV32-LINUX-ILP32D: 
"-L{{.*}}/Inputs/multilib_riscv_linux_sdk/lib/gcc/riscv64-unknown-linux-gnu/7.2.0/lib32/ilp32d"
-// CC1-RV32-LINUX-ILP32D: 
"-L{{.*}}/Inputs/multilib_riscv_linux_sdk/sysroot/lib32/ilp32d"
-// CC1-RV32-LINUX-ILP32D: 
"-L{{.*}}/Inputs/multilib_riscv_linux_sdk/sysroot/usr/lib32/ilp32d"
+// C-RV32-LINUX-MULTI-ILP32D: 
"{{.*}}/Inputs/multilib_riscv_linux_sdk/lib/gcc/riscv64-unknown-linux-gnu/7.2.0/../../../../riscv64-unknown-linux-gnu/bin{{/|}}ld"
+// C-RV32-LINUX-MULTI-ILP32D: 
"--sysroot={{.*}}/Inputs/multilib_riscv_linux_sdk/sysroot"
+// C-RV32-LINUX-MULTI-ILP32D: "-m" "elf32lriscv"
+// C-RV32-LINUX-MULTI-ILP32D: "-dynamic-linker" 
"/lib/ld-linux-riscv32-ilp32d.so.1"
+// C-RV32-LINUX-MULTI-ILP32D: 
"{{.*}}/Inputs/multilib_riscv_linux_sdk/lib/gcc/riscv64-unknown-linux-gnu/7.2.0/lib32/ilp32d{{/|}}crtbegin.o"
+// C-RV32-LINUX-MULTI-ILP32D: 
"-L{{.*}}/Inputs/multilib_riscv_linux_sdk/lib/gcc/riscv64-unknown-linux-gnu/7.2.0/lib32/ilp32d"
+// C-RV32-LINUX-MULTI-ILP32D: 
"-L{{.*}}/Inputs/multilib_riscv_linux_sdk/sysroot/lib32/ilp32d"
+// C-RV32-LINUX-MULTI-ILP32D: 
"-L{{.*}}/Inputs/multilib_riscv_linux_sdk/sysroot/usr/lib32/ilp32d"
 
 // RUN: %clang -target riscv32 %s -emit-llvm -S -o - | FileCheck %s
 


___
cfe-commits mailing list
cfe-commit

r321693 - Update clang cc1as for createMCAsmBackend change in r321692

2018-01-03 Thread Alex Bradbury via cfe-commits
Author: asb
Date: Wed Jan  3 00:53:24 2018
New Revision: 321693

URL: http://llvm.org/viewvc/llvm-project?rev=321693&view=rev
Log:
Update clang cc1as for createMCAsmBackend change in r321692

Modified:
cfe/trunk/tools/driver/cc1as_main.cpp

Modified: cfe/trunk/tools/driver/cc1as_main.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/driver/cc1as_main.cpp?rev=321693&r1=321692&r2=321693&view=diff
==
--- cfe/trunk/tools/driver/cc1as_main.cpp (original)
+++ cfe/trunk/tools/driver/cc1as_main.cpp Wed Jan  3 00:53:24 2018
@@ -397,7 +397,7 @@ static bool ExecuteAssembler(AssemblerIn
 if (Opts.ShowEncoding) {
   CE = TheTarget->createMCCodeEmitter(*MCII, *MRI, Ctx);
   MCTargetOptions Options;
-  MAB = TheTarget->createMCAsmBackend(*MRI, Opts.Triple, Opts.CPU, 
Options);
+  MAB = TheTarget->createMCAsmBackend(*STI, *MRI, Options);
 }
 auto FOut = llvm::make_unique(*Out);
 Str.reset(TheTarget->createAsmStreamer(
@@ -415,8 +415,7 @@ static bool ExecuteAssembler(AssemblerIn
 
 MCCodeEmitter *CE = TheTarget->createMCCodeEmitter(*MCII, *MRI, Ctx);
 MCTargetOptions Options;
-MCAsmBackend *MAB = TheTarget->createMCAsmBackend(*MRI, Opts.Triple,
-  Opts.CPU, Options);
+MCAsmBackend *MAB = TheTarget->createMCAsmBackend(*STI, *MRI, Options);
 Triple T(Opts.Triple);
 Str.reset(TheTarget->createMCObjectStreamer(
 T, Ctx, std::unique_ptr(MAB), *Out, 
std::unique_ptr(CE), *STI,


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


r322276 - [RISCV] Add the RISCV target and compiler driver

2018-01-11 Thread Alex Bradbury via cfe-commits
Author: asb
Date: Thu Jan 11 05:36:56 2018
New Revision: 322276

URL: http://llvm.org/viewvc/llvm-project?rev=322276&view=rev
Log:
[RISCV] Add the RISCV target and compiler driver

As RV64 codegen has not yet been upstreamed into LLVM, we focus on RV32 driver 
support (RV64 to follow).

Differential Revision: https://reviews.llvm.org/D39963

Added:
cfe/trunk/lib/Basic/Targets/RISCV.cpp
cfe/trunk/lib/Basic/Targets/RISCV.h
cfe/trunk/lib/Driver/ToolChains/Arch/RISCV.cpp
cfe/trunk/lib/Driver/ToolChains/Arch/RISCV.h
cfe/trunk/test/Driver/Inputs/multilib_riscv_linux_sdk/
cfe/trunk/test/Driver/Inputs/multilib_riscv_linux_sdk/bin/
cfe/trunk/test/Driver/Inputs/multilib_riscv_linux_sdk/bin/.keep
cfe/trunk/test/Driver/Inputs/multilib_riscv_linux_sdk/include/
cfe/trunk/test/Driver/Inputs/multilib_riscv_linux_sdk/include/.keep
cfe/trunk/test/Driver/Inputs/multilib_riscv_linux_sdk/lib/
cfe/trunk/test/Driver/Inputs/multilib_riscv_linux_sdk/lib/gcc/

cfe/trunk/test/Driver/Inputs/multilib_riscv_linux_sdk/lib/gcc/riscv64-unknown-linux-gnu/

cfe/trunk/test/Driver/Inputs/multilib_riscv_linux_sdk/lib/gcc/riscv64-unknown-linux-gnu/7.2.0/

cfe/trunk/test/Driver/Inputs/multilib_riscv_linux_sdk/lib/gcc/riscv64-unknown-linux-gnu/7.2.0/lib32/

cfe/trunk/test/Driver/Inputs/multilib_riscv_linux_sdk/lib/gcc/riscv64-unknown-linux-gnu/7.2.0/lib32/ilp32/

cfe/trunk/test/Driver/Inputs/multilib_riscv_linux_sdk/lib/gcc/riscv64-unknown-linux-gnu/7.2.0/lib32/ilp32d/

cfe/trunk/test/Driver/Inputs/multilib_riscv_linux_sdk/lib/gcc/riscv64-unknown-linux-gnu/7.2.0/lib64/

cfe/trunk/test/Driver/Inputs/multilib_riscv_linux_sdk/lib/gcc/riscv64-unknown-linux-gnu/7.2.0/lib64/lp64/

cfe/trunk/test/Driver/Inputs/multilib_riscv_linux_sdk/lib/gcc/riscv64-unknown-linux-gnu/7.2.0/lib64/lp64d/

cfe/trunk/test/Driver/Inputs/multilib_riscv_linux_sdk/riscv64-unknown-linux-gnu/

cfe/trunk/test/Driver/Inputs/multilib_riscv_linux_sdk/riscv64-unknown-linux-gnu/bin/

cfe/trunk/test/Driver/Inputs/multilib_riscv_linux_sdk/riscv64-unknown-linux-gnu/bin/ld
   (with props)
cfe/trunk/test/Driver/Inputs/multilib_riscv_linux_sdk/sysroot/
cfe/trunk/test/Driver/Inputs/multilib_riscv_linux_sdk/sysroot/lib/
cfe/trunk/test/Driver/Inputs/multilib_riscv_linux_sdk/sysroot/lib/.keep
cfe/trunk/test/Driver/Inputs/multilib_riscv_linux_sdk/sysroot/lib32/
cfe/trunk/test/Driver/Inputs/multilib_riscv_linux_sdk/sysroot/lib32/ilp32/

cfe/trunk/test/Driver/Inputs/multilib_riscv_linux_sdk/sysroot/lib32/ilp32/.keep
cfe/trunk/test/Driver/Inputs/multilib_riscv_linux_sdk/sysroot/lib32/ilp32d/

cfe/trunk/test/Driver/Inputs/multilib_riscv_linux_sdk/sysroot/lib32/ilp32d/.keep
cfe/trunk/test/Driver/Inputs/multilib_riscv_linux_sdk/sysroot/lib64/
cfe/trunk/test/Driver/Inputs/multilib_riscv_linux_sdk/sysroot/lib64/lp64/

cfe/trunk/test/Driver/Inputs/multilib_riscv_linux_sdk/sysroot/lib64/lp64/.keep
cfe/trunk/test/Driver/Inputs/multilib_riscv_linux_sdk/sysroot/lib64/lp64d/

cfe/trunk/test/Driver/Inputs/multilib_riscv_linux_sdk/sysroot/lib64/lp64d/.keep
cfe/trunk/test/Driver/Inputs/multilib_riscv_linux_sdk/sysroot/usr/
cfe/trunk/test/Driver/Inputs/multilib_riscv_linux_sdk/sysroot/usr/lib32/

cfe/trunk/test/Driver/Inputs/multilib_riscv_linux_sdk/sysroot/usr/lib32/ilp32/

cfe/trunk/test/Driver/Inputs/multilib_riscv_linux_sdk/sysroot/usr/lib32/ilp32/.keep

cfe/trunk/test/Driver/Inputs/multilib_riscv_linux_sdk/sysroot/usr/lib32/ilp32d/

cfe/trunk/test/Driver/Inputs/multilib_riscv_linux_sdk/sysroot/usr/lib32/ilp32d/.keep
cfe/trunk/test/Driver/Inputs/multilib_riscv_linux_sdk/sysroot/usr/lib64/

cfe/trunk/test/Driver/Inputs/multilib_riscv_linux_sdk/sysroot/usr/lib64/lp64/

cfe/trunk/test/Driver/Inputs/multilib_riscv_linux_sdk/sysroot/usr/lib64/lp64/.keep

cfe/trunk/test/Driver/Inputs/multilib_riscv_linux_sdk/sysroot/usr/lib64/lp64d/

cfe/trunk/test/Driver/Inputs/multilib_riscv_linux_sdk/sysroot/usr/lib64/lp64d/.keep
cfe/trunk/test/Driver/riscv-abi.c
cfe/trunk/test/Driver/riscv-features.c
cfe/trunk/test/Driver/riscv32-toolchain.c
cfe/trunk/test/Driver/riscv64-toolchain.c
Modified:
cfe/trunk/lib/Basic/CMakeLists.txt
cfe/trunk/lib/Basic/Targets.cpp
cfe/trunk/lib/Driver/CMakeLists.txt
cfe/trunk/lib/Driver/ToolChains/Clang.cpp
cfe/trunk/lib/Driver/ToolChains/Clang.h
cfe/trunk/lib/Driver/ToolChains/Gnu.cpp
cfe/trunk/lib/Driver/ToolChains/Linux.cpp
cfe/trunk/test/Driver/frame-pointer.c
cfe/trunk/test/Preprocessor/init.c

Modified: cfe/trunk/lib/Basic/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/CMakeLists.txt?rev=322276&r1=322275&r2=322276&view=diff
==
--- cfe/trunk/lib/Basic/CMakeLists.txt (original)
+++ cfe/trunk/lib/Basic/CMakeLists.txt Thu Jan 11 05:36:56 2018
@@ -83,6 +83,7 @@ ad

r322277 - [Driver][RISCV] Fix r322276 by adding missing dummy crtbegin.o files to test input

2018-01-11 Thread Alex Bradbury via cfe-commits
Author: asb
Date: Thu Jan 11 05:51:06 2018
New Revision: 322277

URL: http://llvm.org/viewvc/llvm-project?rev=322277&view=rev
Log:
[Driver][RISCV] Fix r322276 by adding missing dummy crtbegin.o files to test 
input

The dummy crtbegin.o files were left out in r322276 (as they were ignored by 
svn add of test/Driver/Inputs/multilib_riscv_linux_sdk) and are necessary for 
the driver test to work.

Added:

cfe/trunk/test/Driver/Inputs/multilib_riscv_linux_sdk/lib/gcc/riscv64-unknown-linux-gnu/7.2.0/crtbegin.o

cfe/trunk/test/Driver/Inputs/multilib_riscv_linux_sdk/lib/gcc/riscv64-unknown-linux-gnu/7.2.0/lib32/ilp32/crtbegin.o

cfe/trunk/test/Driver/Inputs/multilib_riscv_linux_sdk/lib/gcc/riscv64-unknown-linux-gnu/7.2.0/lib32/ilp32d/crtbegin.o

cfe/trunk/test/Driver/Inputs/multilib_riscv_linux_sdk/lib/gcc/riscv64-unknown-linux-gnu/7.2.0/lib64/lp64/crtbegin.o

cfe/trunk/test/Driver/Inputs/multilib_riscv_linux_sdk/lib/gcc/riscv64-unknown-linux-gnu/7.2.0/lib64/lp64d/crtbegin.o

Added: 
cfe/trunk/test/Driver/Inputs/multilib_riscv_linux_sdk/lib/gcc/riscv64-unknown-linux-gnu/7.2.0/crtbegin.o
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/Inputs/multilib_riscv_linux_sdk/lib/gcc/riscv64-unknown-linux-gnu/7.2.0/crtbegin.o?rev=322277&view=auto
==
(empty)

Added: 
cfe/trunk/test/Driver/Inputs/multilib_riscv_linux_sdk/lib/gcc/riscv64-unknown-linux-gnu/7.2.0/lib32/ilp32/crtbegin.o
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/Inputs/multilib_riscv_linux_sdk/lib/gcc/riscv64-unknown-linux-gnu/7.2.0/lib32/ilp32/crtbegin.o?rev=322277&view=auto
==
(empty)

Added: 
cfe/trunk/test/Driver/Inputs/multilib_riscv_linux_sdk/lib/gcc/riscv64-unknown-linux-gnu/7.2.0/lib32/ilp32d/crtbegin.o
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/Inputs/multilib_riscv_linux_sdk/lib/gcc/riscv64-unknown-linux-gnu/7.2.0/lib32/ilp32d/crtbegin.o?rev=322277&view=auto
==
(empty)

Added: 
cfe/trunk/test/Driver/Inputs/multilib_riscv_linux_sdk/lib/gcc/riscv64-unknown-linux-gnu/7.2.0/lib64/lp64/crtbegin.o
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/Inputs/multilib_riscv_linux_sdk/lib/gcc/riscv64-unknown-linux-gnu/7.2.0/lib64/lp64/crtbegin.o?rev=322277&view=auto
==
(empty)

Added: 
cfe/trunk/test/Driver/Inputs/multilib_riscv_linux_sdk/lib/gcc/riscv64-unknown-linux-gnu/7.2.0/lib64/lp64d/crtbegin.o
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/Inputs/multilib_riscv_linux_sdk/lib/gcc/riscv64-unknown-linux-gnu/7.2.0/lib64/lp64d/crtbegin.o?rev=322277&view=auto
==
(empty)


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


r322286 - [Driver][RISCV] Fix r322276 for Windows (path separator issue)

2018-01-11 Thread Alex Bradbury via cfe-commits
Author: asb
Date: Thu Jan 11 07:38:01 2018
New Revision: 322286

URL: http://llvm.org/viewvc/llvm-project?rev=322286&view=rev
Log:
[Driver][RISCV] Fix r322276 for Windows (path separator issue)

We were seeing test failures of riscv32-toolchain.c on windows due to the \ 
path separator being used for the linker. Add {{/|}} pattern (made 
horrible due to escaping), just like introduced in r214931.

Modified:
cfe/trunk/test/Driver/riscv32-toolchain.c

Modified: cfe/trunk/test/Driver/riscv32-toolchain.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/riscv32-toolchain.c?rev=322286&r1=322285&r2=322286&view=diff
==
--- cfe/trunk/test/Driver/riscv32-toolchain.c (original)
+++ cfe/trunk/test/Driver/riscv32-toolchain.c Thu Jan 11 07:38:01 2018
@@ -10,7 +10,7 @@
 // RUN:   --sysroot=%S/Inputs/multilib_riscv_linux_sdk/sysroot 2>&1 \
 // RUN:   | FileCheck -check-prefix=CC1-RV32-LINUX-ILP32 %s
 
-// CC1-RV32-LINUX-ILP32: 
"{{.*}}/Inputs/multilib_riscv_linux_sdk/lib/gcc/riscv64-unknown-linux-gnu/7.2.0/../../../../riscv64-unknown-linux-gnu/bin/ld"
+// CC1-RV32-LINUX-ILP32: 
"{{.*}}/Inputs/multilib_riscv_linux_sdk/lib/gcc/riscv64-unknown-linux-gnu/7.2.0/../../../../riscv64-unknown-linux-gnu/bin{{/|}}ld"
 // CC1-RV32-LINUX-ILP32: 
"--sysroot={{.*}}/Inputs/multilib_riscv_linux_sdk/sysroot"
 // CC1-RV32-LINUX-ILP32: "-m" "elf32lriscv"
 // CC1-RV32-LINUX-ILP32: "-dynamic-linker" "/lib/ld-linux-riscv32-ilp32.so.1"
@@ -25,7 +25,7 @@
 // RUN:   --sysroot=%S/Inputs/multilib_riscv_linux_sdk/sysroot 2>&1 \
 // RUN:   | FileCheck -check-prefix=CC1-RV32-LINUX-ILP32D %s
 
-// CC1-RV32-LINUX-ILP32D: 
"{{.*}}/Inputs/multilib_riscv_linux_sdk/lib/gcc/riscv64-unknown-linux-gnu/7.2.0/../../../../riscv64-unknown-linux-gnu/bin/ld"
+// CC1-RV32-LINUX-ILP32D: 
"{{.*}}/Inputs/multilib_riscv_linux_sdk/lib/gcc/riscv64-unknown-linux-gnu/7.2.0/../../../../riscv64-unknown-linux-gnu/bin{{/|}}ld"
 // CC1-RV32-LINUX-ILP32D: 
"--sysroot={{.*}}/Inputs/multilib_riscv_linux_sdk/sysroot"
 // CC1-RV32-LINUX-ILP32D: "-m" "elf32lriscv"
 // CC1-RV32-LINUX-ILP32D: "-dynamic-linker" "/lib/ld-linux-riscv32-ilp32d.so.1"


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


r322294 - [Driver][RISCV] Another Windows file separator fix for riscv32-toolchain.c test

2018-01-11 Thread Alex Bradbury via cfe-commits
Author: asb
Date: Thu Jan 11 09:06:32 2018
New Revision: 322294

URL: http://llvm.org/viewvc/llvm-project?rev=322294&view=rev
Log:
[Driver][RISCV] Another Windows file separator fix for riscv32-toolchain.c test

I've checking the failure log, this _should_ be the last one. Sorry for not 
spotting this additional case first time round.

Modified:
cfe/trunk/test/Driver/riscv32-toolchain.c

Modified: cfe/trunk/test/Driver/riscv32-toolchain.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/riscv32-toolchain.c?rev=322294&r1=322293&r2=322294&view=diff
==
--- cfe/trunk/test/Driver/riscv32-toolchain.c (original)
+++ cfe/trunk/test/Driver/riscv32-toolchain.c Thu Jan 11 09:06:32 2018
@@ -14,7 +14,7 @@
 // CC1-RV32-LINUX-ILP32: 
"--sysroot={{.*}}/Inputs/multilib_riscv_linux_sdk/sysroot"
 // CC1-RV32-LINUX-ILP32: "-m" "elf32lriscv"
 // CC1-RV32-LINUX-ILP32: "-dynamic-linker" "/lib/ld-linux-riscv32-ilp32.so.1"
-// CC1-RV32-LINUX-ILP32: 
"{{.*}}/Inputs/multilib_riscv_linux_sdk/lib/gcc/riscv64-unknown-linux-gnu/7.2.0/lib32/ilp32/crtbegin.o"
+// CC1-RV32-LINUX-ILP32: 
"{{.*}}/Inputs/multilib_riscv_linux_sdk/lib/gcc/riscv64-unknown-linux-gnu/7.2.0/lib32/ilp32{{/|}}crtbegin.o"
 // CC1-RV32-LINUX-ILP32: 
"-L{{.*}}/Inputs/multilib_riscv_linux_sdk/lib/gcc/riscv64-unknown-linux-gnu/7.2.0/lib32/ilp32"
 // CC1-RV32-LINUX-ILP32: 
"-L{{.*}}/Inputs/multilib_riscv_linux_sdk/sysroot/lib32/ilp32"
 // CC1-RV32-LINUX-ILP32: 
"-L{{.*}}/Inputs/multilib_riscv_linux_sdk/sysroot/usr/lib32/ilp32"
@@ -29,7 +29,7 @@
 // CC1-RV32-LINUX-ILP32D: 
"--sysroot={{.*}}/Inputs/multilib_riscv_linux_sdk/sysroot"
 // CC1-RV32-LINUX-ILP32D: "-m" "elf32lriscv"
 // CC1-RV32-LINUX-ILP32D: "-dynamic-linker" "/lib/ld-linux-riscv32-ilp32d.so.1"
-// CC1-RV32-LINUX-ILP32D: 
"{{.*}}/Inputs/multilib_riscv_linux_sdk/lib/gcc/riscv64-unknown-linux-gnu/7.2.0/lib32/ilp32d/crtbegin.o"
+// CC1-RV32-LINUX-ILP32D: 
"{{.*}}/Inputs/multilib_riscv_linux_sdk/lib/gcc/riscv64-unknown-linux-gnu/7.2.0/lib32/ilp32d{{/|}}crtbegin.o"
 // CC1-RV32-LINUX-ILP32D: 
"-L{{.*}}/Inputs/multilib_riscv_linux_sdk/lib/gcc/riscv64-unknown-linux-gnu/7.2.0/lib32/ilp32d"
 // CC1-RV32-LINUX-ILP32D: 
"-L{{.*}}/Inputs/multilib_riscv_linux_sdk/sysroot/lib32/ilp32d"
 // CC1-RV32-LINUX-ILP32D: 
"-L{{.*}}/Inputs/multilib_riscv_linux_sdk/sysroot/usr/lib32/ilp32d"


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


r351540 - [analyzer] Unbreak building of SymbolReaperTest true BUILD_SHARED_LIBS=True

2019-01-18 Thread Alex Bradbury via cfe-commits
Author: asb
Date: Fri Jan 18 02:13:07 2019
New Revision: 351540

URL: http://llvm.org/viewvc/llvm-project?rev=351540&view=rev
Log:
[analyzer] Unbreak building of SymbolReaperTest true BUILD_SHARED_LIBS=True

Extra dependencies need to be listed for StaticAnalysisTests in order for
linking to succeed when BUILD_SHARED_LIBS=True.


Modified:
cfe/trunk/unittests/StaticAnalyzer/CMakeLists.txt

Modified: cfe/trunk/unittests/StaticAnalyzer/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/StaticAnalyzer/CMakeLists.txt?rev=351540&r1=351539&r2=351540&view=diff
==
--- cfe/trunk/unittests/StaticAnalyzer/CMakeLists.txt (original)
+++ cfe/trunk/unittests/StaticAnalyzer/CMakeLists.txt Fri Jan 18 02:13:07 2019
@@ -12,6 +12,9 @@ target_link_libraries(StaticAnalysisTest
   PRIVATE
   clangBasic
   clangAnalysis
+  clangAST
+  clangASTMatchers
+  clangCrossTU
   clangFrontend
   clangSerialization
   clangStaticAnalyzerCore


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: r347720 - [RISCV] Mark unit tests as "requires: riscv-registered-target"

2018-11-29 Thread Alex Bradbury via cfe-commits
On Tue, 27 Nov 2018 at 22:56, Mandeep Singh Grang via cfe-commits
 wrote:
>
> Author: mgrang
> Date: Tue Nov 27 14:53:57 2018
> New Revision: 347720
>
> URL: http://llvm.org/viewvc/llvm-project?rev=347720&view=rev
> Log:
> [RISCV] Mark unit tests as "requires: riscv-registered-target"
>
> Some of these tests break if the RISCV backend has not been built.
>
> Reland D54816.
>
> Modified:
> cfe/trunk/test/Driver/riscv-abi.c
> cfe/trunk/test/Driver/riscv-arch.c
> cfe/trunk/test/Driver/riscv-features.c
> cfe/trunk/test/Driver/riscv-gnutools.c
> cfe/trunk/test/Driver/riscv32-toolchain.c
> cfe/trunk/test/Driver/riscv64-toolchain.c

Hi Mandeep,

Maybe I'm missing something obvious but I'm a bit confused - what in
these tests requires that lib/Target/RISCV was built?

These tests obviously don't fail on the standard builders for instance.

Thanks,

Alex
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: r347720 - [RISCV] Mark unit tests as "requires: riscv-registered-target"

2018-12-05 Thread Alex Bradbury via cfe-commits
On Thu, 29 Nov 2018 at 09:44, Alex Bradbury  wrote:
>
> On Tue, 27 Nov 2018 at 22:56, Mandeep Singh Grang via cfe-commits
>  wrote:
> >
> > Author: mgrang
> > Date: Tue Nov 27 14:53:57 2018
> > New Revision: 347720
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=347720&view=rev
> > Log:
> > [RISCV] Mark unit tests as "requires: riscv-registered-target"
> >
> > Some of these tests break if the RISCV backend has not been built.
> >
> > Reland D54816.
> >
> > Modified:
> > cfe/trunk/test/Driver/riscv-abi.c
> > cfe/trunk/test/Driver/riscv-arch.c
> > cfe/trunk/test/Driver/riscv-features.c
> > cfe/trunk/test/Driver/riscv-gnutools.c
> > cfe/trunk/test/Driver/riscv32-toolchain.c
> > cfe/trunk/test/Driver/riscv64-toolchain.c
>
> Hi Mandeep,
>
> Maybe I'm missing something obvious but I'm a bit confused - what in
> these tests requires that lib/Target/RISCV was built?
>
> These tests obviously don't fail on the standard builders for instance.

Hi Mandeep, any thoughts on the question above?

Thanks,

Alex
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


r357693 - [RISCV][NFC] s/riscv32-linux-unknown-elf/riscv32-unknown-linux-gnu in test/Driver/riscv32-toolchain.c

2019-04-04 Thread Alex Bradbury via cfe-commits
Author: asb
Date: Thu Apr  4 06:51:41 2019
New Revision: 357693

URL: http://llvm.org/viewvc/llvm-project?rev=357693&view=rev
Log:
[RISCV][NFC] s/riscv32-linux-unknown-elf/riscv32-unknown-linux-gnu in 
test/Driver/riscv32-toolchain.c

riscv32-linux-unknown-elf was a weird thing to test for as it doesn't match
the triple used in any common RISC-V toolchain distributions (e.g.
riscv-gnu-toolchain scripts produce riscv{32,64}-unknown-linux-gnu).


Modified:
cfe/trunk/test/Driver/riscv32-toolchain.c

Modified: cfe/trunk/test/Driver/riscv32-toolchain.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/riscv32-toolchain.c?rev=357693&r1=357692&r2=357693&view=diff
==
--- cfe/trunk/test/Driver/riscv32-toolchain.c (original)
+++ cfe/trunk/test/Driver/riscv32-toolchain.c Thu Apr  4 06:51:41 2019
@@ -68,7 +68,7 @@
 // CXX-RV32-BAREMETAL-NOSYSROOT-ILP32: 
"{{.*}}/Inputs/basic_riscv32_tree/lib/gcc/riscv32-unknown-elf/8.0.1{{/|}}crtend.o"
 
 // RUN: %clang %s -### -no-canonical-prefixes -fuse-ld=ld \
-// RUN:   -target riscv32-linux-unknown-elf \
+// RUN:   -target riscv32-unknown-linux-gnu \
 // RUN:   --gcc-toolchain=%S/Inputs/multilib_riscv_linux_sdk \
 // RUN:   --sysroot=%S/Inputs/multilib_riscv_linux_sdk/sysroot 2>&1 \
 // RUN:   | FileCheck -check-prefix=C-RV32-LINUX-MULTI-ILP32 %s
@@ -84,7 +84,7 @@
 // C-RV32-LINUX-MULTI-ILP32: 
"-L{{.*}}/Inputs/multilib_riscv_linux_sdk/sysroot/usr/lib32/ilp32"
 
 // RUN: %clang %s -### -no-canonical-prefixes -fuse-ld=ld \
-// RUN:   -target riscv32-linux-unknown-elf -march=rv32imafd -mabi=ilp32d \
+// RUN:   -target riscv32-unknown-linux-gnu -march=rv32imafd -mabi=ilp32d \
 // RUN:   --gcc-toolchain=%S/Inputs/multilib_riscv_linux_sdk \
 // RUN:   --sysroot=%S/Inputs/multilib_riscv_linux_sdk/sysroot 2>&1 \
 // RUN:   | FileCheck -check-prefix=C-RV32-LINUX-MULTI-ILP32D %s


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


r357699 - [RISCV] Collect library directories and triples for riscv64 triple too

2019-04-04 Thread Alex Bradbury via cfe-commits
Author: asb
Date: Thu Apr  4 07:18:26 2019
New Revision: 357699

URL: http://llvm.org/viewvc/llvm-project?rev=357699&view=rev
Log:
[RISCV] Collect library directories and triples for riscv64 triple too

When setting up library and tools paths when detecting an accompanying GCC
installation only riscv32 was handled. As a consequence when targetting
riscv64 neither the linker nor libraries would be found. This adds handling
and tests for riscv64.

Differential Revision: https://reviews.llvm.org/D53392
Patch by Edward Jones.


Added:
cfe/trunk/test/Driver/Inputs/basic_riscv64_tree/
cfe/trunk/test/Driver/Inputs/basic_riscv64_tree/bin/
cfe/trunk/test/Driver/Inputs/basic_riscv64_tree/bin/riscv64-unknown-elf-ld  
 (with props)
cfe/trunk/test/Driver/Inputs/basic_riscv64_tree/lib/
cfe/trunk/test/Driver/Inputs/basic_riscv64_tree/lib/gcc/
cfe/trunk/test/Driver/Inputs/basic_riscv64_tree/lib/gcc/riscv64-unknown-elf/

cfe/trunk/test/Driver/Inputs/basic_riscv64_tree/lib/gcc/riscv64-unknown-elf/8.0.1/
cfe/trunk/test/Driver/Inputs/basic_riscv64_tree/riscv64-unknown-elf/
cfe/trunk/test/Driver/Inputs/basic_riscv64_tree/riscv64-unknown-elf/include/

cfe/trunk/test/Driver/Inputs/basic_riscv64_tree/riscv64-unknown-elf/include/c++/

cfe/trunk/test/Driver/Inputs/basic_riscv64_tree/riscv64-unknown-elf/include/c++/8.0.1/

cfe/trunk/test/Driver/Inputs/basic_riscv64_tree/riscv64-unknown-elf/include/c++/8.0.1/.keep
cfe/trunk/test/Driver/Inputs/basic_riscv64_tree/riscv64-unknown-elf/lib/
Modified:
cfe/trunk/lib/Driver/ToolChains/Gnu.cpp
cfe/trunk/test/Driver/riscv64-toolchain.c

Modified: cfe/trunk/lib/Driver/ToolChains/Gnu.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Gnu.cpp?rev=357699&r1=357698&r2=357699&view=diff
==
--- cfe/trunk/lib/Driver/ToolChains/Gnu.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains/Gnu.cpp Thu Apr  4 07:18:26 2019
@@ -1976,10 +1976,14 @@ void Generic_GCC::GCCInstallationDetecto
   "powerpc64le-linux-gnu", "powerpc64le-unknown-linux-gnu",
   "powerpc64le-suse-linux", "ppc64le-redhat-linux"};
 
-  static const char *const RISCV32LibDirs[] = {"/lib", "/lib32"};
-  static const char *const RISCVTriples[] = {"riscv32-unknown-linux-gnu",
- "riscv64-unknown-linux-gnu",
- "riscv32-unknown-elf"};
+  static const char *const RISCV32LibDirs[] = {"/lib32", "/lib"};
+  static const char *const RISCV32Triples[] = {"riscv32-unknown-linux-gnu",
+   "riscv32-linux-gnu",
+   "riscv32-unknown-elf"};
+  static const char *const RISCV64LibDirs[] = {"/lib64", "/lib"};
+  static const char *const RISCV64Triples[] = {"riscv64-unknown-linux-gnu",
+   "riscv64-linux-gnu",
+   "riscv64-unknown-elf"};
 
   static const char *const SPARCv8LibDirs[] = {"/lib32", "/lib"};
   static const char *const SPARCv8Triples[] = {"sparc-linux-gnu",
@@ -2209,9 +2213,15 @@ void Generic_GCC::GCCInstallationDetecto
 break;
   case llvm::Triple::riscv32:
 LibDirs.append(begin(RISCV32LibDirs), end(RISCV32LibDirs));
+TripleAliases.append(begin(RISCV32Triples), end(RISCV32Triples));
+BiarchLibDirs.append(begin(RISCV64LibDirs), end(RISCV64LibDirs));
+BiarchTripleAliases.append(begin(RISCV64Triples), end(RISCV64Triples));
+break;
+  case llvm::Triple::riscv64:
+LibDirs.append(begin(RISCV64LibDirs), end(RISCV64LibDirs));
+TripleAliases.append(begin(RISCV64Triples), end(RISCV64Triples));
 BiarchLibDirs.append(begin(RISCV32LibDirs), end(RISCV32LibDirs));
-TripleAliases.append(begin(RISCVTriples), end(RISCVTriples));
-BiarchTripleAliases.append(begin(RISCVTriples), end(RISCVTriples));
+BiarchTripleAliases.append(begin(RISCV32Triples), end(RISCV32Triples));
 break;
   case llvm::Triple::sparc:
   case llvm::Triple::sparcel:

Added: 
cfe/trunk/test/Driver/Inputs/basic_riscv64_tree/bin/riscv64-unknown-elf-ld
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/Inputs/basic_riscv64_tree/bin/riscv64-unknown-elf-ld?rev=357699&view=auto
==
--- cfe/trunk/test/Driver/Inputs/basic_riscv64_tree/bin/riscv64-unknown-elf-ld 
(added)
+++ cfe/trunk/test/Driver/Inputs/basic_riscv64_tree/bin/riscv64-unknown-elf-ld 
Thu Apr  4 07:18:26 2019
@@ -0,0 +1 @@
+#!/bin/true

Propchange: 
cfe/trunk/test/Driver/Inputs/basic_riscv64_tree/bin/riscv64-unknown-elf-ld
--
svn:executable = *

Added: 
cfe/trunk/test/Driver/Inputs/basic_riscv64_tree/riscv64-unknown-elf/include/c++/8.0.1/.keep
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driv

r357702 - [RISCV] Fix rL357699 by adding missing zero-length files

2019-04-04 Thread Alex Bradbury via cfe-commits
Author: asb
Date: Thu Apr  4 07:36:07 2019
New Revision: 357702

URL: http://llvm.org/viewvc/llvm-project?rev=357702&view=rev
Log:
[RISCV] Fix rL357699 by adding missing zero-length files

svn add doesn't play very nicely here...

Added:

cfe/trunk/test/Driver/Inputs/basic_riscv64_tree/lib/gcc/riscv64-unknown-elf/8.0.1/crtbegin.o

cfe/trunk/test/Driver/Inputs/basic_riscv64_tree/lib/gcc/riscv64-unknown-elf/8.0.1/crtend.o

cfe/trunk/test/Driver/Inputs/basic_riscv64_tree/riscv64-unknown-elf/lib/crt0.o

Added: 
cfe/trunk/test/Driver/Inputs/basic_riscv64_tree/lib/gcc/riscv64-unknown-elf/8.0.1/crtbegin.o
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/Inputs/basic_riscv64_tree/lib/gcc/riscv64-unknown-elf/8.0.1/crtbegin.o?rev=357702&view=auto
==
(empty)

Added: 
cfe/trunk/test/Driver/Inputs/basic_riscv64_tree/lib/gcc/riscv64-unknown-elf/8.0.1/crtend.o
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/Inputs/basic_riscv64_tree/lib/gcc/riscv64-unknown-elf/8.0.1/crtend.o?rev=357702&view=auto
==
(empty)

Added: 
cfe/trunk/test/Driver/Inputs/basic_riscv64_tree/riscv64-unknown-elf/lib/crt0.o
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/Inputs/basic_riscv64_tree/riscv64-unknown-elf/lib/crt0.o?rev=357702&view=auto
==
(empty)


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


r357989 - [RISCV][NFC] Refactor RISC-V ABI lowering tests in preparation for hard float patches

2019-04-09 Thread Alex Bradbury via cfe-commits
Author: asb
Date: Tue Apr  9 03:12:49 2019
New Revision: 357989

URL: http://llvm.org/viewvc/llvm-project?rev=357989&view=rev
Log:
[RISCV][NFC] Refactor RISC-V ABI lowering tests in preparation for hard float 
patches

Split tests in to files representing the subset of RISC-V ABIs they should
have identical output for.


Added:
cfe/trunk/test/CodeGen/riscv32-ilp32-abi.c
cfe/trunk/test/CodeGen/riscv32-ilp32-ilp32f-abi.c
cfe/trunk/test/CodeGen/riscv32-ilp32-ilp32f-ilp32d-abi.c
cfe/trunk/test/CodeGen/riscv64-lp64-abi.c
cfe/trunk/test/CodeGen/riscv64-lp64-lp64f-abi.c
cfe/trunk/test/CodeGen/riscv64-lp64-lp64f-lp64d-abi.c
Removed:
cfe/trunk/test/CodeGen/riscv32-abi.c
cfe/trunk/test/CodeGen/riscv64-abi.c

Removed: cfe/trunk/test/CodeGen/riscv32-abi.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/riscv32-abi.c?rev=357988&view=auto
==
--- cfe/trunk/test/CodeGen/riscv32-abi.c (original)
+++ cfe/trunk/test/CodeGen/riscv32-abi.c (removed)
@@ -1,430 +0,0 @@
-// RUN: %clang_cc1 -triple riscv32 -emit-llvm %s -o - | FileCheck %s
-// RUN: %clang_cc1 -triple riscv32 -emit-llvm -fforce-enable-int128 %s -o - \
-// RUN: | FileCheck %s -check-prefixes=CHECK,CHECK-FORCEINT128
-
-#include 
-#include 
-
-// CHECK-LABEL: define void @f_void()
-void f_void(void) {}
-
-// Scalar arguments and return values smaller than the word size are extended
-// according to the sign of their type, up to 32 bits
-
-// CHECK-LABEL: define zeroext i1 @f_scalar_0(i1 zeroext %x)
-_Bool f_scalar_0(_Bool x) { return x; }
-
-// CHECK-LABEL: define signext i8 @f_scalar_1(i8 signext %x)
-int8_t f_scalar_1(int8_t x) { return x; }
-
-// CHECK-LABEL: define zeroext i8 @f_scalar_2(i8 zeroext %x)
-uint8_t f_scalar_2(uint8_t x) { return x; }
-
-// CHECK-LABEL: define i32 @f_scalar_3(i32 %x)
-int32_t f_scalar_3(int32_t x) { return x; }
-
-// CHECK-LABEL: define i64 @f_scalar_4(i64 %x)
-int64_t f_scalar_4(int64_t x) { return x; }
-
-#ifdef __SIZEOF_INT128__
-// CHECK-FORCEINT128-LABEL: define i128 @f_scalar_5(i128 %x)
-__int128_t f_scalar_5(__int128_t x) { return x; }
-#endif
-
-// CHECK-LABEL: define float @f_fp_scalar_1(float %x)
-float f_fp_scalar_1(float x) { return x; }
-
-// CHECK-LABEL: define double @f_fp_scalar_2(double %x)
-double f_fp_scalar_2(double x) { return x; }
-
-// Scalars larger than 2*xlen are passed/returned indirect. However, the
-// RISC-V LLVM backend can handle this fine, so the function doesn't need to
-// be modified.
-
-// CHECK-LABEL: define fp128 @f_fp_scalar_3(fp128 %x)
-long double f_fp_scalar_3(long double x) { return x; }
-
-// Empty structs or unions are ignored.
-
-struct empty_s {};
-
-// CHECK-LABEL: define void @f_agg_empty_struct()
-struct empty_s f_agg_empty_struct(struct empty_s x) {
-  return x;
-}
-
-union empty_u {};
-
-// CHECK-LABEL: define void @f_agg_empty_union()
-union empty_u f_agg_empty_union(union empty_u x) {
-  return x;
-}
-
-// Aggregates <= 2*xlen may be passed in registers, so will be coerced to
-// integer arguments. The rules for return are the same.
-
-struct tiny {
-  uint8_t a, b, c, d;
-};
-
-// CHECK-LABEL: define void @f_agg_tiny(i32 %x.coerce)
-void f_agg_tiny(struct tiny x) {
-  x.a += x.b;
-  x.c += x.d;
-}
-
-// CHECK-LABEL: define i32 @f_agg_tiny_ret()
-struct tiny f_agg_tiny_ret() {
-  return (struct tiny){1, 2, 3, 4};
-}
-
-typedef uint8_t v4i8 __attribute__((vector_size(4)));
-typedef int32_t v1i32 __attribute__((vector_size(4)));
-
-// CHECK-LABEL: define void @f_vec_tiny_v4i8(i32 %x.coerce)
-void f_vec_tiny_v4i8(v4i8 x) {
-  x[0] = x[1];
-  x[2] = x[3];
-}
-
-// CHECK-LABEL: define i32 @f_vec_tiny_v4i8_ret()
-v4i8 f_vec_tiny_v4i8_ret() {
-  return (v4i8){1, 2, 3, 4};
-}
-
-// CHECK-LABEL: define void @f_vec_tiny_v1i32(i32 %x.coerce)
-void f_vec_tiny_v1i32(v1i32 x) {
-  x[0] = 114;
-}
-
-// CHECK-LABEL: define i32 @f_vec_tiny_v1i32_ret()
-v1i32 f_vec_tiny_v1i32_ret() {
-  return (v1i32){1};
-}
-
-struct small {
-  int32_t a, *b;
-};
-
-// CHECK-LABEL: define void @f_agg_small([2 x i32] %x.coerce)
-void f_agg_small(struct small x) {
-  x.a += *x.b;
-  x.b = &x.a;
-}
-
-// CHECK-LABEL: define [2 x i32] @f_agg_small_ret()
-struct small f_agg_small_ret() {
-  return (struct small){1, 0};
-}
-
-typedef uint8_t v8i8 __attribute__((vector_size(8)));
-typedef int64_t v1i64 __attribute__((vector_size(8)));
-
-// CHECK-LABEL: define void @f_vec_small_v8i8(i64 %x.coerce)
-void f_vec_small_v8i8(v8i8 x) {
-  x[0] = x[7];
-}
-
-// CHECK-LABEL: define i64 @f_vec_small_v8i8_ret()
-v8i8 f_vec_small_v8i8_ret() {
-  return (v8i8){1, 2, 3, 4, 5, 6, 7, 8};
-}
-
-// CHECK-LABEL: define void @f_vec_small_v1i64(i64 %x.coerce)
-void f_vec_small_v1i64(v1i64 x) {
-  x[0] = 114;
-}
-
-// CHECK-LABEL: define i64 @f_vec_small_v1i64_ret()
-v1i64 f_vec_small_v1i64_ret() {
-  return (v1i64){1};
-}
-
-// Aggregates of 2*xlen size and 2*xlen alignment should be coerced to a
-// single 2*xlen-size

r357991 - [RISCV][NFC] Minor fixup for r357989

2019-04-09 Thread Alex Bradbury via cfe-commits
Author: asb
Date: Tue Apr  9 03:25:05 2019
New Revision: 357991

URL: http://llvm.org/viewvc/llvm-project?rev=357991&view=rev
Log:
[RISCV][NFC] Minor fixup for r357989

One of the tests in riscv64-lp64-lp64f-lp64d would have had a different
lowering for lp64f/lp64d as a float argument was missed.


Modified:
cfe/trunk/test/CodeGen/riscv64-lp64-lp64f-lp64d-abi.c

Modified: cfe/trunk/test/CodeGen/riscv64-lp64-lp64f-lp64d-abi.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/riscv64-lp64-lp64f-lp64d-abi.c?rev=357991&r1=357990&r2=357991&view=diff
==
--- cfe/trunk/test/CodeGen/riscv64-lp64-lp64f-lp64d-abi.c (original)
+++ cfe/trunk/test/CodeGen/riscv64-lp64-lp64f-lp64d-abi.c Tue Apr  9 03:25:05 
2019
@@ -188,8 +188,8 @@ int f_scalar_stack_1(struct tiny a, stru
   return g + h;
 }
 
-// CHECK-LABEL: define signext i32 @f_scalar_stack_2(i32 signext %a, i128 %b, 
float %c, fp128 %d, <32 x i8>*, i8 zeroext %f, i8 %g, i8 %h)
-int f_scalar_stack_2(int32_t a, __int128_t b, float c, long double d, v32i8 e,
+// CHECK-LABEL: define signext i32 @f_scalar_stack_2(i32 signext %a, i128 %b, 
i64 %c, fp128 %d, <32 x i8>*, i8 zeroext %f, i8 %g, i8 %h)
+int f_scalar_stack_2(int32_t a, __int128_t b, int64_t c, long double d, v32i8 
e,
  uint8_t f, int8_t g, uint8_t h) {
   return g + h;
 }


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


r357993 - [RISCV] Unbreak test from r357989

2019-04-09 Thread Alex Bradbury via cfe-commits
Author: asb
Date: Tue Apr  9 03:44:47 2019
New Revision: 357993

URL: http://llvm.org/viewvc/llvm-project?rev=357993&view=rev
Log:
[RISCV] Unbreak test from r357989

There were some errors in the committed test checks, left in due to a git
stash apply mishap.


Modified:
cfe/trunk/test/CodeGen/riscv32-ilp32-ilp32f-abi.c
cfe/trunk/test/CodeGen/riscv32-ilp32-ilp32f-ilp32d-abi.c

Modified: cfe/trunk/test/CodeGen/riscv32-ilp32-ilp32f-abi.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/riscv32-ilp32-ilp32f-abi.c?rev=357993&r1=357992&r2=357993&view=diff
==
--- cfe/trunk/test/CodeGen/riscv32-ilp32-ilp32f-abi.c (original)
+++ cfe/trunk/test/CodeGen/riscv32-ilp32-ilp32f-abi.c Tue Apr  9 03:44:47 2019
@@ -35,8 +35,8 @@ int f_scalar_stack_1(int32_t a, int64_t
 // the presence of large return values that consume a register due to the need
 // to pass a pointer.
 
-// CHECK-LABEL: define void @f_scalar_stack_2(%struct.large* noalias sret 
%agg.result, int32_t %a, i64 %b, i64 %c, fp128 %d, i8 zeroext %e, i8 %f, i8 %g)
-struct large f_scalar_stack_2(int32_t a, int64_t b, double c, long double d,
+// CHECK-LABEL: define void @f_scalar_stack_2(%struct.large* noalias sret 
%agg.result, i32 %a, i64 %b, i64 %c, fp128 %d, i8 zeroext %e, i8 %f, i8 %g)
+struct large f_scalar_stack_2(int32_t a, int64_t b, int64_t c, long double d,
   uint8_t e, int8_t f, uint8_t g) {
   return (struct large){a, e, f, g};
 }
@@ -44,7 +44,7 @@ struct large f_scalar_stack_2(int32_t a,
 // Aggregates and >=XLen scalars passed on the stack should be lowered just as
 // they would be if passed via registers.
 
-// CHECK-LABEL: define void @f_scalar_stack_3(double %a, i64 %b, double %c, 
i64 %d, i32 %e, i64 %f, int32_t %g, double %h, fp128 %i)
+// CHECK-LABEL: define void @f_scalar_stack_3(double %a, i64 %b, double %c, 
i64 %d, i32 %e, i64 %f, i32 %g, double %h, fp128 %i)
 void f_scalar_stack_3(double a, int64_t b, double c, int64_t d, int e,
   int64_t f, int32_t g, double h, long double i) {}
 

Modified: cfe/trunk/test/CodeGen/riscv32-ilp32-ilp32f-ilp32d-abi.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/riscv32-ilp32-ilp32f-ilp32d-abi.c?rev=357993&r1=357992&r2=357993&view=diff
==
--- cfe/trunk/test/CodeGen/riscv32-ilp32-ilp32f-ilp32d-abi.c (original)
+++ cfe/trunk/test/CodeGen/riscv32-ilp32-ilp32f-ilp32d-abi.c Tue Apr  9 
03:44:47 2019
@@ -203,13 +203,13 @@ int f_scalar_stack_1(struct tiny a, stru
 // the presence of large return values that consume a register due to the need
 // to pass a pointer.
 
-// CHECK-LABEL: define void @f_scalar_stack_2(%struct.large* noalias sret 
%agg.result, i32 %a, i64 %b, double %c, fp128 %d, i8 zeroext %e, i8 %f, i8 %g)
+// CHECK-LABEL: define void @f_scalar_stack_2(%struct.large* noalias sret 
%agg.result, i32 %a, i64 %b, i64 %c, fp128 %d, i8 zeroext %e, i8 %f, i8 %g)
 struct large f_scalar_stack_2(int32_t a, int64_t b, int64_t c, long double d,
   uint8_t e, int8_t f, uint8_t g) {
   return (struct large){a, e, f, g};
 }
 
-// CHECK-LABEL: define fp128 @f_scalar_stack_4(i32 %a, i64 %b, double %c, 
fp128 %d, i8 zeroext %e, i8 %f, i8 %g)
+// CHECK-LABEL: define fp128 @f_scalar_stack_4(i32 %a, i64 %b, i64 %c, fp128 
%d, i8 zeroext %e, i8 %f, i8 %g)
 long double f_scalar_stack_4(int32_t a, int64_t b, int64_t c, long double d,
  uint8_t e, int8_t f, uint8_t g) {
   return d;


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: r365825 - [clang-shlib] Fix clang-shlib for PRIVATE dependencies

2019-07-12 Thread Alex Bradbury via cfe-commits
On Thu, 11 Jul 2019 at 22:20, Shoaib Meenai via cfe-commits
 wrote:
>
> Author: smeenai
> Date: Thu Jul 11 14:20:38 2019
> New Revision: 365825
>
> URL: http://llvm.org/viewvc/llvm-project?rev=365825&view=rev
> Log:
> [clang-shlib] Fix clang-shlib for PRIVATE dependencies
>
> Any static library with a PRIVATE dependency ends up with a
> $ generator expression in its INTERFACE_LINK_LIBRARIES,
> which won't be evaluated by the $, so we end up
> with an unevaluated generator expression in the generated build file and
> Ninja chokes on the dollar sign. Just use the static library directly
> for its dependencies instead of trying to propagate dependencies
> manually.
>
> Differential Revision: https://reviews.llvm.org/D64579

This seems to break a -DBUILD_SHARED_LIBS build for me. It fails at
the point of linking lib/libclang_shared.so.9svn with errors like:
ld.lld: error: undefined symbol: llvm::llvm_unreachable_internal(char
const*, char const*, unsigned int)
>>> referenced by Attributes.cpp:34 
>>> (/home/asb/llvm-project/clang/lib/Basic/Attributes.cpp:34)
>>>   
>>> tools/clang/lib/Basic/CMakeFiles/obj.clangBasic.dir/Attributes.cpp.o:(clang::attr::getSubjectMatchRuleSpelling(clang::attr::SubjectMatchRule))

ld.lld: error: undefined symbol: llvm::llvm_unreachable_internal(char
const*, char const*, unsigned int)
>>> referenced by TargetCXXABI.h:168 
>>> (/home/asb/llvm-project/clang/include/clang/Basic/TargetCXXABI.h:168)
>>>   
>>> tools/clang/lib/Basic/CMakeFiles/obj.clangBasic.dir/Attributes.cpp.o:(clang::TargetCXXABI::isMicrosoft()
>>>  const)

ld.lld: error: undefined symbol: llvm::llvm_unreachable_internal(char
const*, char const*, unsigned int)
>>> referenced by TargetCXXABI.h:149 
>>> (/home/asb/llvm-project/clang/include/clang/Basic/TargetCXXABI.h:149)
>>>   
>>> tools/clang/lib/Basic/CMakeFiles/obj.clangBasic.dir/Attributes.cpp.o:(clang::TargetCXXABI::isItaniumFamily()
>>>  const)

ld.lld: error: undefined symbol: llvm::EnableABIBreakingChecks
>>> referenced by Attributes.cpp
>>>   
>>> tools/clang/lib/Basic/CMakeFiles/obj.clangBasic.dir/Attributes.cpp.o:(llvm::VerifyEnableABIBreakingChecks)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


r366450 - [RISCV] Hard float ABI support

2019-07-18 Thread Alex Bradbury via cfe-commits
Author: asb
Date: Thu Jul 18 08:33:41 2019
New Revision: 366450

URL: http://llvm.org/viewvc/llvm-project?rev=366450&view=rev
Log:
[RISCV] Hard float ABI support

The RISC-V hard float calling convention requires the frontend to:

* Detect cases where, once "flattened", a struct can be passed using
int+fp or fp+fp registers under the hard float ABI and coerce to the
appropriate type(s) * Track usage of GPRs and FPRs in order to gate the
above, and to
determine when signext/zeroext attributes must be added to integer
scalars

This patch attempts to do this in compliance with the documented ABI,
and uses ABIArgInfo::CoerceAndExpand in order to do this. @rjmccall, as
author of that code I've tagged you as reviewer for initial feedback on
my usage.

Note that a previous version of the ABI indicated that when passing an
int+fp struct using a GPR+FPR, the int would need to be sign or
zero-extended appropriately. GCC never did this and the ABI was changed,
which makes life easier as ABIArgInfo::CoerceAndExpand can't currently
handle sign/zero-extension attributes.

Differential Revision: https://reviews.llvm.org/D60456

Added:
cfe/trunk/test/CodeGen/riscv32-ilp32d-abi.c
cfe/trunk/test/CodeGen/riscv32-ilp32f-abi.c
cfe/trunk/test/CodeGen/riscv32-ilp32f-ilp32d-abi.c
cfe/trunk/test/CodeGen/riscv64-lp64d-abi.c
cfe/trunk/test/CodeGen/riscv64-lp64f-lp64d-abi.c
Modified:
cfe/trunk/lib/Basic/Targets/RISCV.cpp
cfe/trunk/lib/Basic/Targets/RISCV.h
cfe/trunk/lib/CodeGen/TargetInfo.cpp
cfe/trunk/test/CodeGen/riscv32-ilp32-ilp32f-abi.c
cfe/trunk/test/CodeGen/riscv32-ilp32-ilp32f-ilp32d-abi.c
cfe/trunk/test/CodeGen/riscv64-lp64-lp64f-abi.c
cfe/trunk/test/CodeGen/riscv64-lp64-lp64f-lp64d-abi.c
cfe/trunk/test/Preprocessor/riscv-target-features.c

Modified: cfe/trunk/lib/Basic/Targets/RISCV.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets/RISCV.cpp?rev=366450&r1=366449&r2=366450&view=diff
==
--- cfe/trunk/lib/Basic/Targets/RISCV.cpp (original)
+++ cfe/trunk/lib/Basic/Targets/RISCV.cpp Thu Jul 18 08:33:41 2019
@@ -65,9 +65,18 @@ void RISCVTargetInfo::getTargetDefines(c
   Builder.defineMacro("__riscv");
   bool Is64Bit = getTriple().getArch() == llvm::Triple::riscv64;
   Builder.defineMacro("__riscv_xlen", Is64Bit ? "64" : "32");
-  // TODO: modify when more code models and ABIs are supported.
+  // TODO: modify when more code models are supported.
   Builder.defineMacro("__riscv_cmodel_medlow");
-  Builder.defineMacro("__riscv_float_abi_soft");
+
+  StringRef ABIName = getABI();
+  if (ABIName == "ilp32f" || ABIName == "lp64f")
+Builder.defineMacro("__riscv_float_abi_single");
+  else if (ABIName == "ilp32d" || ABIName == "lp64d")
+Builder.defineMacro("__riscv_float_abi_double");
+  else if (ABIName == "ilp32e")
+Builder.defineMacro("__riscv_abi_rve");
+  else
+Builder.defineMacro("__riscv_float_abi_soft");
 
   if (HasM) {
 Builder.defineMacro("__riscv_mul");

Modified: cfe/trunk/lib/Basic/Targets/RISCV.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets/RISCV.h?rev=366450&r1=366449&r2=366450&view=diff
==
--- cfe/trunk/lib/Basic/Targets/RISCV.h (original)
+++ cfe/trunk/lib/Basic/Targets/RISCV.h Thu Jul 18 08:33:41 2019
@@ -87,8 +87,7 @@ public:
   }
 
   bool setABI(const std::string &Name) override {
-// TODO: support ilp32f and ilp32d ABIs.
-if (Name == "ilp32") {
+if (Name == "ilp32" || Name == "ilp32f" || Name == "ilp32d") {
   ABI = Name;
   return true;
 }
@@ -105,8 +104,7 @@ public:
   }
 
   bool setABI(const std::string &Name) override {
-// TODO: support lp64f and lp64d ABIs.
-if (Name == "lp64") {
+if (Name == "lp64" || Name == "lp64f" || Name == "lp64d") {
   ABI = Name;
   return true;
 }

Modified: cfe/trunk/lib/CodeGen/TargetInfo.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/TargetInfo.cpp?rev=366450&r1=366449&r2=366450&view=diff
==
--- cfe/trunk/lib/CodeGen/TargetInfo.cpp (original)
+++ cfe/trunk/lib/CodeGen/TargetInfo.cpp Thu Jul 18 08:33:41 2019
@@ -9188,25 +9188,44 @@ static bool getTypeString(SmallStringEnc
 namespace {
 class RISCVABIInfo : public DefaultABIInfo {
 private:
-  unsigned XLen; // Size of the integer ('x') registers in bits.
+  // Size of the integer ('x') registers in bits.
+  unsigned XLen;
+  // Size of the floating point ('f') registers in bits. Note that the target
+  // ISA might have a wider FLen than the selected ABI (e.g. an RV32IF target
+  // with soft float ABI has FLen==0).
+  unsigned FLen;
   static const int NumArgGPRs = 8;
+  static const int NumArgFPRs = 8;
+  bool detectFPCCEligibleStructHelper(QualType Ty, CharUnits CurOff,
+  llvm::T

r366454 - Revert "[RISCV] Hard float ABI support" r366450

2019-07-18 Thread Alex Bradbury via cfe-commits
Author: asb
Date: Thu Jul 18 09:13:17 2019
New Revision: 366454

URL: http://llvm.org/viewvc/llvm-project?rev=366454&view=rev
Log:
Revert "[RISCV] Hard float ABI support" r366450

The commit was missing a few hunks. Will fix and recommit.

Removed:
cfe/trunk/test/CodeGen/riscv32-ilp32d-abi.c
cfe/trunk/test/CodeGen/riscv32-ilp32f-abi.c
cfe/trunk/test/CodeGen/riscv32-ilp32f-ilp32d-abi.c
cfe/trunk/test/CodeGen/riscv64-lp64d-abi.c
cfe/trunk/test/CodeGen/riscv64-lp64f-lp64d-abi.c
Modified:
cfe/trunk/lib/Basic/Targets/RISCV.cpp
cfe/trunk/lib/Basic/Targets/RISCV.h
cfe/trunk/lib/CodeGen/TargetInfo.cpp
cfe/trunk/test/CodeGen/riscv32-ilp32-ilp32f-abi.c
cfe/trunk/test/CodeGen/riscv32-ilp32-ilp32f-ilp32d-abi.c
cfe/trunk/test/CodeGen/riscv64-lp64-lp64f-abi.c
cfe/trunk/test/CodeGen/riscv64-lp64-lp64f-lp64d-abi.c
cfe/trunk/test/Preprocessor/riscv-target-features.c

Modified: cfe/trunk/lib/Basic/Targets/RISCV.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets/RISCV.cpp?rev=366454&r1=366453&r2=366454&view=diff
==
--- cfe/trunk/lib/Basic/Targets/RISCV.cpp (original)
+++ cfe/trunk/lib/Basic/Targets/RISCV.cpp Thu Jul 18 09:13:17 2019
@@ -65,18 +65,9 @@ void RISCVTargetInfo::getTargetDefines(c
   Builder.defineMacro("__riscv");
   bool Is64Bit = getTriple().getArch() == llvm::Triple::riscv64;
   Builder.defineMacro("__riscv_xlen", Is64Bit ? "64" : "32");
-  // TODO: modify when more code models are supported.
+  // TODO: modify when more code models and ABIs are supported.
   Builder.defineMacro("__riscv_cmodel_medlow");
-
-  StringRef ABIName = getABI();
-  if (ABIName == "ilp32f" || ABIName == "lp64f")
-Builder.defineMacro("__riscv_float_abi_single");
-  else if (ABIName == "ilp32d" || ABIName == "lp64d")
-Builder.defineMacro("__riscv_float_abi_double");
-  else if (ABIName == "ilp32e")
-Builder.defineMacro("__riscv_abi_rve");
-  else
-Builder.defineMacro("__riscv_float_abi_soft");
+  Builder.defineMacro("__riscv_float_abi_soft");
 
   if (HasM) {
 Builder.defineMacro("__riscv_mul");

Modified: cfe/trunk/lib/Basic/Targets/RISCV.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets/RISCV.h?rev=366454&r1=366453&r2=366454&view=diff
==
--- cfe/trunk/lib/Basic/Targets/RISCV.h (original)
+++ cfe/trunk/lib/Basic/Targets/RISCV.h Thu Jul 18 09:13:17 2019
@@ -87,7 +87,8 @@ public:
   }
 
   bool setABI(const std::string &Name) override {
-if (Name == "ilp32" || Name == "ilp32f" || Name == "ilp32d") {
+// TODO: support ilp32f and ilp32d ABIs.
+if (Name == "ilp32") {
   ABI = Name;
   return true;
 }
@@ -104,7 +105,8 @@ public:
   }
 
   bool setABI(const std::string &Name) override {
-if (Name == "lp64" || Name == "lp64f" || Name == "lp64d") {
+// TODO: support lp64f and lp64d ABIs.
+if (Name == "lp64") {
   ABI = Name;
   return true;
 }

Modified: cfe/trunk/lib/CodeGen/TargetInfo.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/TargetInfo.cpp?rev=366454&r1=366453&r2=366454&view=diff
==
--- cfe/trunk/lib/CodeGen/TargetInfo.cpp (original)
+++ cfe/trunk/lib/CodeGen/TargetInfo.cpp Thu Jul 18 09:13:17 2019
@@ -9188,44 +9188,25 @@ static bool getTypeString(SmallStringEnc
 namespace {
 class RISCVABIInfo : public DefaultABIInfo {
 private:
-  // Size of the integer ('x') registers in bits.
-  unsigned XLen;
-  // Size of the floating point ('f') registers in bits. Note that the target
-  // ISA might have a wider FLen than the selected ABI (e.g. an RV32IF target
-  // with soft float ABI has FLen==0).
-  unsigned FLen;
+  unsigned XLen; // Size of the integer ('x') registers in bits.
   static const int NumArgGPRs = 8;
-  static const int NumArgFPRs = 8;
-  bool detectFPCCEligibleStructHelper(QualType Ty, CharUnits CurOff,
-  llvm::Type *&Field1Ty,
-  CharUnits &Field1Off,
-  llvm::Type *&Field2Ty,
-  CharUnits &Field2Off) const;
 
 public:
-  RISCVABIInfo(CodeGen::CodeGenTypes &CGT, unsigned XLen, unsigned FLen)
-  : DefaultABIInfo(CGT), XLen(XLen), FLen(FLen) {}
+  RISCVABIInfo(CodeGen::CodeGenTypes &CGT, unsigned XLen)
+  : DefaultABIInfo(CGT), XLen(XLen) {}
 
   // DefaultABIInfo's classifyReturnType and classifyArgumentType are
   // non-virtual, but computeInfo is virtual, so we overload it.
   void computeInfo(CGFunctionInfo &FI) const override;
 
-  ABIArgInfo classifyArgumentType(QualType Ty, bool IsFixed, int &ArgGPRsLeft,
-  int &ArgFPRsLeft) const;
+  ABIArgInfo classifyArgumentType(QualType Ty, bool IsFixed,
+  int 

Re: r366450 - [RISCV] Hard float ABI support

2019-07-18 Thread Alex Bradbury via cfe-commits
Apologies, I cherry-picked the wrong version of the commit. Have
reverted and will re-land later.

On Thu, 18 Jul 2019 at 17:09, Ilya Biryukov  wrote:
>
> Hi Alex,
>
> I'm seeing a few test failures after your commit.
> Any ideas on how to fix this?
>
>
> Failing Tests (2):
> Clang :: Driver/riscv-abi.c
> Clang :: Preprocessor/riscv-target-features.c
>
> The failures are:
> /usr/local/google/home/ibiryukov/projects/llvm/clang/test/Preprocessor/riscv-target-features.c:71:18:
>  error: CHECK-DOUBLE: expected string not found in input
> // CHECK-DOUBLE: __riscv_float_abi_double 1
>  ^
> :1:1: note: scanning from here
> #define _ILP32 1
> ^
> :12:9: note: possible intended match here
> #define __CHAR_BIT__ 8
> ^
>
> /usr/local/google/home/ibiryukov/projects/llvm/clang/test/Driver/riscv-abi.c:16:18:
>  error: CHECK-ILP32F: expected string not found in input
> // CHECK-ILP32F: error: unknown target ABI 'ilp32f'
>  ^
> :1:1: note: scanning from here
> Hard-float 'f' ABI can't be used for a target that doesn't support the F 
> instruction set extension (ignoring target-abi)
> ^
> :1:93: note: possible intended match here
> Hard-float 'f' ABI can't be used for a target that doesn't support the F 
> instruction set extension (ignoring target-abi)
>
>
>
> On Thu, Jul 18, 2019 at 5:33 PM Alex Bradbury via cfe-commits 
>  wrote:
>>
>> Author: asb
>> Date: Thu Jul 18 08:33:41 2019
>> New Revision: 366450
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=366450&view=rev
>> Log:
>> [RISCV] Hard float ABI support
>>
>> The RISC-V hard float calling convention requires the frontend to:
>>
>> * Detect cases where, once "flattened", a struct can be passed using
>> int+fp or fp+fp registers under the hard float ABI and coerce to the
>> appropriate type(s) * Track usage of GPRs and FPRs in order to gate the
>> above, and to
>> determine when signext/zeroext attributes must be added to integer
>> scalars
>>
>> This patch attempts to do this in compliance with the documented ABI,
>> and uses ABIArgInfo::CoerceAndExpand in order to do this. @rjmccall, as
>> author of that code I've tagged you as reviewer for initial feedback on
>> my usage.
>>
>> Note that a previous version of the ABI indicated that when passing an
>> int+fp struct using a GPR+FPR, the int would need to be sign or
>> zero-extended appropriately. GCC never did this and the ABI was changed,
>> which makes life easier as ABIArgInfo::CoerceAndExpand can't currently
>> handle sign/zero-extension attributes.
>>
>> Differential Revision: https://reviews.llvm.org/D60456
>>
>> Added:
>> cfe/trunk/test/CodeGen/riscv32-ilp32d-abi.c
>> cfe/trunk/test/CodeGen/riscv32-ilp32f-abi.c
>> cfe/trunk/test/CodeGen/riscv32-ilp32f-ilp32d-abi.c
>> cfe/trunk/test/CodeGen/riscv64-lp64d-abi.c
>> cfe/trunk/test/CodeGen/riscv64-lp64f-lp64d-abi.c
>> Modified:
>> cfe/trunk/lib/Basic/Targets/RISCV.cpp
>> cfe/trunk/lib/Basic/Targets/RISCV.h
>> cfe/trunk/lib/CodeGen/TargetInfo.cpp
>> cfe/trunk/test/CodeGen/riscv32-ilp32-ilp32f-abi.c
>> cfe/trunk/test/CodeGen/riscv32-ilp32-ilp32f-ilp32d-abi.c
>> cfe/trunk/test/CodeGen/riscv64-lp64-lp64f-abi.c
>> cfe/trunk/test/CodeGen/riscv64-lp64-lp64f-lp64d-abi.c
>> cfe/trunk/test/Preprocessor/riscv-target-features.c
>>
>> Modified: cfe/trunk/lib/Basic/Targets/RISCV.cpp
>> URL: 
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets/RISCV.cpp?rev=366450&r1=366449&r2=366450&view=diff
>> ==
>> --- cfe/trunk/lib/Basic/Targets/RISCV.cpp (original)
>> +++ cfe/trunk/lib/Basic/Targets/RISCV.cpp Thu Jul 18 08:33:41 2019
>> @@ -65,9 +65,18 @@ void RISCVTargetInfo::getTargetDefines(c
>>Builder.defineMacro("__riscv");
>>bool Is64Bit = getTriple().getArch() == llvm::Triple::riscv64;
>>Builder.defineMacro("__riscv_xlen", Is64Bit ? "64" : "32");
>> -  // TODO: modify when more code models and ABIs are supported.
>> +  // TODO: modify when more code models are supported.
>>Builder.defineMacro("__riscv_cmodel_medlow");
>> -  Builder.defineMacro("__riscv_float_abi_soft");
>> +
>> +  StringRef ABIName = getABI();
>> +  if (ABIName == "ilp32f" || ABIName == "lp64f")
>> +Builder.defineMacro("__riscv_float_

r366480 - [RISCV] Hard float ABI support

2019-07-18 Thread Alex Bradbury via cfe-commits
Author: asb
Date: Thu Jul 18 11:29:59 2019
New Revision: 366480

URL: http://llvm.org/viewvc/llvm-project?rev=366480&view=rev
Log:
[RISCV] Hard float ABI support

The RISC-V hard float calling convention requires the frontend to:

* Detect cases where, once "flattened", a struct can be passed using
int+fp or fp+fp registers under the hard float ABI and coerce to the
appropriate type(s)
* Track usage of GPRs and FPRs in order to gate the above, and to
determine when signext/zeroext attributes must be added to integer
scalars

This patch attempts to do this in compliance with the documented ABI,
and uses ABIArgInfo::CoerceAndExpand in order to do this. @rjmccall, as
author of that code I've tagged you as reviewer for initial feedback on
my usage.

Note that a previous version of the ABI indicated that when passing an
int+fp struct using a GPR+FPR, the int would need to be sign or
zero-extended appropriately. GCC never did this and the ABI was changed,
which makes life easier as ABIArgInfo::CoerceAndExpand can't currently
handle sign/zero-extension attributes.

Re-landed after backing out 366450 due to missed hunks.

Differential Revision: https://reviews.llvm.org/D60456

Added:
cfe/trunk/test/CodeGen/riscv32-ilp32d-abi.c
cfe/trunk/test/CodeGen/riscv32-ilp32f-abi.c
cfe/trunk/test/CodeGen/riscv32-ilp32f-ilp32d-abi.c
cfe/trunk/test/CodeGen/riscv64-lp64d-abi.c
cfe/trunk/test/CodeGen/riscv64-lp64f-lp64d-abi.c
Modified:
cfe/trunk/lib/Basic/Targets/RISCV.cpp
cfe/trunk/lib/Basic/Targets/RISCV.h
cfe/trunk/lib/CodeGen/TargetInfo.cpp
cfe/trunk/test/CodeGen/riscv32-ilp32-ilp32f-abi.c
cfe/trunk/test/CodeGen/riscv32-ilp32-ilp32f-ilp32d-abi.c
cfe/trunk/test/CodeGen/riscv64-lp64-lp64f-abi.c
cfe/trunk/test/CodeGen/riscv64-lp64-lp64f-lp64d-abi.c
cfe/trunk/test/Driver/riscv-abi.c
cfe/trunk/test/Preprocessor/riscv-target-features.c

Modified: cfe/trunk/lib/Basic/Targets/RISCV.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets/RISCV.cpp?rev=366480&r1=366479&r2=366480&view=diff
==
--- cfe/trunk/lib/Basic/Targets/RISCV.cpp (original)
+++ cfe/trunk/lib/Basic/Targets/RISCV.cpp Thu Jul 18 11:29:59 2019
@@ -65,9 +65,18 @@ void RISCVTargetInfo::getTargetDefines(c
   Builder.defineMacro("__riscv");
   bool Is64Bit = getTriple().getArch() == llvm::Triple::riscv64;
   Builder.defineMacro("__riscv_xlen", Is64Bit ? "64" : "32");
-  // TODO: modify when more code models and ABIs are supported.
+  // TODO: modify when more code models are supported.
   Builder.defineMacro("__riscv_cmodel_medlow");
-  Builder.defineMacro("__riscv_float_abi_soft");
+
+  StringRef ABIName = getABI();
+  if (ABIName == "ilp32f" || ABIName == "lp64f")
+Builder.defineMacro("__riscv_float_abi_single");
+  else if (ABIName == "ilp32d" || ABIName == "lp64d")
+Builder.defineMacro("__riscv_float_abi_double");
+  else if (ABIName == "ilp32e")
+Builder.defineMacro("__riscv_abi_rve");
+  else
+Builder.defineMacro("__riscv_float_abi_soft");
 
   if (HasM) {
 Builder.defineMacro("__riscv_mul");

Modified: cfe/trunk/lib/Basic/Targets/RISCV.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets/RISCV.h?rev=366480&r1=366479&r2=366480&view=diff
==
--- cfe/trunk/lib/Basic/Targets/RISCV.h (original)
+++ cfe/trunk/lib/Basic/Targets/RISCV.h Thu Jul 18 11:29:59 2019
@@ -87,8 +87,7 @@ public:
   }
 
   bool setABI(const std::string &Name) override {
-// TODO: support ilp32f and ilp32d ABIs.
-if (Name == "ilp32") {
+if (Name == "ilp32" || Name == "ilp32f" || Name == "ilp32d") {
   ABI = Name;
   return true;
 }
@@ -105,8 +104,7 @@ public:
   }
 
   bool setABI(const std::string &Name) override {
-// TODO: support lp64f and lp64d ABIs.
-if (Name == "lp64") {
+if (Name == "lp64" || Name == "lp64f" || Name == "lp64d") {
   ABI = Name;
   return true;
 }

Modified: cfe/trunk/lib/CodeGen/TargetInfo.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/TargetInfo.cpp?rev=366480&r1=366479&r2=366480&view=diff
==
--- cfe/trunk/lib/CodeGen/TargetInfo.cpp (original)
+++ cfe/trunk/lib/CodeGen/TargetInfo.cpp Thu Jul 18 11:29:59 2019
@@ -9188,25 +9188,45 @@ static bool getTypeString(SmallStringEnc
 namespace {
 class RISCVABIInfo : public DefaultABIInfo {
 private:
-  unsigned XLen; // Size of the integer ('x') registers in bits.
+  // Size of the integer ('x') registers in bits.
+  unsigned XLen;
+  // Size of the floating point ('f') registers in bits. Note that the target
+  // ISA might have a wider FLen than the selected ABI (e.g. an RV32IF target
+  // with soft float ABI has FLen==0).
+  unsigned FLen;
   static const int NumArgGPRs = 8;
+  static const int NumArgFPRs = 8;
+  bool detectFPCCEli

r365305 - [RISCV] Specify registers used for exception handling

2019-07-08 Thread Alex Bradbury via cfe-commits
Author: asb
Date: Mon Jul  8 02:38:06 2019
New Revision: 365305

URL: http://llvm.org/viewvc/llvm-project?rev=365305&view=rev
Log:
[RISCV] Specify registers used for exception handling

Implements the handling of __builtin_eh_return_regno().

Differential Revision: https://reviews.llvm.org/D63417
Patch by Edward Jones.

Added:
cfe/trunk/test/CodeGen/builtins-riscv.c
Modified:
cfe/trunk/lib/Basic/Targets/RISCV.h

Modified: cfe/trunk/lib/Basic/Targets/RISCV.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets/RISCV.h?rev=365305&r1=365304&r2=365305&view=diff
==
--- cfe/trunk/lib/Basic/Targets/RISCV.h (original)
+++ cfe/trunk/lib/Basic/Targets/RISCV.h Mon Jul  8 02:38:06 2019
@@ -57,6 +57,15 @@ public:
 
   ArrayRef getGCCRegNames() const override;
 
+  int getEHDataRegisterNumber(unsigned RegNo) const override {
+if (RegNo == 0)
+  return 10;
+else if (RegNo == 1)
+  return 11;
+else
+  return -1;
+  }
+
   ArrayRef getGCCRegAliases() const override;
 
   bool validateAsmConstraint(const char *&Name,

Added: cfe/trunk/test/CodeGen/builtins-riscv.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/builtins-riscv.c?rev=365305&view=auto
==
--- cfe/trunk/test/CodeGen/builtins-riscv.c (added)
+++ cfe/trunk/test/CodeGen/builtins-riscv.c Mon Jul  8 02:38:06 2019
@@ -0,0 +1,10 @@
+// RUN: %clang_cc1 -Wall -Werror -triple riscv32 -disable-O0-optnone 
-emit-llvm -o - %s | opt -S -mem2reg | FileCheck %s
+// RUN: %clang_cc1 -Wall -Werror -triple riscv64 -disable-O0-optnone 
-emit-llvm -o - %s | opt -S -mem2reg | FileCheck %s
+
+void test_eh_return_data_regno() {
+  // CHECK: store volatile i32 10
+  // CHECK: store volatile i32 11
+  volatile int res;
+  res = __builtin_eh_return_data_regno(0);
+  res = __builtin_eh_return_data_regno(1);
+}


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


r365329 - [RISCV][NFC] Make use of Triple::isRISCV

2019-07-08 Thread Alex Bradbury via cfe-commits
Author: asb
Date: Mon Jul  8 08:07:12 2019
New Revision: 365329

URL: http://llvm.org/viewvc/llvm-project?rev=365329&view=rev
Log:
[RISCV][NFC] Make use of Triple::isRISCV

Use new helper introduced in rL365327.

Modified:
cfe/trunk/lib/Driver/ToolChains/Gnu.cpp
cfe/trunk/lib/Driver/ToolChains/Linux.cpp

Modified: cfe/trunk/lib/Driver/ToolChains/Gnu.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Gnu.cpp?rev=365329&r1=365328&r2=365329&view=diff
==
--- cfe/trunk/lib/Driver/ToolChains/Gnu.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains/Gnu.cpp Mon Jul  8 08:07:12 2019
@@ -933,10 +933,6 @@ static bool isMicroMips(const ArgList &A
   return A && A->getOption().matches(options::OPT_mmicromips);
 }
 
-static bool isRISCV(llvm::Triple::ArchType Arch) {
-  return Arch == llvm::Triple::riscv32 || Arch == llvm::Triple::riscv64;
-}
-
 static bool isMSP430(llvm::Triple::ArchType Arch) {
   return Arch == llvm::Triple::msp430;
 }
@@ -2312,7 +2308,7 @@ bool Generic_GCC::GCCInstallationDetecto
   } else if (TargetTriple.isMIPS()) {
 if (!findMIPSMultilibs(D, TargetTriple, Path, Args, Detected))
   return false;
-  } else if (isRISCV(TargetArch)) {
+  } else if (TargetTriple.isRISCV()) {
 findRISCVMultilibs(D, TargetTriple, Path, Args, Detected);
   } else if (isMSP430(TargetArch)) {
 findMSP430Multilibs(D, TargetTriple, Path, Args, Detected);

Modified: cfe/trunk/lib/Driver/ToolChains/Linux.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Linux.cpp?rev=365329&r1=365328&r2=365329&view=diff
==
--- cfe/trunk/lib/Driver/ToolChains/Linux.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains/Linux.cpp Mon Jul  8 08:07:12 2019
@@ -276,8 +276,7 @@ Linux::Linux(const Driver &D, const llvm
   const bool IsAndroid = Triple.isAndroid();
   const bool IsMips = Triple.isMIPS();
   const bool IsHexagon = Arch == llvm::Triple::hexagon;
-  const bool IsRISCV =
-  Arch == llvm::Triple::riscv32 || Arch == llvm::Triple::riscv64;
+  const bool IsRISCV = Triple.isRISCV();
 
   if (IsMips && !SysRoot.empty())
 ExtraOpts.push_back("--sysroot=" + SysRoot);


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


r348929 - [clang-fuzzer] Add explicit dependency on clangSerialization for clangHandleCXX after rC348907

2018-12-12 Thread Alex Bradbury via cfe-commits
Author: asb
Date: Wed Dec 12 06:33:24 2018
New Revision: 348929

URL: http://llvm.org/viewvc/llvm-project?rev=348929&view=rev
Log:
[clang-fuzzer] Add explicit dependency on clangSerialization for clangHandleCXX 
after rC348907

This library was breaking my -DBUILD_SHARED_LIBS=1 build. rC348915 seemed to 
miss this case.

As this seems an "obvious" fix, I am committing without pre-commit review as
per the LLVM developer policy.


Modified:
cfe/trunk/tools/clang-fuzzer/handle-cxx/CMakeLists.txt

Modified: cfe/trunk/tools/clang-fuzzer/handle-cxx/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/clang-fuzzer/handle-cxx/CMakeLists.txt?rev=348929&r1=348928&r2=348929&view=diff
==
--- cfe/trunk/tools/clang-fuzzer/handle-cxx/CMakeLists.txt (original)
+++ cfe/trunk/tools/clang-fuzzer/handle-cxx/CMakeLists.txt Wed Dec 12 06:33:24 
2018
@@ -8,5 +8,6 @@ add_clang_library(clangHandleCXX
   clangCodeGen
   clangFrontend
   clangLex
+  clangSerialization
   clangTooling
   )


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: r348915 - Add explicit dependency on clangSerialization for a bunch of components to fix -DBUILD_SHARED_LIBS=on build

2018-12-12 Thread Alex Bradbury via cfe-commits
On Wed, 12 Dec 2018 at 08:05, Fangrui Song via cfe-commits
 wrote:
>
> Author: maskray
> Date: Wed Dec 12 00:02:18 2018
> New Revision: 348915
>
> URL: http://llvm.org/viewvc/llvm-project?rev=348915&view=rev
> Log:
> Add explicit dependency on clangSerialization for a bunch of components to 
> fix -DBUILD_SHARED_LIBS=on build
>
> This is a more thorough fix of rC348911.
> The story about -DBUILD_SHARED_LIBS=on build after rC348907 (Move 
> PCHContainerOperations from Frontend to Serialization) is:
>
> 1. libclangSerialization.so defines PCHContainerReader dtor, ...
> 2. clangFrontend and clangTooling define classes inheriting from 
> PCHContainerReader, thus their DSOs have undefined references on 
> PCHContainerReader dtor
> 3. Components depending on either clangFrontend or clangTooling cannot be 
> linked unless they have explicit dependency on clangSerialization due to the 
> default linker option -z defs. The explicit dependency could be avoided if 
> libclang{Frontend,Tooling}.so had these undefined references.
>
> This patch adds the explicit dependency on clangSerialization to make them 
> build.

Hi Fangrui. My shared library build ran into issues when linking
libclangHandleCXX.so. I committed rC348929 to fix that.

Best,

Alex
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 3dcfd48 - [CodeGen] Increase applicability of ffine-grained-bitfield-accesses for targets with limited native integer widths

2020-06-12 Thread Alex Bradbury via cfe-commits

Author: Alex Bradbury
Date: 2020-06-12T10:33:47+01:00
New Revision: 3dcfd482cb17fad2d641c976b822d1fe36dc1359

URL: 
https://github.com/llvm/llvm-project/commit/3dcfd482cb17fad2d641c976b822d1fe36dc1359
DIFF: 
https://github.com/llvm/llvm-project/commit/3dcfd482cb17fad2d641c976b822d1fe36dc1359.diff

LOG: [CodeGen] Increase applicability of ffine-grained-bitfield-accesses for 
targets with limited native integer widths

As pointed out in PR45708, -ffine-grained-bitfield-accesses doesn't
trigger in all cases you think it might for RISC-V. The logic in
CGRecordLowering::accumulateBitFields checks OffsetInRecord is a legal
integer according to the datalayout. RISC targets will typically only
have the native width as a legal integer type so this check will fail
for OffsetInRecord of 8 or 16 when you would expect the transformation
is still worthwhile.

This patch changes the logic to check for an OffsetInRecord of a at
least 1 byte, that fits in a legal integer, and is a power of 2. We
would prefer to query whether native load/store operations are
available, but I don't believe that is possible.

Differential Revision: https://reviews.llvm.org/D79155

Added: 


Modified: 
clang/lib/CodeGen/CGRecordLayoutBuilder.cpp
clang/test/CodeGenCXX/finegrain-bitfield-type.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/CGRecordLayoutBuilder.cpp 
b/clang/lib/CodeGen/CGRecordLayoutBuilder.cpp
index c9a1b1d4fd14..4e5d1d3f16f6 100644
--- a/clang/lib/CodeGen/CGRecordLayoutBuilder.cpp
+++ b/clang/lib/CodeGen/CGRecordLayoutBuilder.cpp
@@ -406,15 +406,17 @@ 
CGRecordLowering::accumulateBitFields(RecordDecl::field_iterator Field,
 return;
   }
 
-  // Check if OffsetInRecord is better as a single field run. When 
OffsetInRecord
-  // has legal integer width, and its bitfield offset is naturally aligned, it
-  // is better to make the bitfield a separate storage component so as it can 
be
-  // accessed directly with lower cost.
+  // Check if OffsetInRecord (the size in bits of the current run) is better
+  // as a single field run. When OffsetInRecord has legal integer width, and
+  // its bitfield offset is naturally aligned, it is better to make the
+  // bitfield a separate storage component so as it can be accessed directly
+  // with lower cost.
   auto IsBetterAsSingleFieldRun = [&](uint64_t OffsetInRecord,
   uint64_t StartBitOffset) {
 if (!Types.getCodeGenOpts().FineGrainedBitfieldAccesses)
   return false;
-if (!DataLayout.isLegalInteger(OffsetInRecord))
+if (OffsetInRecord < 8 || !llvm::isPowerOf2_64(OffsetInRecord) ||
+!DataLayout.fitsInLegalInteger(OffsetInRecord))
   return false;
 // Make sure StartBitOffset is natually aligned if it is treated as an
 // IType integer.

diff  --git a/clang/test/CodeGenCXX/finegrain-bitfield-type.cpp 
b/clang/test/CodeGenCXX/finegrain-bitfield-type.cpp
index ff02d46de5e4..2106a6d3e0a9 100644
--- a/clang/test/CodeGenCXX/finegrain-bitfield-type.cpp
+++ b/clang/test/CodeGenCXX/finegrain-bitfield-type.cpp
@@ -1,5 +1,12 @@
 // RUN: %clang_cc1 -triple x86_64-linux-gnu -ffine-grained-bitfield-accesses \
 // RUN:   -emit-llvm -o - %s | FileCheck %s
+// RUN: %clang_cc1 -triple riscv64-linux-gnu -ffine-grained-bitfield-accesses \
+// RUN:   -emit-llvm -o - %s | FileCheck %s
+
+// Note: This test checks the X86-64 and RISC-V targets in order to explore
+// behaviour when i8/i16 are native integer widths (X86-64) and when they're
+// not (RISC-V).
+
 struct S4 {
   unsigned long f1:28;
   unsigned long f2:4;
@@ -19,4 +26,4 @@ struct S5 a5;
 // CHECK: %struct.S4 = type { i32, i16 }
 // CHECK-NOT: %struct.S4 = type { i48 }
 // CHECK: %struct.S5 = type { i32, i32, i16, [6 x i8] }
-// CHECK-NOT: %struct.S5 = type { i80 }
\ No newline at end of file
+// CHECK-NOT: %struct.S5 = type { i80 }



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: [llvm-dev] Upgrading phabricator

2016-09-30 Thread Alex Bradbury via cfe-commits
On 30 September 2016 at 14:21, Eric Liu via llvm-commits
 wrote:
> Thanks for the feedback Aaron! :)
>
> I've disabled it. I think the annoying part really is the status (e.g.
> Request, Closed etc) in the tag, and I am wondering if a tag with just line
> numbers like "(N Loc)" would be better. But I'm not really sure about the
> trade-off here.

I'd suggest that [PATCH] is a waste of screen real estate too - the
`Dn:` prefix makes it obvious. I do appreciate there's an argument
for having it for consistency with people who post patches directly to
llvm-commits.

Alex
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[llvm] [clang] Remove experimental from Vector Crypto extensions (PR #69000)

2023-11-07 Thread Alex Bradbury via cfe-commits

asb wrote:

> Since it's possible that **ISA spec** and **intrinsics spec** are not 
> synchronized, so the updates add an dummy extension called **zexperimental**, 
> once `-menable-experimental-extensions` is specified, the feature 
> `zexperimental` is automatically added.
> If `let RequiredFeatures = ["Zexperimental"] ` is added in `.td` file, it 
> will check if `zexperimental` exists, if not, the corresponding intrinsics 
> would not be added, hence causing an **intrinsics undeclared** error.

Thanks for looking into this. It's perhaps surprising we've gone so long 
without having the infrastructure to make an extension non-experimental without 
making its not-yet-finalized intrinsics non-experimental. Introducing a new 
required feature seems like a reasonable way of doing this, but introducing a 
dummy extension seems unnecessary (unless I'm missing something?).

I could see a solution involving a Clang flag (e.g. 
`-menable-experimental-intrinsics`), or perhaps a solution where the user must 
use a certain `#define` (I know riscv_vector.h is implemented using a pragma, 
but presumably that could still query defines). There may be other options too.

Another piece of info that would be helpful to better understand is what the 
process is for finalising intrinsic additions (@eopxd might know?). If it's 
just the case that we have to wait another month before moving an extension 
from experimental to experimental then maybe extra infro to separate 
experimental intrinsics from instructions is less interesting. If it's more 
indeterminate than that, we probably need it.

I'll put this on the agenda for Thursday's RISC-V LLVM sync-up call in the hope 
we can resolve it there.

https://github.com/llvm/llvm-project/pull/69000
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [llvm] [RISCV] Add processor definition for XiangShan-NanHu (PR #70294)

2023-11-07 Thread Alex Bradbury via cfe-commits

https://github.com/asb approved this pull request.

I think everyone is happy, so please go ahead and squash+merge. Thanks!

https://github.com/llvm/llvm-project/pull/70294
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang] Enable --gcc-install-dir for RISCV baremetal toolchains (PR #71803)

2023-11-09 Thread Alex Bradbury via cfe-commits

asb wrote:

Tagging @MaskRay for a quick check of this too, if he has time.

https://github.com/llvm/llvm-project/pull/71803
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[llvm] [clang] [clang][RISCV] Change default abi with f extension but without d extension (PR #73489)

2023-12-07 Thread Alex Bradbury via cfe-commits

asb wrote:

This is a user-facing change that definitely needs to be acknowledged in the 
release notes (clang/docs/ReleaseNotes.rst)

I agree with you that it seems more intuitive that a -march=rv32imaf invocation 
should default to ilp32f just as -march=rv32imafd defaults to ilp32d. I 
slightly disagree that this patch aligns us to GCC, because as I understood 
Kito's comment the GCC behaviour is really depending on what default ABI the 
toolchain was configured with. For a toolchain that defaults to ilp32d, 
presumably -march=rv32imaf still ends up with ilp32?

That said, with the GCC cross-compilation model being so different to clang I 
don't think we necessarily need to match precisely, so I'm not opposed to a 
more intuitive default.

https://github.com/llvm/llvm-project/pull/73489
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[llvm] [clang] [RISCV] Remove experimental from Vector Crypto extensions (PR #74213)

2023-12-07 Thread Alex Bradbury via cfe-commits

asb wrote:

I failed to report back in the other review thread about the discussion at the 
previous RISC-V LLVM sync-up call. I think it's a fair summary to say we 
concluded was that gating the intrinsics on a flag was a good idea (though not 
a strict requirement if it was going to slow things down too much), and that we 
probably shouldn't agonise over the precise form this flag takes. What you 
propose here seems OK to me, but please add something to RISCVUsage indicating 
that in some cases an extension may be non-experimental but the intrinsics 
still experimental and `-menable-experimental-extensions` must be passed to 
Clang to use them. I also think a Clang release note might make sense, such as 
"It is now possible for intrinsics to be experimental while the extension 
itself is non-experimental. This is currently the case for the vector crypto 
extensions (Zvk*, Zvbb, Zvbc) where `-menable-experimental-extension` must 
still be passed to Clang in order to enable use of the C intrinsics."

https://github.com/llvm/llvm-project/pull/74213
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [llvm] [clang][RISCV] Change default abi with f extension but without d extension (PR #73489)

2023-12-07 Thread Alex Bradbury via cfe-commits

asb wrote:

I think the conclusion from the LLVM sync-up call was that everyone happy to 
move in this direction, so please add the release note and we can do a final 
review. Thanks!

https://github.com/llvm/llvm-project/pull/73489
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [llvm] [clang][RISCV] Change default abi with f extension but without d extension (PR #73489)

2023-12-08 Thread Alex Bradbury via cfe-commits

asb wrote:

> > I think the conclusion from the LLVM sync-up call was that everyone happy 
> > to move in this direction, so please add the release note and we can do a 
> > final review. Thanks!
> 
> Done, added release note.

Thanks! Sorry I wasn't specific about this, but we need a Clang release note as 
well.

https://github.com/llvm/llvm-project/pull/73489
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [llvm] [clang][RISCV] Change default abi with f extension but without d extension (PR #73489)

2023-12-13 Thread Alex Bradbury via cfe-commits

https://github.com/asb approved this pull request.

LGTM

https://github.com/llvm/llvm-project/pull/73489
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [llvm] [RISCV] Remove experimental from Vector Crypto extensions (PR #74213)

2023-12-13 Thread Alex Bradbury via cfe-commits

https://github.com/asb approved this pull request.

I was sure I LGTMed this earlier today, but it seems I didn't...

https://github.com/llvm/llvm-project/pull/74213
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [RISCV] Minor improvements/cleanup to target attribute handling. NFC (PR #73851)

2023-11-29 Thread Alex Bradbury via cfe-commits

https://github.com/asb approved this pull request.

LGTM.

https://github.com/llvm/llvm-project/pull/73851
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[llvm] [clang] [RISCV] CodeGen of RVE and ilp32e/lp64e ABIs (PR #76777)

2024-01-04 Thread Alex Bradbury via cfe-commits

asb wrote:

The conclusion from the previous review was this was OK to merge. I think I 
held it up by not responding to a ping (apologies). I've had another scan 
through and don't see a problem with merging this and considering it 
experimental once Craig's review comments are addressed.

For the psABI, there's a gap here I think as GCC and LLVM need to deviate from 
what is currently written. I think 
https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/257 tried to 
partially address this. I wonder if we need a tracking issue in that repo to 
try to get this properly documented via that PR or otherwise (what do you think 
@jrtc27 @kito-cheng?).

https://github.com/llvm/llvm-project/pull/76777
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [llvm] [RISCV] Add B extension (PR #76893)

2024-01-04 Thread Alex Bradbury via cfe-commits

asb wrote:

Thanks!

If someone sets zba_zbb_zbs, should b be inferred?

This patch needs an LLVM release note as well, and agreed we should await on a 
versioning decision.

https://github.com/llvm/llvm-project/pull/76893
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[llvm] [clang] [RISCV] CodeGen of RVE and ilp32e/lp64e ABIs (PR #76777)

2024-01-04 Thread Alex Bradbury via cfe-commits

asb wrote:

@nemanjai I'm curious if you have an interest / need to support RVE or not?

https://github.com/llvm/llvm-project/pull/76777
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[llvm] [clang] [RISCV] CodeGen of RVE and ilp32e/lp64e ABIs (PR #76777)

2024-01-04 Thread Alex Bradbury via cfe-commits


@@ -179,6 +180,11 @@ Assembly Support
 Supported
   Fully supported by the compiler.  This includes everything in Assembly 
Support, along with - if relevant - C language intrinsics for the instructions 
and pattern matching by the compiler to recognize idiomatic patterns which can 
be lowered to the associated instructions.
 
+.. _riscv-rve-note:
+
+``E``
+  Support of RV32E/RV64E and ilp32e/lp64e ABIs are experimental.

asb wrote:

Maybe this would be a good place to add "To be compatible with the 
implementation of ilp32e in GCC, we don't use aligned registers to pass 
variadic arguments and set stack alignment to 4-bytes for types with length of 
2*XLEN."

Given this gap in the ABI, it would be good if we could document it somewhere 
outside of the commit message.

https://github.com/llvm/llvm-project/pull/76777
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[lldb] [mlir] [polly] [lld] [libcxx] [flang] [llvm] [clang] [compiler-rt] [openmp] [libc] [WebAssembly] Correctly consider signext/zext arg flags at function declaration (PR #77281)

2024-01-09 Thread Alex Bradbury via cfe-commits

asb wrote:

In case anyone was wondering how this is handled in SelectionDAG, I believe 
it's covered by CallLoweringInfo ultimately determining if an arg is sext/zext 
through CallBase::paramHasAttr, which does indeed check both the callsite and 
the called function (if it's a direct call of course). Indeed, I think you 
could just switch to using paramHasAttr in this patch and get the desired 
behaviour (which seems to be what ARMFastISel does in its `SelectCall` 
implementation).

Although this does fix a real bug, I'd strongly advise that a bug be filed 
against whatever code generated produced a call lacking the matching 
signext/zeroext attribute as the caller. I don't believe that in general LLVM 
is particularly well tested or robust against such inconsistencies, so it's 
likely to run into bugs.

https://github.com/llvm/llvm-project/pull/77281
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [llvm] [RISCV] CodeGen of RVE and ilp32e/lp64e ABIs (PR #76777)

2024-01-09 Thread Alex Bradbury via cfe-commits

asb wrote:

The RISCVUsage change looks good to me, and it's fantastic that @nemanjai might 
be able to help push this forward further.

I think all the review comments were addressed, so I'd be happy to merge if 
@topperc is happy his comments were resolved. Though also fine to wait longer 
if @nemanjai you wanted to review this as well.

https://github.com/llvm/llvm-project/pull/76777
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [llvm] [Clang][RISCV] Move getVScaleRange logic into libLLVMFrontendDriver. NFC (PR #77327)

2024-01-09 Thread Alex Bradbury via cfe-commits

asb wrote:

libLLVMFrontendDriver intuitively seems like a sensible home, though I think 
we'd be the first to use it in this way. I'm wondering if you considered moving 
the helper function into RISCVISAInfo? I'm not sure it's _better_ but it 
doesn't seem like a terrible place for this logic.

https://github.com/llvm/llvm-project/pull/77327
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [llvm] [RISCV] Add support for new unprivileged extensions defined in profiles spec (PR #77458)

2024-01-10 Thread Alex Bradbury via cfe-commits

https://github.com/asb approved this pull request.

LGTM, but please add a release note too.

https://github.com/llvm/llvm-project/pull/77458
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 4f40ca5 - [RISCV] Implement support for the Zicbom and Zicboz extensions

2022-06-28 Thread Alex Bradbury via cfe-commits

Author: Alex Bradbury
Date: 2022-06-28T12:43:25+01:00
New Revision: 4f40ca53cefb725aca6564585d0ec4836a79e21a

URL: 
https://github.com/llvm/llvm-project/commit/4f40ca53cefb725aca6564585d0ec4836a79e21a
DIFF: 
https://github.com/llvm/llvm-project/commit/4f40ca53cefb725aca6564585d0ec4836a79e21a.diff

LOG: [RISCV] Implement support for the Zicbom and Zicboz extensions

Implements the ratified RISC-V Base Cache Management Operation ISA
Extensions: Zicbom and Zicboz, as described in
https://github.com/riscv/riscv-CMOs/blob/master/specifications/cmobase-v1.0.pdf.

Zicbop is implemented in a separate patch due to it requiring a new ASM
operand type to be defined.

As discussed in the relevant issue in the upstream spec
https://github.com/riscv/riscv-CMOs/issues/47, the cbo.* instructions
use the format (rs1) or 0(rs1) for their operand, similar to the AMOs.

Differential Revision: https://reviews.llvm.org/D117432

Added: 
llvm/lib/Target/RISCV/RISCVInstrInfoZicbo.td
llvm/test/MC/RISCV/rv32zicbom-invalid.s
llvm/test/MC/RISCV/rv32zicbom-valid.s
llvm/test/MC/RISCV/rv32zicboz-invalid.s
llvm/test/MC/RISCV/rv32zicboz-valid.s

Modified: 
clang/test/Preprocessor/riscv-target-features.c
llvm/lib/Support/RISCVISAInfo.cpp
llvm/lib/Target/RISCV/RISCV.td
llvm/lib/Target/RISCV/RISCVInstrInfo.td
llvm/lib/Target/RISCV/RISCVSubtarget.h
llvm/test/CodeGen/RISCV/attributes.ll
llvm/test/MC/RISCV/attribute-arch.s

Removed: 




diff  --git a/clang/test/Preprocessor/riscv-target-features.c 
b/clang/test/Preprocessor/riscv-target-features.c
index edd66fb0cc4b9..02af5d8d6b21e 100644
--- a/clang/test/Preprocessor/riscv-target-features.c
+++ b/clang/test/Preprocessor/riscv-target-features.c
@@ -42,6 +42,8 @@
 // CHECK-NOT: __riscv_zkr
 // CHECK-NOT: __riscv_zkt
 // CHECK-NOT: __riscv_zk
+// CHECK-NOT: __riscv_zicbom
+// CHECK-NOT: __riscv_zicboz
 
 // RUN: %clang -target riscv32-unknown-linux-gnu -march=rv32im -x c -E -dM %s \
 // RUN: -o - | FileCheck --check-prefix=CHECK-M-EXT %s
@@ -433,3 +435,15 @@
 // RUN: -march=rv64i_zbkb_zbkc_zbkx_zksed_zksh -x c -E -dM %s -o - \
 // RUN: | FileCheck --check-prefix=CHECK-COMBINE-INTO-ZKS %s
 // CHECK-COMBINE-INTO-ZKS: __riscv_zks 1
+
+// RUN: %clang -target riscv32 -march=rv32izicbom -x c -E -dM %s \
+// RUN: -o - | FileCheck --check-prefix=CHECK-ZICBOM-EXT %s
+// RUN: %clang -target riscv64 -march=rv64izicbom -x c -E -dM %s \
+// RUN: -o - | FileCheck --check-prefix=CHECK-ZICBOM-EXT %s
+// CHECK-ZICBOM-EXT: __riscv_zicbom 100{{$}}
+
+// RUN: %clang -target riscv32 -march=rv32izicboz -x c -E -dM %s \
+// RUN: -o - | FileCheck --check-prefix=CHECK-ZICBOZ-EXT %s
+// RUN: %clang -target riscv64 -march=rv64izicboz -x c -E -dM %s \
+// RUN: -o - | FileCheck --check-prefix=CHECK-ZICBOZ-EXT %s
+// CHECK-ZICBOZ-EXT: __riscv_zicboz 100{{$}}

diff  --git a/llvm/lib/Support/RISCVISAInfo.cpp 
b/llvm/lib/Support/RISCVISAInfo.cpp
index 1057dbae13da9..9ff5fbe10bb4c 100644
--- a/llvm/lib/Support/RISCVISAInfo.cpp
+++ b/llvm/lib/Support/RISCVISAInfo.cpp
@@ -95,6 +95,9 @@ static const RISCVSupportedExtension SupportedExtensions[] = {
 {"zve64x", RISCVExtensionVersion{1, 0}},
 {"zve64f", RISCVExtensionVersion{1, 0}},
 {"zve64d", RISCVExtensionVersion{1, 0}},
+
+{"zicbom", RISCVExtensionVersion{1, 0}},
+{"zicboz", RISCVExtensionVersion{1, 0}},
 };
 
 static const RISCVSupportedExtension SupportedExperimentalExtensions[] = {

diff  --git a/llvm/lib/Target/RISCV/RISCV.td b/llvm/lib/Target/RISCV/RISCV.td
index 657f89ca18411..9b36598116a11 100644
--- a/llvm/lib/Target/RISCV/RISCV.td
+++ b/llvm/lib/Target/RISCV/RISCV.td
@@ -400,6 +400,20 @@ def FeatureStdExtZvfh
"'Zvfh' (Vector Half-Precision Floating-Point)",
[FeatureStdExtZve32f]>;
 
+def FeatureStdExtZicbom
+: SubtargetFeature<"zicbom", "HasStdExtZicbom", "true",
+   "'Zicbom' (Cache-Block Management Instructions)">;
+def HasStdExtZicbom : Predicate<"Subtarget->hasStdExtZicbom()">,
+AssemblerPredicate<(all_of 
FeatureStdExtZicbom),
+"'Zicbom' (Cache-Block Management 
Instructions)">;
+
+def FeatureStdExtZicboz
+: SubtargetFeature<"zicboz", "HasStdExtZicboz", "true",
+   "'Zicboz' (Cache-Block Zero Instructions)">;
+def HasStdExtZicboz : Predicate<"Subtarget->hasStdExtZicboz()">,
+AssemblerPredicate<(all_of 
FeatureStdExtZicboz),
+"'Zicboz' (Cache-Block Zero Instructions)">;
+
 def Feature64Bit
 : SubtargetFeature<"64bit", "HasRV64", "true", "Implements RV64">;
 def IsRV64 : Predicate<"Subtarget->is64Bit()">,

diff  --git a/llvm/lib/Target/RISCV/RISCVInstrInfo.td 
b/llvm/lib/Target/RISCV/RISCVInstrInfo.td
index 7e907a6f91a2d..ee4c026af8f43 100644
--- a/llvm/lib/Target/RISCV/RISCVInstrInfo.td

[clang] 7bcfcab - [RISCV] Implement support for the Zicbop extension

2022-06-28 Thread Alex Bradbury via cfe-commits

Author: Alex Bradbury
Date: 2022-06-28T12:43:26+01:00
New Revision: 7bcfcabbd14e9cd51d150a36aee9edf4f4231724

URL: 
https://github.com/llvm/llvm-project/commit/7bcfcabbd14e9cd51d150a36aee9edf4f4231724
DIFF: 
https://github.com/llvm/llvm-project/commit/7bcfcabbd14e9cd51d150a36aee9edf4f4231724.diff

LOG: [RISCV] Implement support for the Zicbop extension

Implements the ratified RISC-V Base Cache Management Operation ISA
Extension: Zicbop, as described in
https://github.com/riscv/riscv-CMOs/blob/master/specifications/cmobase-v1.0.pdf.

This is implemented in a separate patch to Zicbom and Zicboz due to it
requiring a new ASM operand type to be defined.

Differential Revision: https://reviews.llvm.org/D117433

Added: 
llvm/test/MC/RISCV/rv32zicbop-invalid.s
llvm/test/MC/RISCV/rv32zicbop-valid.s

Modified: 
clang/test/Preprocessor/riscv-target-features.c
llvm/lib/Support/RISCVISAInfo.cpp
llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
llvm/lib/Target/RISCV/MCTargetDesc/RISCVBaseInfo.h
llvm/lib/Target/RISCV/RISCV.td
llvm/lib/Target/RISCV/RISCVInstrInfo.cpp
llvm/lib/Target/RISCV/RISCVInstrInfoZicbo.td
llvm/lib/Target/RISCV/RISCVSubtarget.h
llvm/test/CodeGen/RISCV/attributes.ll
llvm/test/MC/RISCV/attribute-arch.s
llvm/test/MC/RISCV/rv32zicbom-invalid.s
llvm/test/MC/RISCV/rv32zicboz-invalid.s

Removed: 




diff  --git a/clang/test/Preprocessor/riscv-target-features.c 
b/clang/test/Preprocessor/riscv-target-features.c
index 02af5d8d6b21e..38cef26cdc845 100644
--- a/clang/test/Preprocessor/riscv-target-features.c
+++ b/clang/test/Preprocessor/riscv-target-features.c
@@ -447,3 +447,9 @@
 // RUN: %clang -target riscv64 -march=rv64izicboz -x c -E -dM %s \
 // RUN: -o - | FileCheck --check-prefix=CHECK-ZICBOZ-EXT %s
 // CHECK-ZICBOZ-EXT: __riscv_zicboz 100{{$}}
+
+// RUN: %clang -target riscv32 -march=rv32izicbop -x c -E -dM %s \
+// RUN: -o - | FileCheck --check-prefix=CHECK-ZICBOP-EXT %s
+// RUN: %clang -target riscv64 -march=rv64izicbop -x c -E -dM %s \
+// RUN: -o - | FileCheck --check-prefix=CHECK-ZICBOP-EXT %s
+// CHECK-ZICBOP-EXT: __riscv_zicbop 100{{$}}

diff  --git a/llvm/lib/Support/RISCVISAInfo.cpp 
b/llvm/lib/Support/RISCVISAInfo.cpp
index 9ff5fbe10bb4c..7fe04af4696b8 100644
--- a/llvm/lib/Support/RISCVISAInfo.cpp
+++ b/llvm/lib/Support/RISCVISAInfo.cpp
@@ -98,6 +98,7 @@ static const RISCVSupportedExtension SupportedExtensions[] = {
 
 {"zicbom", RISCVExtensionVersion{1, 0}},
 {"zicboz", RISCVExtensionVersion{1, 0}},
+{"zicbop", RISCVExtensionVersion{1, 0}},
 };
 
 static const RISCVSupportedExtension SupportedExperimentalExtensions[] = {

diff  --git a/llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp 
b/llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
index 9c59c7bc57554..69fb9d2844d39 100644
--- a/llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
+++ b/llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
@@ -689,6 +689,16 @@ struct RISCVOperand : public MCParsedAsmOperand {
 
   bool isSImm12Lsb0() const { return isBareSimmNLsb0<12>(); }
 
+  bool isSImm12Lsb0() const {
+if (!isImm())
+  return false;
+RISCVMCExpr::VariantKind VK = RISCVMCExpr::VK_RISCV_None;
+int64_t Imm;
+bool IsConstantImm = evaluateConstantImm(getImm(), Imm, VK);
+return IsConstantImm && isShiftedInt<7, 5>(Imm) &&
+   VK == RISCVMCExpr::VK_RISCV_None;
+  }
+
   bool isSImm13Lsb0() const { return isBareSimmNLsb0<13>(); }
 
   bool isSImm10LsbNonZero() const {
@@ -1198,6 +1208,10 @@ bool RISCVAsmParser::MatchAndEmitInstruction(SMLoc 
IDLoc, unsigned &Opcode,
 return generateImmOutOfRangeError(
 Operands, ErrorInfo, -(1 << 11), (1 << 11) - 2,
 "immediate must be a multiple of 2 bytes in the range");
+  case Match_InvalidSImm12Lsb0:
+return generateImmOutOfRangeError(
+Operands, ErrorInfo, -(1 << 11), (1 << 11) - 32,
+"immediate must be a multiple of 32 bytes in the range");
   case Match_InvalidSImm13Lsb0:
 return generateImmOutOfRangeError(
 Operands, ErrorInfo, -(1 << 12), (1 << 12) - 2,

diff  --git a/llvm/lib/Target/RISCV/MCTargetDesc/RISCVBaseInfo.h 
b/llvm/lib/Target/RISCV/MCTargetDesc/RISCVBaseInfo.h
index b0b3dc4fe7df0..fa408f7fc5d7d 100644
--- a/llvm/lib/Target/RISCV/MCTargetDesc/RISCVBaseInfo.h
+++ b/llvm/lib/Target/RISCV/MCTargetDesc/RISCVBaseInfo.h
@@ -221,6 +221,7 @@ enum OperandType : unsigned {
   OPERAND_UIMM7,
   OPERAND_UIMM12,
   OPERAND_SIMM12,
+  OPERAND_SIMM12_LSB0,
   OPERAND_UIMM20,
   OPERAND_UIMMLOG2XLEN,
   OPERAND_RVKRNUM,

diff  --git a/llvm/lib/Target/RISCV/RISCV.td b/llvm/lib/Target/RISCV/RISCV.td
index 9b36598116a11..e783ef38b4484 100644
--- a/llvm/lib/Target/RISCV/RISCV.td
+++ b/llvm/lib/Target/RISCV/RISCV.td
@@ -414,6 +414,13 @@ def HasStdExtZicboz : 
Predicate<"Subtarget->hasStdExtZicboz()">,
 AssemblerPredica

[clang] bea5e88 - [clang][Sema] Fix typo in checkBuiltinArgument helper

2022-04-20 Thread Alex Bradbury via cfe-commits

Author: Alex Bradbury
Date: 2022-04-20T14:42:41+01:00
New Revision: bea5e88bcf5908b676da35fb8c64f9f8449ba73b

URL: 
https://github.com/llvm/llvm-project/commit/bea5e88bcf5908b676da35fb8c64f9f8449ba73b
DIFF: 
https://github.com/llvm/llvm-project/commit/bea5e88bcf5908b676da35fb8c64f9f8449ba73b.diff

LOG: [clang][Sema] Fix typo in checkBuiltinArgument helper

The checkBuiltinArgument helper takes an integer ArgIndex and is
documented as performing normal type-checking on that argument. However,
it mistakenly hardcodes the argument index to zero when retrieving the
argument from the call expression.

This hadn't been noticed previously as all in-tree uses typecheck the
0th argument anyway.

Added: 


Modified: 
clang/lib/Sema/SemaChecking.cpp

Removed: 




diff  --git a/clang/lib/Sema/SemaChecking.cpp b/clang/lib/Sema/SemaChecking.cpp
index cd069d5664571..f575c0775e7f9 100644
--- a/clang/lib/Sema/SemaChecking.cpp
+++ b/clang/lib/Sema/SemaChecking.cpp
@@ -6222,7 +6222,7 @@ static bool checkBuiltinArgument(Sema &S, CallExpr *E, 
unsigned ArgIndex) {
   InitializedEntity Entity =
 InitializedEntity::InitializeParameter(S.Context, Param);
 
-  ExprResult Arg = E->getArg(0);
+  ExprResult Arg = E->getArg(ArgIndex);
   Arg = S.PerformCopyInitialization(Entity, SourceLocation(), Arg);
   if (Arg.isInvalid())
 return true;



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [llvm] [RISCV] Add generic CPUs for profiles (PR #84877)

2024-03-14 Thread Alex Bradbury via cfe-commits

asb wrote:

> > I don't know if we need S-mode profile CPUs.
> 
> I lean towards not supporting them since the S extensions don't do anything 
> in the compiler except preprocessor defines and ELF attributes, but maybe we 
> should put it on the agenda for the sync meeting this week.

My initial feeling is it probably wouldn't hurt to have them, but it's not 
clear who would use them in practice. Build systems for userspace code 
presumably wouldn't do so, and I'd have thought kernels would typically want 
more control (as they wouldn't want the compiler to make use of floating point 
or vectors freely). But I could be wrong on that, so I'd love to hear from 
others with more experience on that. e.g. @petrhosek

https://github.com/llvm/llvm-project/pull/84877
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [llvm] [RISCV] Add generic CPUs for profiles (PR #84877)

2024-03-14 Thread Alex Bradbury via cfe-commits

asb wrote:

We discussed this on the sync-up call and @preames very rightly pointed out 
that we should take a step back here...from a user perspective, what does 
specifying a profile via `-mcpu` provide that specifying it via `-march` 
doesn't? We weren't able to answer that in the call, but perhaps we're missing 
something?

https://github.com/llvm/llvm-project/pull/84877
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [llvm] [RISC-V] Add CSR read/write builtins (PR #85091)

2024-03-14 Thread Alex Bradbury via cfe-commits

asb wrote:

> In my view, the builtin solution is superior from a usability perspective.

I agree, I think Sam's previous work on this stopped due to changing priorities 
not because there was any real pushback.

https://github.com/llvm/llvm-project/pull/85091
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [llvm] [RISCV] Add Ssqosid support to -march. (PR #80747)

2024-02-06 Thread Alex Bradbury via cfe-commits

https://github.com/asb approved this pull request.

LGTM.

https://github.com/llvm/llvm-project/pull/80747
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [RISCV] Add -march string as Module metadata in IR. (PR #80760)

2024-02-06 Thread Alex Bradbury via cfe-commits

asb wrote:

I agree that finding a generic cross-target solution to this problem is 
attractive...but I worry it will be hard and slow to proceed. It's possible the 
previous discussions just lacked someone following up with concrete patches, 
but I do worry we'd end up stuck in limbo vs starting with a target-specific 
approach that we later hope to replace with something more generic.

With that in mind:
* To what degree are we constrained by backwards compatibility once we commit 
to something like this? It's hard to imagine not being able to write an 
appropriate IR autoupgrade rule, but perhaps I'm missing something.
* Just to check my understanding, is the only usecase for this ISA naming 
string to produce appropriate ELF attributes?

Two simple and early pieces of feedback on the patch:
* Nitpick: We're not adding the -march string as module metadata, we're adding 
an ISA naming string in a normalized form.
* A comment in CodeGenModule or at least the test to briefly indicate _why_ 
this metadata is wanted would be helpful I think.

https://github.com/llvm/llvm-project/pull/80760
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [llvm] [RISCV] Graduate Zicond to non-experimental (PR #79811)

2024-01-29 Thread Alex Bradbury via cfe-commits

https://github.com/asb created https://github.com/llvm/llvm-project/pull/79811

The Zicond extension was ratified in the last few months, with no changes that 
affect the LLVM implementation. Although there's surely more tuning that could 
be done about when to select Zicond or not, there are no known correctness 
issues. Therefore, we should mark support as non-experimental.

>From cf5c3432f66b36db0b8283a967b24686433cdf63 Mon Sep 17 00:00:00 2001
From: Alex Bradbury 
Date: Sun, 28 Jan 2024 08:50:35 +
Subject: [PATCH] [RISCV] Graduate Zicond to non-experimental

The Zicond extension was ratified in the last few months, with no
changes that affect the LLVM implementation. Although there's surely
more tuning that could be done about when to select Zicond or not, there
are no known correctness issues. Therefore, we should mark support as
non-experimental.
---
 .../CodeGen/RISCV/riscv-func-attr-target.c|  2 +-
 .../test/Preprocessor/riscv-target-features.c | 18 
 llvm/docs/RISCVUsage.rst  |  4 +-
 llvm/docs/ReleaseNotes.rst|  2 +
 llvm/lib/Support/RISCVISAInfo.cpp |  3 +-
 llvm/lib/Target/RISCV/RISCVFeatures.td|  2 +-
 llvm/lib/Target/RISCV/RISCVInstrInfoZicond.td |  2 -
 llvm/test/CodeGen/RISCV/attributes.ll |  4 +-
 llvm/test/CodeGen/RISCV/cmov-branch-opt.ll|  4 +-
 llvm/test/CodeGen/RISCV/condbinops.ll |  4 +-
 llvm/test/CodeGen/RISCV/condops.ll|  4 +-
 .../CodeGen/RISCV/select-binop-identity.ll|  4 +-
 llvm/test/CodeGen/RISCV/select.ll |  4 +-
 .../CodeGen/RISCV/short-forward-branch-opt.ll |  2 +-
 llvm/test/CodeGen/RISCV/xaluo.ll  |  4 +-
 llvm/test/MC/RISCV/rv32zicond-invalid.s   |  4 +-
 llvm/test/MC/RISCV/rv32zicond-valid.s | 12 ++---
 llvm/unittests/Support/RISCVISAInfoTest.cpp   | 46 +--
 18 files changed, 61 insertions(+), 64 deletions(-)

diff --git a/clang/test/CodeGen/RISCV/riscv-func-attr-target.c 
b/clang/test/CodeGen/RISCV/riscv-func-attr-target.c
index 7d3362e84e75888..f216eaf735b4a85 100644
--- a/clang/test/CodeGen/RISCV/riscv-func-attr-target.c
+++ b/clang/test/CodeGen/RISCV/riscv-func-attr-target.c
@@ -39,7 +39,7 @@ __attribute__((target("cpu=sifive-u54"))) void 
testAttrCpuOnly() {}
 // CHECK: attributes #0 = { 
{{.*}}"target-features"="+64bit,+a,+m,+save-restore,+zifencei,-relax,-zbb,-zfa" 
}
 // CHECK: attributes #1 = { {{.*}}"target-cpu"="rocket-rv64" 
"target-features"="+64bit,+a,+d,+f,+m,+save-restore,+v,+zicsr,+zifencei,+zve32f,+zve32x,+zve64d,+zve64f,+zve64x,+zvl128b,+zvl32b,+zvl64b,-relax,-zbb,-zfa"
 "tune-cpu"="generic-rv64" }
 // CHECK: attributes #2 = { 
{{.*}}"target-features"="+64bit,+a,+m,+save-restore,+zbb,+zifencei,-relax,-zfa" 
}
-// CHECK: attributes #3 = { 
{{.*}}"target-features"="+64bit,+a,+d,+experimental-zicond,+f,+m,+save-restore,+v,+zbb,+zicsr,+zifencei,+zve32f,+zve32x,+zve64d,+zve64f,+zve64x,+zvl128b,+zvl32b,+zvl64b,-relax,-zfa"
 }
+// CHECK: attributes #3 = { 
{{.*}}"target-features"="+64bit,+a,+d,+f,+m,+save-restore,+v,+zbb,+zicond,+zicsr,+zifencei,+zve32f,+zve32x,+zve64d,+zve64f,+zve64x,+zvl128b,+zvl32b,+zvl64b,-relax,-zfa"
 }
 // Make sure we append negative features if we override the arch
 // CHECK: attributes #4 = { 
{{.*}}"target-features"="+64bit,+a,+c,+d,+f,+m,+save-restore,+zbb,+zicsr,+zifencei,{{(-[[:alnum:]-]+)(,-[[:alnum:]-]+)*}}"
 }
 // CHECK: attributes #5 = { 
{{.*}}"target-features"="+64bit,+m,+save-restore,{{(-[[:alnum:]-]+)(,-[[:alnum:]-]+)*}}"
 }
diff --git a/clang/test/Preprocessor/riscv-target-features.c 
b/clang/test/Preprocessor/riscv-target-features.c
index 8f50126f1b36285..2361c83a5a6102d 100644
--- a/clang/test/Preprocessor/riscv-target-features.c
+++ b/clang/test/Preprocessor/riscv-target-features.c
@@ -88,6 +88,7 @@
 // CHECK-NOT: __riscv_zicclsm {{.*$}}
 // CHECK-NOT: __riscv_ziccrse {{.*$}}
 // CHECK-NOT: __riscv_zicntr {{.*$}}
+// CHECK-NOT: __riscv_zicond {{.*$}}
 // CHECK-NOT: __riscv_zicsr {{.*$}}
 // CHECK-NOT: __riscv_zifencei {{.*$}}
 // CHECK-NOT: __riscv_zihintntl {{.*$}}
@@ -148,7 +149,6 @@
 // CHECK-NOT: __riscv_zfbfmin {{.*$}}
 // CHECK-NOT: __riscv_zicfilp {{.*$}}
 // CHECK-NOT: __riscv_zicfiss {{.*$}}
-// CHECK-NOT: __riscv_zicond {{.*$}}
 // CHECK-NOT: __riscv_zimop {{.*$}}
 // CHECK-NOT: __riscv_ztso {{.*$}}
 // CHECK-NOT: __riscv_zvfbfmin {{.*$}}
@@ -766,6 +766,14 @@
 // RUN:   -o - | FileCheck --check-prefix=CHECK-ZICNTR-EXT %s
 // CHECK-ZICNTR-EXT: __riscv_zicntr 200{{$}}
 
+// RUN: %clang --target=riscv32 \
+// RUN:   -march=rv32i_zicond -E -dM %s \
+// RUN:   -o - | FileCheck --check-prefix=CHECK-ZICOND-EXT %s
+// RUN: %clang --target=riscv64 \
+// RUN:   -march=rv64i_zicond -E -dM %s \
+// RUN:   -o - | FileCheck --check-prefix=CHECK-ZICOND-EXT %s
+// CHECK-ZICOND-EXT: __riscv_zicond  100{{$}}
+
 // RUN: %clang --target=riscv32-unknown-linux-gnu \
 // RUN:   -march=rv32izicsr2p0 -E -dM %s \
 // RUN:   -o - | FileCheck --check-prefix=CHECK-Z

[clang] [llvm] [RISCV] Graduate Zicond to non-experimental (PR #79811)

2024-01-29 Thread Alex Bradbury via cfe-commits

https://github.com/asb updated https://github.com/llvm/llvm-project/pull/79811

>From cf5c3432f66b36db0b8283a967b24686433cdf63 Mon Sep 17 00:00:00 2001
From: Alex Bradbury 
Date: Sun, 28 Jan 2024 08:50:35 +
Subject: [PATCH 1/2] [RISCV] Graduate Zicond to non-experimental

The Zicond extension was ratified in the last few months, with no
changes that affect the LLVM implementation. Although there's surely
more tuning that could be done about when to select Zicond or not, there
are no known correctness issues. Therefore, we should mark support as
non-experimental.
---
 .../CodeGen/RISCV/riscv-func-attr-target.c|  2 +-
 .../test/Preprocessor/riscv-target-features.c | 18 
 llvm/docs/RISCVUsage.rst  |  4 +-
 llvm/docs/ReleaseNotes.rst|  2 +
 llvm/lib/Support/RISCVISAInfo.cpp |  3 +-
 llvm/lib/Target/RISCV/RISCVFeatures.td|  2 +-
 llvm/lib/Target/RISCV/RISCVInstrInfoZicond.td |  2 -
 llvm/test/CodeGen/RISCV/attributes.ll |  4 +-
 llvm/test/CodeGen/RISCV/cmov-branch-opt.ll|  4 +-
 llvm/test/CodeGen/RISCV/condbinops.ll |  4 +-
 llvm/test/CodeGen/RISCV/condops.ll|  4 +-
 .../CodeGen/RISCV/select-binop-identity.ll|  4 +-
 llvm/test/CodeGen/RISCV/select.ll |  4 +-
 .../CodeGen/RISCV/short-forward-branch-opt.ll |  2 +-
 llvm/test/CodeGen/RISCV/xaluo.ll  |  4 +-
 llvm/test/MC/RISCV/rv32zicond-invalid.s   |  4 +-
 llvm/test/MC/RISCV/rv32zicond-valid.s | 12 ++---
 llvm/unittests/Support/RISCVISAInfoTest.cpp   | 46 +--
 18 files changed, 61 insertions(+), 64 deletions(-)

diff --git a/clang/test/CodeGen/RISCV/riscv-func-attr-target.c 
b/clang/test/CodeGen/RISCV/riscv-func-attr-target.c
index 7d3362e84e7588..f216eaf735b4a8 100644
--- a/clang/test/CodeGen/RISCV/riscv-func-attr-target.c
+++ b/clang/test/CodeGen/RISCV/riscv-func-attr-target.c
@@ -39,7 +39,7 @@ __attribute__((target("cpu=sifive-u54"))) void 
testAttrCpuOnly() {}
 // CHECK: attributes #0 = { 
{{.*}}"target-features"="+64bit,+a,+m,+save-restore,+zifencei,-relax,-zbb,-zfa" 
}
 // CHECK: attributes #1 = { {{.*}}"target-cpu"="rocket-rv64" 
"target-features"="+64bit,+a,+d,+f,+m,+save-restore,+v,+zicsr,+zifencei,+zve32f,+zve32x,+zve64d,+zve64f,+zve64x,+zvl128b,+zvl32b,+zvl64b,-relax,-zbb,-zfa"
 "tune-cpu"="generic-rv64" }
 // CHECK: attributes #2 = { 
{{.*}}"target-features"="+64bit,+a,+m,+save-restore,+zbb,+zifencei,-relax,-zfa" 
}
-// CHECK: attributes #3 = { 
{{.*}}"target-features"="+64bit,+a,+d,+experimental-zicond,+f,+m,+save-restore,+v,+zbb,+zicsr,+zifencei,+zve32f,+zve32x,+zve64d,+zve64f,+zve64x,+zvl128b,+zvl32b,+zvl64b,-relax,-zfa"
 }
+// CHECK: attributes #3 = { 
{{.*}}"target-features"="+64bit,+a,+d,+f,+m,+save-restore,+v,+zbb,+zicond,+zicsr,+zifencei,+zve32f,+zve32x,+zve64d,+zve64f,+zve64x,+zvl128b,+zvl32b,+zvl64b,-relax,-zfa"
 }
 // Make sure we append negative features if we override the arch
 // CHECK: attributes #4 = { 
{{.*}}"target-features"="+64bit,+a,+c,+d,+f,+m,+save-restore,+zbb,+zicsr,+zifencei,{{(-[[:alnum:]-]+)(,-[[:alnum:]-]+)*}}"
 }
 // CHECK: attributes #5 = { 
{{.*}}"target-features"="+64bit,+m,+save-restore,{{(-[[:alnum:]-]+)(,-[[:alnum:]-]+)*}}"
 }
diff --git a/clang/test/Preprocessor/riscv-target-features.c 
b/clang/test/Preprocessor/riscv-target-features.c
index 8f50126f1b3628..2361c83a5a6102 100644
--- a/clang/test/Preprocessor/riscv-target-features.c
+++ b/clang/test/Preprocessor/riscv-target-features.c
@@ -88,6 +88,7 @@
 // CHECK-NOT: __riscv_zicclsm {{.*$}}
 // CHECK-NOT: __riscv_ziccrse {{.*$}}
 // CHECK-NOT: __riscv_zicntr {{.*$}}
+// CHECK-NOT: __riscv_zicond {{.*$}}
 // CHECK-NOT: __riscv_zicsr {{.*$}}
 // CHECK-NOT: __riscv_zifencei {{.*$}}
 // CHECK-NOT: __riscv_zihintntl {{.*$}}
@@ -148,7 +149,6 @@
 // CHECK-NOT: __riscv_zfbfmin {{.*$}}
 // CHECK-NOT: __riscv_zicfilp {{.*$}}
 // CHECK-NOT: __riscv_zicfiss {{.*$}}
-// CHECK-NOT: __riscv_zicond {{.*$}}
 // CHECK-NOT: __riscv_zimop {{.*$}}
 // CHECK-NOT: __riscv_ztso {{.*$}}
 // CHECK-NOT: __riscv_zvfbfmin {{.*$}}
@@ -766,6 +766,14 @@
 // RUN:   -o - | FileCheck --check-prefix=CHECK-ZICNTR-EXT %s
 // CHECK-ZICNTR-EXT: __riscv_zicntr 200{{$}}
 
+// RUN: %clang --target=riscv32 \
+// RUN:   -march=rv32i_zicond -E -dM %s \
+// RUN:   -o - | FileCheck --check-prefix=CHECK-ZICOND-EXT %s
+// RUN: %clang --target=riscv64 \
+// RUN:   -march=rv64i_zicond -E -dM %s \
+// RUN:   -o - | FileCheck --check-prefix=CHECK-ZICOND-EXT %s
+// CHECK-ZICOND-EXT: __riscv_zicond  100{{$}}
+
 // RUN: %clang --target=riscv32-unknown-linux-gnu \
 // RUN:   -march=rv32izicsr2p0 -E -dM %s \
 // RUN:   -o - | FileCheck --check-prefix=CHECK-ZICSR-EXT %s
@@ -1349,14 +1357,6 @@
 // RUN:   -o - | FileCheck --check-prefix=CHECK-ZICFILP-EXT %s
 // CHECK-ZICFILP-EXT: __riscv_zicfilp 4000{{$}}
 
-// RUN: %clang --target=riscv32 -menable-experimental-extensions \
-// RUN:   -march=rv32i_zicond1p0 -E -dM %s \
-// RUN:   -o - | FileCheck --check-

[llvm] [clang] [RISCV] Graduate Zicond to non-experimental (PR #79811)

2024-01-29 Thread Alex Bradbury via cfe-commits

asb wrote:

> Should we backport this to llvm 18?

I'd be inclined to do so if there are no objections.

https://github.com/llvm/llvm-project/pull/79811
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [llvm] [RISCV] Graduate Zicond to non-experimental (PR #79811)

2024-01-29 Thread Alex Bradbury via cfe-commits

https://github.com/asb closed https://github.com/llvm/llvm-project/pull/79811
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[llvm] [clang] [RISCV] Add experimental support of Zaamo and Zalrsc (PR #77424)

2024-01-15 Thread Alex Bradbury via cfe-commits

asb wrote:

There should be a release note for this as well as the RISCVUsage update.

I have concerns that the codegen part of this isn't correct. Specifically, the 
[requirement](https://llvm.org/docs/Atomics.html#atomics-and-codegen) that "One 
very important property of the atomic operations is that if your backend 
supports any inline lock-free atomic operations of a given size, you should 
support ALL operations of that size in a lock-free manner." It would be good if 
the codegen tests were updated so we see AMO codegen when only zalrsc is 
present, and cmpxchg when there's only zaamo. I _think_ that for the atomics 
not natively supported at widths up to and including xlen, the tests should 
show lowering to the `__sync_*` instructions [documented 
here](https://llvm.org/docs/Atomics.html#libcalls-sync), similar to when 
+forced-atomics is enabled.

https://github.com/llvm/llvm-project/pull/77424
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[llvm] [clang] [RISCV] CodeGen of RVE and ilp32e/lp64e ABIs (PR #76777)

2024-01-16 Thread Alex Bradbury via cfe-commits

https://github.com/asb approved this pull request.

LGTM. Thanks for your persistence on this!

https://github.com/llvm/llvm-project/pull/76777
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[llvm] [clang] [RISCV] Bump Zfbfmin, Zvfbfmin, and Zvfbfwma to 1.0. (PR #78021)

2024-01-16 Thread Alex Bradbury via cfe-commits

https://github.com/asb approved this pull request.

LGTM.

https://github.com/llvm/llvm-project/pull/78021
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [llvm] [RISCV] Relax march string order constraint (PR #78120)

2024-01-16 Thread Alex Bradbury via cfe-commits

asb wrote:

Just to check, can someone confirm if gcc is now handling ISA strings in this 
way too? I do think this is the right direction to go but haven't done a 
detailed code review of this approach yet.

https://github.com/llvm/llvm-project/pull/78120
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [llvm] [RISCV] Add experimental support of Zaamo and Zalrsc (PR #77424)

2024-01-17 Thread Alex Bradbury via cfe-commits

asb wrote:

CC @jyknight who can hopefully confirm if my interpretation is correct. Based 
on your comment on #77814, perhaps the expectation is that libatomic would have 
a lock-free implementation for any __sync calls used up to the max atomic width 
(e.g. lr/sc based if there's no AMO instructions)?

https://github.com/llvm/llvm-project/pull/77424
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [llvm] [RISCV] Add experimental support of Zaamo and Zalrsc (PR #77424)

2024-01-18 Thread Alex Bradbury via cfe-commits

asb wrote:

Thanks James, that matches what I'd understood. Just one comment on this though:

> If Zaamo is present, but neither Zalrsc nor Zacas are present, I think 
> there's no way to implement a cmpxchg operation. This means lock-free atomics 
> cannot be supported, so it should `setMaxAtomicSizeInBitsSupported(0)`.

Especially given that Zaamo is 
[documented](https://github.com/riscv/riscv-zaamo-zalrsc/blob/main/zaamo-zalrsc.adoc)
 as targeting embedded systems, emitting __sync calls for the non-AMO atomics 
(as would be done with +forced-atomics, presumably they'd be implemented by 
turning off interrupts) seems defensible doesn't it? Or is there a correctness 
issue with that I'm missing?

https://github.com/llvm/llvm-project/pull/77424
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[llvm] [clang] [RISCV] Add experimental support of Zaamo and Zalrsc (PR #77424)

2024-01-18 Thread Alex Bradbury via cfe-commits

asb wrote:

> However, I must say, I cannot understand why this is even a thing that anyone 
> would want. Why would anyone design a single-processor RISCV system that 
> doesn't implement LR/SC? If you don't have the issue of coherent memory 
> across multiple CPUs, LR/SC is utterly trivial to implement -- it's 1 bit of 
> hidden state, indicating whether there is an active reservation. You set the 
> bit in LR. In SC, you check if it's set; if so, execute the store, clear the 
> bit, and return success, otherwise return failure. So, like...why...

That's a fair question. I know that some vendors have talked about using them 
for manipulating device registers (this is mentioned in the RISC-V spec too 
"Another use of AMOs is to provide atomic updates to memory-mapped device 
registers (e..g, setting, clearing, or toggling bits) in the I/O space"). So 
one use case is having a cheap (cycle count and code size) read-modify-write 
for device registers on a very simple core. But as you say, having lr/sc as 
well isn't expensive on a single core system. If you're doing something like 
only supporting AMOs on the peripheral memory space then you probably wouldn't 
want the compiler generating atomic operations for you anyway.

I'm mentioning it in the RISC-V sync-up call shortly to see if anyone has 
insight on how they would intend to use the extension in practice.

https://github.com/llvm/llvm-project/pull/77424
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [RISCV] Re-order riscv-target-features.c to put non-experimental extensions together. (PR #78675)

2024-01-18 Thread Alex Bradbury via cfe-commits

https://github.com/asb approved this pull request.

LGTM.

https://github.com/llvm/llvm-project/pull/78675
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [llvm] [RISCV] Add Zic64b, Ziccamoa, Ziccif, Zicclsm, Ziccrse, and Za64rs to sifive-p450. (PR #79030)

2024-01-22 Thread Alex Bradbury via cfe-commits

https://github.com/asb approved this pull request.

LGTM.

https://github.com/llvm/llvm-project/pull/79030
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[llvm] [clang] [RISCV][MC] Add experimental support of Zaamo and Zalrsc (PR #78970)

2024-01-23 Thread Alex Bradbury via cfe-commits


@@ -1307,6 +1309,13 @@
 // CHECK-ZVKT-EXT: __riscv_zvkt 100{{$}}
 
 // Experimental extensions
+// RUN: %clang --target=riscv32 -menable-experimental-extensions \
+// RUN: -march=rv32i_zaamo0p1 -x c -E -dM %s \

asb wrote:

I'm confused how/if this is actually working. Shouldn't it be zaamo0p2?

https://github.com/llvm/llvm-project/pull/78970
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang] [unittest] Add a test for Generic_GCC::GCCVersion::Parse (PR #69078)

2023-10-18 Thread Alex Bradbury via cfe-commits

asb wrote:

@tbaederr Just came to report the same thing!

@mstorsjo This broke builds that use `-DBUILD_SHARED_LIBS=True`. The problem 
seems to be that the `Generic_GCC` class has the `LLVM_LIBRARY_VISIBILITY` 
attribute meaning the 
`clang::driver::toolchains::Generic_GCC::GCCVersion::Parse(llvm::StringRef)` 
symbol is hidden. Removing that attribute fixes the build. It would be good for 
someone more familiar with this part of the codebase to confirm if that's an 
acceptable fix however.

https://github.com/llvm/llvm-project/pull/69078
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [RISCV] Run mem2reg to simplify Zbc tests (PR #70169)

2023-10-24 Thread Alex Bradbury via cfe-commits

https://github.com/asb approved this pull request.

LGTM.

https://github.com/llvm/llvm-project/pull/70169
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [RISCV] Add processor definition for XiangShan-NanHu (PR #70294)

2023-10-26 Thread Alex Bradbury via cfe-commits

asb wrote:

@dtcxzyw Could you please confirm the status of this core - is it commercially 
available, an academic test chip, something else?

https://github.com/llvm/llvm-project/pull/70294
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [RISCV] Add processor definition for XiangShan-NanHu (PR #70294)

2023-10-26 Thread Alex Bradbury via cfe-commits

asb wrote:

> > @dtcxzyw Could you please confirm the status of this core - is it 
> > commercially available, an academic test chip, something else?
> 
> It's maintained by Beijing Institute of Open Source Chip (BOSC), a non-profit 
> organziation founded by companies and researech institutions. It is provided 
> as an open-source CPU Core IP to the third party. It's not an academic 
> testchip.
> 
> It's not commercially available now, but there have already been a couple of 
> companies using it as the CPU Core IP. I cannot disclose the progress of 
> commercial chips now but hopefully we will see it soon. There are also some 
> companies using it on FPGAs now.

Thanks for clarifying. We don't really have an established policy here - it's 
obvious that commercial designs with active support should go in, and that some 
core design I hacked up over a weekend shouldn't but we haven't had the need to 
discuss anything in-between that. This patch and the scheduling model aren't 
large, but if there's thought of adding substantially more specific tuning it 
might be worth discussing those plans.

All that said, @dtcxzyw this is obviously far from your first patch so I have 
no concern about support being maintained. @preames suggested that we might 
want to think about deprecation policy so that we can be fairly liberal in 
accepting support for new CPUs/microarchs, yet remove them later if they become 
less relevant. Before you go ahead with the merge, it would be good to confirm 
that @preames agrees that this patch doesn't need to block on discussing that 
deprecation policy.

Thanks!

https://github.com/llvm/llvm-project/pull/70294
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [RISCV] Add processor definition for XiangShan-NanHu (PR #70294)

2023-10-27 Thread Alex Bradbury via cfe-commits

asb wrote:

> Xiangshan is of great famousness in China and there is already a community in 
> which many individual developers and organiztions/companies like PLCT, T-Head 
> have participated. So I think we needn't worry about the maintenance. :-)

Thanks for that extra context!

https://github.com/llvm/llvm-project/pull/70294
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 1ecf120 - [index-while-building] Fix build with -DBUILD_SHARED_LIBS=True

2020-08-20 Thread Alex Bradbury via cfe-commits

Author: Alex Bradbury
Date: 2020-08-20T15:12:56+01:00
New Revision: 1ecf120246e7d3e5c9a9ed1db637914bbf4b5702

URL: 
https://github.com/llvm/llvm-project/commit/1ecf120246e7d3e5c9a9ed1db637914bbf4b5702
DIFF: 
https://github.com/llvm/llvm-project/commit/1ecf120246e7d3e5c9a9ed1db637914bbf4b5702.diff

LOG: [index-while-building] Fix build with -DBUILD_SHARED_LIBS=True

The dependencies in clang/lib/IndexSerialization/CMakeLists.txt were
incomplete, leading to link errors for a -DBUILD_SHARED_LIBS=True build.

Added: 


Modified: 
clang/lib/IndexSerialization/CMakeLists.txt

Removed: 




diff  --git a/clang/lib/IndexSerialization/CMakeLists.txt 
b/clang/lib/IndexSerialization/CMakeLists.txt
index 197059fff4b3..65a5d20d6a92 100644
--- a/clang/lib/IndexSerialization/CMakeLists.txt
+++ b/clang/lib/IndexSerialization/CMakeLists.txt
@@ -1,3 +1,7 @@
+set(LLVM_LINK_COMPONENTS
+  Support
+  )
+
 add_clang_library(clangIndexSerialization
   SerializablePathCollection.cpp
 



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] d17de54 - [clang][RISCV][test] Add test that shows incorrect ABI lowering

2022-08-11 Thread Alex Bradbury via cfe-commits

Author: Alex Bradbury
Date: 2022-08-11T18:51:37+01:00
New Revision: d17de5479c6234f9e37fb4deca9e537bf8d3932e

URL: 
https://github.com/llvm/llvm-project/commit/d17de5479c6234f9e37fb4deca9e537bf8d3932e
DIFF: 
https://github.com/llvm/llvm-project/commit/d17de5479c6234f9e37fb4deca9e537bf8d3932e.diff

LOG: [clang][RISCV][test] Add test that shows incorrect ABI lowering

As reported in ,
under hard float ABIs there are issues with lowering structs that
inherit from other structs.

See  for a fix.

Added: 
clang/test/CodeGen/RISCV/riscv-abi.cpp

Modified: 


Removed: 




diff  --git a/clang/test/CodeGen/RISCV/riscv-abi.cpp 
b/clang/test/CodeGen/RISCV/riscv-abi.cpp
new file mode 100644
index 0..ba9e61bbbe7db
--- /dev/null
+++ b/clang/test/CodeGen/RISCV/riscv-abi.cpp
@@ -0,0 +1,88 @@
+// RUN: %clang_cc1 -triple riscv32 -emit-llvm -x c++ %s -o - \
+// RUN:   | FileCheck -check-prefixes=ILP32,ILP32-ILP32F,ILP32-ILP32F-ILP32D %s
+// RUN: %clang_cc1 -triple riscv32 -target-feature +f -target-abi ilp32f 
-emit-llvm -x c++ %s -o - \
+// RUN:   | FileCheck 
-check-prefixes=ILP32F,ILP32-ILP32F,ILP32F-ILP32D,ILP32-ILP32F-ILP32D %s
+// RUN: %clang_cc1 -triple riscv32 -target-feature +f -target-feature +d 
-target-abi ilp32d -emit-llvm %s -x c++ -o - \
+// RUN:   | FileCheck -check-prefixes=ILP32D,ILP32F-ILP32D,ILP32-ILP32F-ILP32D 
%s
+
+// RUN: %clang_cc1 -triple riscv64 -emit-llvm -x c++ %s -o - \
+// RUN:   | FileCheck -check-prefixes=LP64,LP64-LP64F,LP64-LP64F-LP64D %s
+// RUN: %clang_cc1 -triple riscv64 -target-feature +f -target-abi lp64f 
-emit-llvm -x c++ %s -o - \
+// RUN:   | FileCheck 
-check-prefixes=LP64F,LP64-LP64F,LP64F-LP64D,LP64-LP64F-LP64D %s
+// RUN: %clang_cc1 -triple riscv64 -target-feature +f -target-feature +d 
-target-abi lp64d -emit-llvm %s -x c++ -o - \
+// RUN:   | FileCheck -check-prefixes=LP64D,LP64F-LP64D,LP64-LP64F-LP64D %s
+
+#include 
+
+// Ensure that fields inherited from a parent struct are treated in the same
+// way as fields directly in the child for the purposes of RISC-V ABI rules.
+
+struct parent1_int32_s {
+  int32_t i1;
+};
+
+struct child1_int32_s : parent1_int32_s {
+  int32_t i2;
+};
+
+// ILP32-ILP32F-ILP32D-LABEL: define{{.*}} [2 x i32] 
@_Z30int32_int32_struct_inheritance14child1_int32_s([2 x i32] %a.coerce)
+// LP64-LP64F-LP64D-LABEL: define{{.*}} i64 
@_Z30int32_int32_struct_inheritance14child1_int32_s(i64 %a.coerce)
+struct child1_int32_s int32_int32_struct_inheritance(struct child1_int32_s a) {
+  return a;
+}
+
+struct parent2_int32_s {
+  int32_t i1;
+};
+
+struct child2_float_s : parent2_int32_s {
+  float f1;
+};
+
+// TODO: Fix incorrect lowering for hard-float ABIs.
+
+// ILP32: define{{.*}} [2 x i32] 
@_Z30int32_float_struct_inheritance14child2_float_s([2 x i32] %a.coerce)
+// ILP32F-ILP32D: define{{.*}} float 
@_Z30int32_float_struct_inheritance14child2_float_s(float %0)
+// LP64: define{{.*}} i64 
@_Z30int32_float_struct_inheritance14child2_float_s(i64 %a.coerce)
+// LP64F-LP64D: define{{.*}} float 
@_Z30int32_float_struct_inheritance14child2_float_s(float %0)
+struct child2_float_s int32_float_struct_inheritance(struct child2_float_s a) {
+  return a;
+}
+
+struct parent3_float_s {
+  float f1;
+};
+
+struct child3_int64_s : parent3_float_s {
+  int64_t i1;
+};
+
+// TODO: Fix incorrect lowering for lp64f/lp64d ABIs.
+
+// ILP32-ILP32F-ILP32D-LABEL: define{{.*}} void 
@_Z30float_int64_struct_inheritance14child3_int64_s(ptr noalias 
sret(%struct.child3_int64_s)
+// LP64-LP64F-LP64D-LABEL: define{{.*}} [2 x i64] 
@_Z30float_int64_struct_inheritance14child3_int64_s([2 x i64] %a.coerce)
+struct child3_int64_s float_int64_struct_inheritance(struct child3_int64_s a) {
+  return a;
+}
+
+struct parent4_double_s {
+  double d1;
+};
+
+struct child4_double_s : parent4_double_s {
+  double d1;
+};
+
+// TODO: Fix incorrect lowering for ilp32d/lp64d ABIs.
+
+// ILP32-ILP32F-LABEL: define{{.*}} void 
@_Z32double_double_struct_inheritance15child4_double_s(ptr noalias 
sret(%struct.child4_double_s)
+// ILP32D-LABEL: define{{.*}} double 
@_Z32double_double_struct_inheritance15child4_double_s(double %0)
+// LP64-LP64F-LABEL: define{{.*}} [2 x i64] 
@_Z32double_double_struct_inheritance15child4_double_s([2 x i64] %a.coerce)
+// LP64D-LABEL: define{{.*}} double 
@_Z32double_double_struct_inheritance15child4_double_s(double %0)
+struct child4_double_s double_double_struct_inheritance(struct child4_double_s 
a) {
+  return a;
+}
+
+// NOTE: These prefixes are unused. Do not add tests below this line:
+// ILP32F: {{.*}}
+// LP64F: {{.*}}



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] bc53832 - [clang][RISCV] Fix incorrect ABI lowering for inherited structs under hard-float ABIs

2022-08-19 Thread Alex Bradbury via cfe-commits

Author: Alex Bradbury
Date: 2022-08-19T20:31:06+01:00
New Revision: bc538320809fb52af12ec0366118c82201af4f40

URL: 
https://github.com/llvm/llvm-project/commit/bc538320809fb52af12ec0366118c82201af4f40
DIFF: 
https://github.com/llvm/llvm-project/commit/bc538320809fb52af12ec0366118c82201af4f40.diff

LOG: [clang][RISCV] Fix incorrect ABI lowering for inherited structs under 
hard-float ABIs

The hard float ABIs have a rule that if a flattened struct contains
either a single fp value, or an int+fp, or fp+fp then it may be passed
in a pair of registers (if sufficient GPRs+FPRs are available).
detectFPCCEligibleStruct and the helper it calls,
detectFPCCEligibleStructHelper examine the type of the argument/return
value to determine if it complies with the requirements for this ABI
rule.

As reported in bug #57084, this logic produces incorrect results for C++
structs that inherit from other structs. This is because only the fields
of the struct were examined, but enumerating RD->fields misses any
fields in inherited C++ structs. This patch corrects that issue by
adding appropriate logic to enumerate any included base structs.

Differential Revision: https://reviews.llvm.org/D131677

Added: 


Modified: 
clang/lib/CodeGen/TargetInfo.cpp
clang/test/CodeGen/RISCV/riscv-abi.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/TargetInfo.cpp 
b/clang/lib/CodeGen/TargetInfo.cpp
index 39871b0907ede..1f9c903effca8 100644
--- a/clang/lib/CodeGen/TargetInfo.cpp
+++ b/clang/lib/CodeGen/TargetInfo.cpp
@@ -10979,9 +10979,22 @@ bool 
RISCVABIInfo::detectFPCCEligibleStructHelper(QualType Ty, CharUnits CurOff,
 // Unions aren't eligible unless they're empty (which is caught above).
 if (RD->isUnion())
   return false;
+const ASTRecordLayout &Layout = getContext().getASTRecordLayout(RD);
+// If this is a C++ record, check the bases first.
+if (const CXXRecordDecl *CXXRD = dyn_cast(RD)) {
+  for (const CXXBaseSpecifier &B : CXXRD->bases()) {
+const auto *BDecl =
+cast(B.getType()->castAs()->getDecl());
+CharUnits BaseOff = Layout.getBaseClassOffset(BDecl);
+bool Ret = detectFPCCEligibleStructHelper(B.getType(), CurOff + 
BaseOff,
+  Field1Ty, Field1Off, 
Field2Ty,
+  Field2Off);
+if (!Ret)
+  return false;
+  }
+}
 int ZeroWidthBitFieldCount = 0;
 for (const FieldDecl *FD : RD->fields()) {
-  const ASTRecordLayout &Layout = getContext().getASTRecordLayout(RD);
   uint64_t FieldOffInBits = Layout.getFieldOffset(FD->getFieldIndex());
   QualType QTy = FD->getType();
   if (FD->isBitField()) {

diff  --git a/clang/test/CodeGen/RISCV/riscv-abi.cpp 
b/clang/test/CodeGen/RISCV/riscv-abi.cpp
index ba9e61bbbe7db..7e34ffef14d30 100644
--- a/clang/test/CodeGen/RISCV/riscv-abi.cpp
+++ b/clang/test/CodeGen/RISCV/riscv-abi.cpp
@@ -1,15 +1,15 @@
-// RUN: %clang_cc1 -triple riscv32 -emit-llvm -x c++ %s -o - \
+// RUN: %clang_cc1 -triple riscv32 -emit-llvm %s -o - \
 // RUN:   | FileCheck -check-prefixes=ILP32,ILP32-ILP32F,ILP32-ILP32F-ILP32D %s
-// RUN: %clang_cc1 -triple riscv32 -target-feature +f -target-abi ilp32f 
-emit-llvm -x c++ %s -o - \
+// RUN: %clang_cc1 -triple riscv32 -target-feature +f -target-abi ilp32f 
-emit-llvm %s -o - \
 // RUN:   | FileCheck 
-check-prefixes=ILP32F,ILP32-ILP32F,ILP32F-ILP32D,ILP32-ILP32F-ILP32D %s
-// RUN: %clang_cc1 -triple riscv32 -target-feature +f -target-feature +d 
-target-abi ilp32d -emit-llvm %s -x c++ -o - \
+// RUN: %clang_cc1 -triple riscv32 -target-feature +f -target-feature +d 
-target-abi ilp32d -emit-llvm %s -o - \
 // RUN:   | FileCheck -check-prefixes=ILP32D,ILP32F-ILP32D,ILP32-ILP32F-ILP32D 
%s
 
-// RUN: %clang_cc1 -triple riscv64 -emit-llvm -x c++ %s -o - \
+// RUN: %clang_cc1 -triple riscv64 -emit-llvm %s -o - \
 // RUN:   | FileCheck -check-prefixes=LP64,LP64-LP64F,LP64-LP64F-LP64D %s
-// RUN: %clang_cc1 -triple riscv64 -target-feature +f -target-abi lp64f 
-emit-llvm -x c++ %s -o - \
+// RUN: %clang_cc1 -triple riscv64 -target-feature +f -target-abi lp64f 
-emit-llvm %s -o - \
 // RUN:   | FileCheck 
-check-prefixes=LP64F,LP64-LP64F,LP64F-LP64D,LP64-LP64F-LP64D %s
-// RUN: %clang_cc1 -triple riscv64 -target-feature +f -target-feature +d 
-target-abi lp64d -emit-llvm %s -x c++ -o - \
+// RUN: %clang_cc1 -triple riscv64 -target-feature +f -target-feature +d 
-target-abi lp64d -emit-llvm %s -o - \
 // RUN:   | FileCheck -check-prefixes=LP64D,LP64F-LP64D,LP64-LP64F-LP64D %s
 
 #include 
@@ -39,12 +39,10 @@ struct child2_float_s : parent2_int32_s {
   float f1;
 };
 
-// TODO: Fix incorrect lowering for hard-float ABIs.
-
 // ILP32: define{{.*}} [2 x i32] 
@_Z30int32_float_struct_inheritance14child2_float_s([2 x i32] %a.coerce)
-// ILP32F-ILP32D: define{{.*}} float 
@_Z30int32_float_struct_inh

[clang] e0a2818 - [clang][RISCV] Fix ABI mismatch between GCC and Clang (extension of integers on stack)

2023-01-24 Thread Alex Bradbury via cfe-commits

Author: Alex Bradbury
Date: 2023-01-24T14:20:28Z
New Revision: e0a28188d2b53427bc90cdf7f7899c64af102489

URL: 
https://github.com/llvm/llvm-project/commit/e0a28188d2b53427bc90cdf7f7899c64af102489
DIFF: 
https://github.com/llvm/llvm-project/commit/e0a28188d2b53427bc90cdf7f7899c64af102489.diff

LOG: [clang][RISCV] Fix ABI mismatch between GCC and Clang (extension of 
integers on stack)

See  for full
details. Essentially, a previous version of the psABI indicated (by my
reading) that integer scalars passed on the stack were anyext. A [later
commit](https://github.com/riscv-non-isa/riscv-elf-psabi-doc/commit/cec39a064ee0e5b0129973fffab7e3ad1710498f)
changed this to indicate that they are in fact signext/zeroext just as
if they were passed in registers.

This patch adds the change in the release notes but doesn't add a flag
to retain the old behaviour. The hope is that it's sufficiently hard to
trigger an issue due to this that it isn't worthwhile doing so.

Differential Revision: https://reviews.llvm.org/D140401

Added: 


Modified: 
clang/docs/ReleaseNotes.rst
clang/lib/CodeGen/TargetInfo.cpp
clang/test/CodeGen/RISCV/riscv32-ilp32-abi.c
clang/test/CodeGen/RISCV/riscv32-ilp32-ilp32f-abi.c
clang/test/CodeGen/RISCV/riscv32-ilp32-ilp32f-ilp32d-abi.c
clang/test/CodeGen/RISCV/riscv32-ilp32f-abi.c
clang/test/CodeGen/RISCV/riscv64-lp64-abi.c
clang/test/CodeGen/RISCV/riscv64-lp64-lp64f-abi.c
clang/test/CodeGen/RISCV/riscv64-lp64-lp64f-lp64d-abi.c

Removed: 




diff  --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 7d356e53547bf..136f47bd28848 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -879,6 +879,8 @@ RISC-V Support in Clang
 - Fix interaction of ``-mcpu`` and ``-march``, RISC-V backend will take the
   architecture extension union of ``-mcpu`` and ``-march`` before, and now will
   take architecture extensions from ``-march`` if both are given.
+- An ABI mismatch between GCC and Clang that related to the
+  sign/zero-extension of integer scalars was fixed.
 
 X86 Support in Clang
 

diff  --git a/clang/lib/CodeGen/TargetInfo.cpp 
b/clang/lib/CodeGen/TargetInfo.cpp
index 4c3bdbce9e762..be1dbe8480c6e 100644
--- a/clang/lib/CodeGen/TargetInfo.cpp
+++ b/clang/lib/CodeGen/TargetInfo.cpp
@@ -11008,11 +11008,6 @@ void RISCVABIInfo::computeInfo(CGFunctionInfo &FI) 
const {
 }
   }
 
-  // We must track the number of GPRs used in order to conform to the RISC-V
-  // ABI, as integer scalars passed in registers should have signext/zeroext
-  // when promoted, but are anyext if passed on the stack. As GPR usage is
-  // 
diff erent for variadic arguments, we must also track whether we are
-  // examining a vararg or not.
   int ArgGPRsLeft = IsRetIndirect ? NumArgGPRs - 1 : NumArgGPRs;
   int ArgFPRsLeft = FLen ? NumArgFPRs : 0;
   int NumFixedArgs = FI.getNumRequiredArgs();
@@ -11290,7 +11285,6 @@ ABIArgInfo RISCVABIInfo::classifyArgumentType(QualType 
Ty, bool IsFixed,
   }
 
   uint64_t NeededAlign = getContext().getTypeAlign(Ty);
-  bool MustUseStack = false;
   // Determine the number of GPRs needed to pass the current argument
   // according to the ABI. 2*XLen-aligned varargs are passed in "aligned"
   // register pairs, so may consume 3 registers.
@@ -11301,7 +11295,6 @@ ABIArgInfo RISCVABIInfo::classifyArgumentType(QualType 
Ty, bool IsFixed,
 NeededArgGPRs = 2;
 
   if (NeededArgGPRs > ArgGPRsLeft) {
-MustUseStack = true;
 NeededArgGPRs = ArgGPRsLeft;
   }
 
@@ -11312,14 +11305,13 @@ ABIArgInfo 
RISCVABIInfo::classifyArgumentType(QualType Ty, bool IsFixed,
 if (const EnumType *EnumTy = Ty->getAs())
   Ty = EnumTy->getDecl()->getIntegerType();
 
-// All integral types are promoted to XLen width, unless passed on the
-// stack.
-if (Size < XLen && Ty->isIntegralOrEnumerationType() && !MustUseStack) {
+// All integral types are promoted to XLen width
+if (Size < XLen && Ty->isIntegralOrEnumerationType()) {
   return extendType(Ty);
 }
 
 if (const auto *EIT = Ty->getAs()) {
-  if (EIT->getNumBits() < XLen && !MustUseStack)
+  if (EIT->getNumBits() < XLen)
 return extendType(Ty);
   if (EIT->getNumBits() > 128 ||
   (!getContext().getTargetInfo().hasInt128Type() &&

diff  --git a/clang/test/CodeGen/RISCV/riscv32-ilp32-abi.c 
b/clang/test/CodeGen/RISCV/riscv32-ilp32-abi.c
index e18bd1d7eab3f..9b157ad5c782e 100644
--- a/clang/test/CodeGen/RISCV/riscv32-ilp32-abi.c
+++ b/clang/test/CodeGen/RISCV/riscv32-ilp32-abi.c
@@ -22,20 +22,16 @@ struct large {
   int32_t a, b, c, d;
 };
 
-// Scalars passed on the stack should not have signext/zeroext attributes
-// (they are anyext).
+// Scalars passed on the stack should have signext/zeroext attributes, just as
+// if they were passed in registers.
 

[clang] 123223a - [clang-repl] XFAIL riscv targets in simple-exception test case

2023-01-17 Thread Alex Bradbury via cfe-commits

Author: Alex Bradbury
Date: 2023-01-17T14:28:15Z
New Revision: 123223ab87ca50d1ce4f8c08128d0237b3d31c84

URL: 
https://github.com/llvm/llvm-project/commit/123223ab87ca50d1ce4f8c08128d0237b3d31c84
DIFF: 
https://github.com/llvm/llvm-project/commit/123223ab87ca50d1ce4f8c08128d0237b3d31c84.diff

LOG: [clang-repl] XFAIL riscv targets in simple-exception test case

This test fails for RISC-V and Arm targets are already XFAILed, so add
RISC-V to the XFAIL list.

Differential Revision: https://reviews.llvm.org/D141380

Added: 


Modified: 
clang/test/Interpreter/simple-exception.cpp

Removed: 




diff  --git a/clang/test/Interpreter/simple-exception.cpp 
b/clang/test/Interpreter/simple-exception.cpp
index 57e14e47a30a1..886b8ffd2d701 100644
--- a/clang/test/Interpreter/simple-exception.cpp
+++ b/clang/test/Interpreter/simple-exception.cpp
@@ -1,7 +1,7 @@
 // clang-format off
 // UNSUPPORTED: system-aix
-// XFAIL for arm and arm64, or running on Windows.
-// XFAIL: target=arm{{.*}}, system-windows
+// XFAIL for arm, arm64, riscv, or running on Windows.
+// XFAIL: target={{(arm|riscv).*}}, system-windows
 // RUN: cat %s | clang-repl | FileCheck %s
 extern "C" int printf(const char *, ...);
 
@@ -11,4 +11,4 @@ auto r1 = checkException();
 // CHECK: Running f()
 // CHECK-NEXT: Simple exception
 
-%quit
\ No newline at end of file
+%quit



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [RISCV] Update Zfa extension version to 1.0 (PR #67964)

2023-10-02 Thread Alex Bradbury via cfe-commits

https://github.com/asb created https://github.com/llvm/llvm-project/pull/67964

The Zfa specification was recently ratified
. This commit 
bumps the version to 1.0, but leaves it as an experimental extension (to be 
done in a follow-on patch), so reviews can focus on confirming there haven't 
been spec changes we have missed (which as noted below, is more difficult than 
usual).

Because the development of the Zfa spec overlapped with the transition of 
riscv-isa-manual from LaTeX to AsciiDoc, it's more difficult than usual to 
confirm version changes. The linked PDF in RISCVUsage is for some reason a 404. 
Key commit histories to review are:
* Changes to zfa.adoc on the main branch 

* Changes to zfa.tex on the now defunct latex branch 


>From reviewing these, I believe there have been no changes to the spec since 
>version 0.1/0.2 (sadly the AsciiDoc and LaTeX versions of the spec are 
>inconsistent about version numbering).

There hasn't been a GitHub release of the spec since Zfa was ratified (though 
I've requested one
), so RISCVUsage is 
updated to link to the current Zfa.adoc. I don't think we need to block on 
this, as we expect to shortly move Zfa to non-experimental, at which point we 
don't link to individual spec documents in RISCVUsage.

>From 79ab61e07a01e503f22e717c4b0e64b7741c59a0 Mon Sep 17 00:00:00 2001
From: Alex Bradbury 
Date: Mon, 2 Oct 2023 11:06:44 +0100
Subject: [PATCH] [RISCV] Update Zfa extension version to 1.0

The Zfa specification was recently ratified
. This
commit bumps the version to 1.0, but leaves it as an experimental
extension (to be done in a follow-on patch), so reviews can focus on
confirming there haven't been spec changes we have missed (which as
noted below, is more difficult than usual).

Because the development of the Zfa spec overlapped with the transition
of riscv-isa-manual from LaTeX to AsciiDoc, it's more difficult than
usual to confirm version changes. The linked PDF in RISCVUsage is for
some reason a 404. Key commit histories to review are:
* Changes to zfa.adoc on the main branch
  
* Changes to zfa.tex on the now defunct latex branch
  

>From reviewing these, I believe there have been no changes to the spec
since version 0.1/0.2 (sadly the AsciiDoc and LaTeX versions of the spec
are inconsistent about version numbering).

There hasn't been a GitHub release of the spec since Zfa was ratified
(though I've requested one
), so RISCVUsage
is updated to link to the current Zfa.adoc. I don't think we need to
block on this, as we expect to shortly move Zfa to non-experimental, at
which point we don't link to individual spec documents in RISCVUsage.
---
 clang/test/Driver/riscv-arch.c  | 4 ++--
 clang/test/Preprocessor/riscv-target-features.c | 6 +++---
 llvm/docs/RISCVUsage.rst| 2 +-
 llvm/docs/ReleaseNotes.rst  | 1 +
 llvm/lib/Support/RISCVISAInfo.cpp   | 2 +-
 llvm/test/CodeGen/RISCV/attributes.ll   | 4 ++--
 llvm/test/MC/RISCV/attribute-arch.s | 4 ++--
 7 files changed, 12 insertions(+), 11 deletions(-)

diff --git a/clang/test/Driver/riscv-arch.c b/clang/test/Driver/riscv-arch.c
index 92a6a59cba2317c..4896c0184507dd4 100644
--- a/clang/test/Driver/riscv-arch.c
+++ b/clang/test/Driver/riscv-arch.c
@@ -385,9 +385,9 @@
 // RUN: not %clang --target=riscv32-unknown-elf -march=rv32izfa0p1 
-menable-experimental-extensions -### %s \
 // RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-EXPERIMENTAL-BADVERS 
%s
 // RV32-EXPERIMENTAL-BADVERS: error: invalid arch name 'rv32izfa0p1'
-// RV32-EXPERIMENTAL-BADVERS: unsupported version number 0.1 for experimental 
extension 'zfa' (this compiler supports 0.2)
+// RV32-EXPERIMENTAL-BADVERS: unsupported version number 0.1 for experimental 
extension 'zfa' (this compiler supports 1.0)
 
-// RUN: %clang --target=riscv32-unknown-elf -march=rv32izfa0p2 
-menable-experimental-extensions -### %s \
+// RUN: %clang --target=riscv32-unknown-elf -march=rv32izfa1p0 
-menable-experimental-extensions -### %s \
 // RUN: -fsyntax-only 2>&1 | FileCheck 
-check-prefix=RV32-EXPERIMENTAL-GOODVERS %s
 // RV32-EXPERIMENTAL-GOODVERS: "-target-feature" "+experimental-zfa"
 
diff --git a/clang/test/Preprocessor/riscv-target-features.c 
b/clang/test/Preprocessor/riscv-target-features.c
index 4dd83cfa0620b90..4b9ec423200017f 100644
--- a/clang/test/Preprocessor/riscv-target-features.c
+++ b/clang/test/Preprocessor/riscv-target-features.c
@@ -

[clang] [RISCV] Update Zfa extension version to 1.0 (PR #67964)

2023-10-02 Thread Alex Bradbury via cfe-commits

https://github.com/asb updated https://github.com/llvm/llvm-project/pull/67964

>From 79ab61e07a01e503f22e717c4b0e64b7741c59a0 Mon Sep 17 00:00:00 2001
From: Alex Bradbury 
Date: Mon, 2 Oct 2023 11:06:44 +0100
Subject: [PATCH 1/2] [RISCV] Update Zfa extension version to 1.0

The Zfa specification was recently ratified
. This
commit bumps the version to 1.0, but leaves it as an experimental
extension (to be done in a follow-on patch), so reviews can focus on
confirming there haven't been spec changes we have missed (which as
noted below, is more difficult than usual).

Because the development of the Zfa spec overlapped with the transition
of riscv-isa-manual from LaTeX to AsciiDoc, it's more difficult than
usual to confirm version changes. The linked PDF in RISCVUsage is for
some reason a 404. Key commit histories to review are:
* Changes to zfa.adoc on the main branch
  
* Changes to zfa.tex on the now defunct latex branch
  

>From reviewing these, I believe there have been no changes to the spec
since version 0.1/0.2 (sadly the AsciiDoc and LaTeX versions of the spec
are inconsistent about version numbering).

There hasn't been a GitHub release of the spec since Zfa was ratified
(though I've requested one
), so RISCVUsage
is updated to link to the current Zfa.adoc. I don't think we need to
block on this, as we expect to shortly move Zfa to non-experimental, at
which point we don't link to individual spec documents in RISCVUsage.
---
 clang/test/Driver/riscv-arch.c  | 4 ++--
 clang/test/Preprocessor/riscv-target-features.c | 6 +++---
 llvm/docs/RISCVUsage.rst| 2 +-
 llvm/docs/ReleaseNotes.rst  | 1 +
 llvm/lib/Support/RISCVISAInfo.cpp   | 2 +-
 llvm/test/CodeGen/RISCV/attributes.ll   | 4 ++--
 llvm/test/MC/RISCV/attribute-arch.s | 4 ++--
 7 files changed, 12 insertions(+), 11 deletions(-)

diff --git a/clang/test/Driver/riscv-arch.c b/clang/test/Driver/riscv-arch.c
index 92a6a59cba2317c..4896c0184507dd4 100644
--- a/clang/test/Driver/riscv-arch.c
+++ b/clang/test/Driver/riscv-arch.c
@@ -385,9 +385,9 @@
 // RUN: not %clang --target=riscv32-unknown-elf -march=rv32izfa0p1 
-menable-experimental-extensions -### %s \
 // RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-EXPERIMENTAL-BADVERS 
%s
 // RV32-EXPERIMENTAL-BADVERS: error: invalid arch name 'rv32izfa0p1'
-// RV32-EXPERIMENTAL-BADVERS: unsupported version number 0.1 for experimental 
extension 'zfa' (this compiler supports 0.2)
+// RV32-EXPERIMENTAL-BADVERS: unsupported version number 0.1 for experimental 
extension 'zfa' (this compiler supports 1.0)
 
-// RUN: %clang --target=riscv32-unknown-elf -march=rv32izfa0p2 
-menable-experimental-extensions -### %s \
+// RUN: %clang --target=riscv32-unknown-elf -march=rv32izfa1p0 
-menable-experimental-extensions -### %s \
 // RUN: -fsyntax-only 2>&1 | FileCheck 
-check-prefix=RV32-EXPERIMENTAL-GOODVERS %s
 // RV32-EXPERIMENTAL-GOODVERS: "-target-feature" "+experimental-zfa"
 
diff --git a/clang/test/Preprocessor/riscv-target-features.c 
b/clang/test/Preprocessor/riscv-target-features.c
index 4dd83cfa0620b90..4b9ec423200017f 100644
--- a/clang/test/Preprocessor/riscv-target-features.c
+++ b/clang/test/Preprocessor/riscv-target-features.c
@@ -1002,12 +1002,12 @@
 // CHECK-ZACAS-EXT: __riscv_zacas 100{{$}}
 
 // RUN: %clang --target=riscv32-unknown-linux-gnu 
-menable-experimental-extensions \
-// RUN: -march=rv32izfa0p2 -x c -E -dM %s \
+// RUN: -march=rv32izfa1p0 -x c -E -dM %s \
 // RUN: -o - | FileCheck --check-prefix=CHECK-ZFA-EXT %s
 // RUN: %clang --target=riscv64-unknown-linux-gnu 
-menable-experimental-extensions \
-// RUN: -march=rv64izfa0p2 -x c -E -dM %s \
+// RUN: -march=rv64izfa1p0 -x c -E -dM %s \
 // RUN: -o - | FileCheck --check-prefix=CHECK-ZFA-EXT %s
-// CHECK-ZFA-EXT: __riscv_zfa 2000{{$}}
+// CHECK-ZFA-EXT: __riscv_zfa 100{{$}}
 
 // RUN: %clang --target=riscv32 -menable-experimental-extensions \
 // RUN: -march=rv32izfbfmin0p8 -x c -E -dM %s \
diff --git a/llvm/docs/RISCVUsage.rst b/llvm/docs/RISCVUsage.rst
index 8d12d58738c609a..647c4c49500c161 100644
--- a/llvm/docs/RISCVUsage.rst
+++ b/llvm/docs/RISCVUsage.rst
@@ -197,7 +197,7 @@ The primary goal of experimental support is to assist in 
the process of ratifica
   LLVM implements the `1.0-rc1 draft specification 
`_.
 
 ``experimental-zfa``
-  LLVM implements the `0.2 draft specification 
`__.
+  LLVM implements the `1.0 specification 


[clang] [RISCV] Update Zfa extension version to 1.0 (PR #67964)

2023-10-02 Thread Alex Bradbury via cfe-commits

https://github.com/asb edited https://github.com/llvm/llvm-project/pull/67964
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [RISCV] Update Zfa extension version to 1.0 (PR #67964)

2023-10-03 Thread Alex Bradbury via cfe-commits

https://github.com/asb updated https://github.com/llvm/llvm-project/pull/67964

>From 79ab61e07a01e503f22e717c4b0e64b7741c59a0 Mon Sep 17 00:00:00 2001
From: Alex Bradbury 
Date: Mon, 2 Oct 2023 11:06:44 +0100
Subject: [PATCH 1/3] [RISCV] Update Zfa extension version to 1.0

The Zfa specification was recently ratified
. This
commit bumps the version to 1.0, but leaves it as an experimental
extension (to be done in a follow-on patch), so reviews can focus on
confirming there haven't been spec changes we have missed (which as
noted below, is more difficult than usual).

Because the development of the Zfa spec overlapped with the transition
of riscv-isa-manual from LaTeX to AsciiDoc, it's more difficult than
usual to confirm version changes. The linked PDF in RISCVUsage is for
some reason a 404. Key commit histories to review are:
* Changes to zfa.adoc on the main branch
  
* Changes to zfa.tex on the now defunct latex branch
  

>From reviewing these, I believe there have been no changes to the spec
since version 0.1/0.2 (sadly the AsciiDoc and LaTeX versions of the spec
are inconsistent about version numbering).

There hasn't been a GitHub release of the spec since Zfa was ratified
(though I've requested one
), so RISCVUsage
is updated to link to the current Zfa.adoc. I don't think we need to
block on this, as we expect to shortly move Zfa to non-experimental, at
which point we don't link to individual spec documents in RISCVUsage.
---
 clang/test/Driver/riscv-arch.c  | 4 ++--
 clang/test/Preprocessor/riscv-target-features.c | 6 +++---
 llvm/docs/RISCVUsage.rst| 2 +-
 llvm/docs/ReleaseNotes.rst  | 1 +
 llvm/lib/Support/RISCVISAInfo.cpp   | 2 +-
 llvm/test/CodeGen/RISCV/attributes.ll   | 4 ++--
 llvm/test/MC/RISCV/attribute-arch.s | 4 ++--
 7 files changed, 12 insertions(+), 11 deletions(-)

diff --git a/clang/test/Driver/riscv-arch.c b/clang/test/Driver/riscv-arch.c
index 92a6a59cba2317c..4896c0184507dd4 100644
--- a/clang/test/Driver/riscv-arch.c
+++ b/clang/test/Driver/riscv-arch.c
@@ -385,9 +385,9 @@
 // RUN: not %clang --target=riscv32-unknown-elf -march=rv32izfa0p1 
-menable-experimental-extensions -### %s \
 // RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-EXPERIMENTAL-BADVERS 
%s
 // RV32-EXPERIMENTAL-BADVERS: error: invalid arch name 'rv32izfa0p1'
-// RV32-EXPERIMENTAL-BADVERS: unsupported version number 0.1 for experimental 
extension 'zfa' (this compiler supports 0.2)
+// RV32-EXPERIMENTAL-BADVERS: unsupported version number 0.1 for experimental 
extension 'zfa' (this compiler supports 1.0)
 
-// RUN: %clang --target=riscv32-unknown-elf -march=rv32izfa0p2 
-menable-experimental-extensions -### %s \
+// RUN: %clang --target=riscv32-unknown-elf -march=rv32izfa1p0 
-menable-experimental-extensions -### %s \
 // RUN: -fsyntax-only 2>&1 | FileCheck 
-check-prefix=RV32-EXPERIMENTAL-GOODVERS %s
 // RV32-EXPERIMENTAL-GOODVERS: "-target-feature" "+experimental-zfa"
 
diff --git a/clang/test/Preprocessor/riscv-target-features.c 
b/clang/test/Preprocessor/riscv-target-features.c
index 4dd83cfa0620b90..4b9ec423200017f 100644
--- a/clang/test/Preprocessor/riscv-target-features.c
+++ b/clang/test/Preprocessor/riscv-target-features.c
@@ -1002,12 +1002,12 @@
 // CHECK-ZACAS-EXT: __riscv_zacas 100{{$}}
 
 // RUN: %clang --target=riscv32-unknown-linux-gnu 
-menable-experimental-extensions \
-// RUN: -march=rv32izfa0p2 -x c -E -dM %s \
+// RUN: -march=rv32izfa1p0 -x c -E -dM %s \
 // RUN: -o - | FileCheck --check-prefix=CHECK-ZFA-EXT %s
 // RUN: %clang --target=riscv64-unknown-linux-gnu 
-menable-experimental-extensions \
-// RUN: -march=rv64izfa0p2 -x c -E -dM %s \
+// RUN: -march=rv64izfa1p0 -x c -E -dM %s \
 // RUN: -o - | FileCheck --check-prefix=CHECK-ZFA-EXT %s
-// CHECK-ZFA-EXT: __riscv_zfa 2000{{$}}
+// CHECK-ZFA-EXT: __riscv_zfa 100{{$}}
 
 // RUN: %clang --target=riscv32 -menable-experimental-extensions \
 // RUN: -march=rv32izfbfmin0p8 -x c -E -dM %s \
diff --git a/llvm/docs/RISCVUsage.rst b/llvm/docs/RISCVUsage.rst
index 8d12d58738c609a..647c4c49500c161 100644
--- a/llvm/docs/RISCVUsage.rst
+++ b/llvm/docs/RISCVUsage.rst
@@ -197,7 +197,7 @@ The primary goal of experimental support is to assist in 
the process of ratifica
   LLVM implements the `1.0-rc1 draft specification 
`_.
 
 ``experimental-zfa``
-  LLVM implements the `0.2 draft specification 
`__.
+  LLVM implements the `1.0 specification 


[clang] [RISCV] Update Zfa extension version to 1.0 (PR #67964)

2023-10-03 Thread Alex Bradbury via cfe-commits

asb wrote:

> ⚠️ C/C++ code formatter, clang-format found issues in your code. ⚠️

This is a whitespace change > 20 lines away from the edit made in the test 
file, so I don't believe it's appropriate to reformat in this PR.

https://github.com/llvm/llvm-project/pull/67964
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [RISCV] Mark the Zfa extension as non-experimental (PR #68113)

2023-10-03 Thread Alex Bradbury via cfe-commits

https://github.com/asb created https://github.com/llvm/llvm-project/pull/68113

Following the version bump in #67964 and the bug fix in #68026 I believe we're 
ready to mark Zfa as non-experimental. I'll note the GCC torture suite passes 
now with Zfa enabled (though it's more of a litmus test than anything else).

This PR is stacked on top of #67694 - only the most recent commit should be 
reviewed.

>From 79ab61e07a01e503f22e717c4b0e64b7741c59a0 Mon Sep 17 00:00:00 2001
From: Alex Bradbury 
Date: Mon, 2 Oct 2023 11:06:44 +0100
Subject: [PATCH 1/4] [RISCV] Update Zfa extension version to 1.0

The Zfa specification was recently ratified
. This
commit bumps the version to 1.0, but leaves it as an experimental
extension (to be done in a follow-on patch), so reviews can focus on
confirming there haven't been spec changes we have missed (which as
noted below, is more difficult than usual).

Because the development of the Zfa spec overlapped with the transition
of riscv-isa-manual from LaTeX to AsciiDoc, it's more difficult than
usual to confirm version changes. The linked PDF in RISCVUsage is for
some reason a 404. Key commit histories to review are:
* Changes to zfa.adoc on the main branch
  
* Changes to zfa.tex on the now defunct latex branch
  

>From reviewing these, I believe there have been no changes to the spec
since version 0.1/0.2 (sadly the AsciiDoc and LaTeX versions of the spec
are inconsistent about version numbering).

There hasn't been a GitHub release of the spec since Zfa was ratified
(though I've requested one
), so RISCVUsage
is updated to link to the current Zfa.adoc. I don't think we need to
block on this, as we expect to shortly move Zfa to non-experimental, at
which point we don't link to individual spec documents in RISCVUsage.
---
 clang/test/Driver/riscv-arch.c  | 4 ++--
 clang/test/Preprocessor/riscv-target-features.c | 6 +++---
 llvm/docs/RISCVUsage.rst| 2 +-
 llvm/docs/ReleaseNotes.rst  | 1 +
 llvm/lib/Support/RISCVISAInfo.cpp   | 2 +-
 llvm/test/CodeGen/RISCV/attributes.ll   | 4 ++--
 llvm/test/MC/RISCV/attribute-arch.s | 4 ++--
 7 files changed, 12 insertions(+), 11 deletions(-)

diff --git a/clang/test/Driver/riscv-arch.c b/clang/test/Driver/riscv-arch.c
index 92a6a59cba2317c..4896c0184507dd4 100644
--- a/clang/test/Driver/riscv-arch.c
+++ b/clang/test/Driver/riscv-arch.c
@@ -385,9 +385,9 @@
 // RUN: not %clang --target=riscv32-unknown-elf -march=rv32izfa0p1 
-menable-experimental-extensions -### %s \
 // RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-EXPERIMENTAL-BADVERS 
%s
 // RV32-EXPERIMENTAL-BADVERS: error: invalid arch name 'rv32izfa0p1'
-// RV32-EXPERIMENTAL-BADVERS: unsupported version number 0.1 for experimental 
extension 'zfa' (this compiler supports 0.2)
+// RV32-EXPERIMENTAL-BADVERS: unsupported version number 0.1 for experimental 
extension 'zfa' (this compiler supports 1.0)
 
-// RUN: %clang --target=riscv32-unknown-elf -march=rv32izfa0p2 
-menable-experimental-extensions -### %s \
+// RUN: %clang --target=riscv32-unknown-elf -march=rv32izfa1p0 
-menable-experimental-extensions -### %s \
 // RUN: -fsyntax-only 2>&1 | FileCheck 
-check-prefix=RV32-EXPERIMENTAL-GOODVERS %s
 // RV32-EXPERIMENTAL-GOODVERS: "-target-feature" "+experimental-zfa"
 
diff --git a/clang/test/Preprocessor/riscv-target-features.c 
b/clang/test/Preprocessor/riscv-target-features.c
index 4dd83cfa0620b90..4b9ec423200017f 100644
--- a/clang/test/Preprocessor/riscv-target-features.c
+++ b/clang/test/Preprocessor/riscv-target-features.c
@@ -1002,12 +1002,12 @@
 // CHECK-ZACAS-EXT: __riscv_zacas 100{{$}}
 
 // RUN: %clang --target=riscv32-unknown-linux-gnu 
-menable-experimental-extensions \
-// RUN: -march=rv32izfa0p2 -x c -E -dM %s \
+// RUN: -march=rv32izfa1p0 -x c -E -dM %s \
 // RUN: -o - | FileCheck --check-prefix=CHECK-ZFA-EXT %s
 // RUN: %clang --target=riscv64-unknown-linux-gnu 
-menable-experimental-extensions \
-// RUN: -march=rv64izfa0p2 -x c -E -dM %s \
+// RUN: -march=rv64izfa1p0 -x c -E -dM %s \
 // RUN: -o - | FileCheck --check-prefix=CHECK-ZFA-EXT %s
-// CHECK-ZFA-EXT: __riscv_zfa 2000{{$}}
+// CHECK-ZFA-EXT: __riscv_zfa 100{{$}}
 
 // RUN: %clang --target=riscv32 -menable-experimental-extensions \
 // RUN: -march=rv32izfbfmin0p8 -x c -E -dM %s \
diff --git a/llvm/docs/RISCVUsage.rst b/llvm/docs/RISCVUsage.rst
index 8d12d58738c609a..647c4c49500c161 100644
--- a/llvm/docs/RISCVUsage.rst
+++ b/llvm/docs/RISCVUsage.rst
@@ -197,7 +197,7 @@ The primary goal of experimental support is to assist in 
the process of ratifica
   LLVM implements the `1.0-rc1 draft specification 


[clang] [RISCV] Update Zfa extension version to 1.0 (PR #67964)

2023-10-03 Thread Alex Bradbury via cfe-commits

https://github.com/asb updated https://github.com/llvm/llvm-project/pull/67964

>From 79ab61e07a01e503f22e717c4b0e64b7741c59a0 Mon Sep 17 00:00:00 2001
From: Alex Bradbury 
Date: Mon, 2 Oct 2023 11:06:44 +0100
Subject: [PATCH 1/4] [RISCV] Update Zfa extension version to 1.0

The Zfa specification was recently ratified
. This
commit bumps the version to 1.0, but leaves it as an experimental
extension (to be done in a follow-on patch), so reviews can focus on
confirming there haven't been spec changes we have missed (which as
noted below, is more difficult than usual).

Because the development of the Zfa spec overlapped with the transition
of riscv-isa-manual from LaTeX to AsciiDoc, it's more difficult than
usual to confirm version changes. The linked PDF in RISCVUsage is for
some reason a 404. Key commit histories to review are:
* Changes to zfa.adoc on the main branch
  
* Changes to zfa.tex on the now defunct latex branch
  

>From reviewing these, I believe there have been no changes to the spec
since version 0.1/0.2 (sadly the AsciiDoc and LaTeX versions of the spec
are inconsistent about version numbering).

There hasn't been a GitHub release of the spec since Zfa was ratified
(though I've requested one
), so RISCVUsage
is updated to link to the current Zfa.adoc. I don't think we need to
block on this, as we expect to shortly move Zfa to non-experimental, at
which point we don't link to individual spec documents in RISCVUsage.
---
 clang/test/Driver/riscv-arch.c  | 4 ++--
 clang/test/Preprocessor/riscv-target-features.c | 6 +++---
 llvm/docs/RISCVUsage.rst| 2 +-
 llvm/docs/ReleaseNotes.rst  | 1 +
 llvm/lib/Support/RISCVISAInfo.cpp   | 2 +-
 llvm/test/CodeGen/RISCV/attributes.ll   | 4 ++--
 llvm/test/MC/RISCV/attribute-arch.s | 4 ++--
 7 files changed, 12 insertions(+), 11 deletions(-)

diff --git a/clang/test/Driver/riscv-arch.c b/clang/test/Driver/riscv-arch.c
index 92a6a59cba2317c..4896c0184507dd4 100644
--- a/clang/test/Driver/riscv-arch.c
+++ b/clang/test/Driver/riscv-arch.c
@@ -385,9 +385,9 @@
 // RUN: not %clang --target=riscv32-unknown-elf -march=rv32izfa0p1 
-menable-experimental-extensions -### %s \
 // RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-EXPERIMENTAL-BADVERS 
%s
 // RV32-EXPERIMENTAL-BADVERS: error: invalid arch name 'rv32izfa0p1'
-// RV32-EXPERIMENTAL-BADVERS: unsupported version number 0.1 for experimental 
extension 'zfa' (this compiler supports 0.2)
+// RV32-EXPERIMENTAL-BADVERS: unsupported version number 0.1 for experimental 
extension 'zfa' (this compiler supports 1.0)
 
-// RUN: %clang --target=riscv32-unknown-elf -march=rv32izfa0p2 
-menable-experimental-extensions -### %s \
+// RUN: %clang --target=riscv32-unknown-elf -march=rv32izfa1p0 
-menable-experimental-extensions -### %s \
 // RUN: -fsyntax-only 2>&1 | FileCheck 
-check-prefix=RV32-EXPERIMENTAL-GOODVERS %s
 // RV32-EXPERIMENTAL-GOODVERS: "-target-feature" "+experimental-zfa"
 
diff --git a/clang/test/Preprocessor/riscv-target-features.c 
b/clang/test/Preprocessor/riscv-target-features.c
index 4dd83cfa0620b90..4b9ec423200017f 100644
--- a/clang/test/Preprocessor/riscv-target-features.c
+++ b/clang/test/Preprocessor/riscv-target-features.c
@@ -1002,12 +1002,12 @@
 // CHECK-ZACAS-EXT: __riscv_zacas 100{{$}}
 
 // RUN: %clang --target=riscv32-unknown-linux-gnu 
-menable-experimental-extensions \
-// RUN: -march=rv32izfa0p2 -x c -E -dM %s \
+// RUN: -march=rv32izfa1p0 -x c -E -dM %s \
 // RUN: -o - | FileCheck --check-prefix=CHECK-ZFA-EXT %s
 // RUN: %clang --target=riscv64-unknown-linux-gnu 
-menable-experimental-extensions \
-// RUN: -march=rv64izfa0p2 -x c -E -dM %s \
+// RUN: -march=rv64izfa1p0 -x c -E -dM %s \
 // RUN: -o - | FileCheck --check-prefix=CHECK-ZFA-EXT %s
-// CHECK-ZFA-EXT: __riscv_zfa 2000{{$}}
+// CHECK-ZFA-EXT: __riscv_zfa 100{{$}}
 
 // RUN: %clang --target=riscv32 -menable-experimental-extensions \
 // RUN: -march=rv32izfbfmin0p8 -x c -E -dM %s \
diff --git a/llvm/docs/RISCVUsage.rst b/llvm/docs/RISCVUsage.rst
index 8d12d58738c609a..647c4c49500c161 100644
--- a/llvm/docs/RISCVUsage.rst
+++ b/llvm/docs/RISCVUsage.rst
@@ -197,7 +197,7 @@ The primary goal of experimental support is to assist in 
the process of ratifica
   LLVM implements the `1.0-rc1 draft specification 
`_.
 
 ``experimental-zfa``
-  LLVM implements the `0.2 draft specification 
`__.
+  LLVM implements the `1.0 specification 


[clang] [RISCV] Mark the Zfa extension as non-experimental (PR #68113)

2023-10-03 Thread Alex Bradbury via cfe-commits

https://github.com/asb updated https://github.com/llvm/llvm-project/pull/68113

>From 79ab61e07a01e503f22e717c4b0e64b7741c59a0 Mon Sep 17 00:00:00 2001
From: Alex Bradbury 
Date: Mon, 2 Oct 2023 11:06:44 +0100
Subject: [PATCH 1/6] [RISCV] Update Zfa extension version to 1.0

The Zfa specification was recently ratified
. This
commit bumps the version to 1.0, but leaves it as an experimental
extension (to be done in a follow-on patch), so reviews can focus on
confirming there haven't been spec changes we have missed (which as
noted below, is more difficult than usual).

Because the development of the Zfa spec overlapped with the transition
of riscv-isa-manual from LaTeX to AsciiDoc, it's more difficult than
usual to confirm version changes. The linked PDF in RISCVUsage is for
some reason a 404. Key commit histories to review are:
* Changes to zfa.adoc on the main branch
  
* Changes to zfa.tex on the now defunct latex branch
  

>From reviewing these, I believe there have been no changes to the spec
since version 0.1/0.2 (sadly the AsciiDoc and LaTeX versions of the spec
are inconsistent about version numbering).

There hasn't been a GitHub release of the spec since Zfa was ratified
(though I've requested one
), so RISCVUsage
is updated to link to the current Zfa.adoc. I don't think we need to
block on this, as we expect to shortly move Zfa to non-experimental, at
which point we don't link to individual spec documents in RISCVUsage.
---
 clang/test/Driver/riscv-arch.c  | 4 ++--
 clang/test/Preprocessor/riscv-target-features.c | 6 +++---
 llvm/docs/RISCVUsage.rst| 2 +-
 llvm/docs/ReleaseNotes.rst  | 1 +
 llvm/lib/Support/RISCVISAInfo.cpp   | 2 +-
 llvm/test/CodeGen/RISCV/attributes.ll   | 4 ++--
 llvm/test/MC/RISCV/attribute-arch.s | 4 ++--
 7 files changed, 12 insertions(+), 11 deletions(-)

diff --git a/clang/test/Driver/riscv-arch.c b/clang/test/Driver/riscv-arch.c
index 92a6a59cba2317c..4896c0184507dd4 100644
--- a/clang/test/Driver/riscv-arch.c
+++ b/clang/test/Driver/riscv-arch.c
@@ -385,9 +385,9 @@
 // RUN: not %clang --target=riscv32-unknown-elf -march=rv32izfa0p1 
-menable-experimental-extensions -### %s \
 // RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-EXPERIMENTAL-BADVERS 
%s
 // RV32-EXPERIMENTAL-BADVERS: error: invalid arch name 'rv32izfa0p1'
-// RV32-EXPERIMENTAL-BADVERS: unsupported version number 0.1 for experimental 
extension 'zfa' (this compiler supports 0.2)
+// RV32-EXPERIMENTAL-BADVERS: unsupported version number 0.1 for experimental 
extension 'zfa' (this compiler supports 1.0)
 
-// RUN: %clang --target=riscv32-unknown-elf -march=rv32izfa0p2 
-menable-experimental-extensions -### %s \
+// RUN: %clang --target=riscv32-unknown-elf -march=rv32izfa1p0 
-menable-experimental-extensions -### %s \
 // RUN: -fsyntax-only 2>&1 | FileCheck 
-check-prefix=RV32-EXPERIMENTAL-GOODVERS %s
 // RV32-EXPERIMENTAL-GOODVERS: "-target-feature" "+experimental-zfa"
 
diff --git a/clang/test/Preprocessor/riscv-target-features.c 
b/clang/test/Preprocessor/riscv-target-features.c
index 4dd83cfa0620b90..4b9ec423200017f 100644
--- a/clang/test/Preprocessor/riscv-target-features.c
+++ b/clang/test/Preprocessor/riscv-target-features.c
@@ -1002,12 +1002,12 @@
 // CHECK-ZACAS-EXT: __riscv_zacas 100{{$}}
 
 // RUN: %clang --target=riscv32-unknown-linux-gnu 
-menable-experimental-extensions \
-// RUN: -march=rv32izfa0p2 -x c -E -dM %s \
+// RUN: -march=rv32izfa1p0 -x c -E -dM %s \
 // RUN: -o - | FileCheck --check-prefix=CHECK-ZFA-EXT %s
 // RUN: %clang --target=riscv64-unknown-linux-gnu 
-menable-experimental-extensions \
-// RUN: -march=rv64izfa0p2 -x c -E -dM %s \
+// RUN: -march=rv64izfa1p0 -x c -E -dM %s \
 // RUN: -o - | FileCheck --check-prefix=CHECK-ZFA-EXT %s
-// CHECK-ZFA-EXT: __riscv_zfa 2000{{$}}
+// CHECK-ZFA-EXT: __riscv_zfa 100{{$}}
 
 // RUN: %clang --target=riscv32 -menable-experimental-extensions \
 // RUN: -march=rv32izfbfmin0p8 -x c -E -dM %s \
diff --git a/llvm/docs/RISCVUsage.rst b/llvm/docs/RISCVUsage.rst
index 8d12d58738c609a..647c4c49500c161 100644
--- a/llvm/docs/RISCVUsage.rst
+++ b/llvm/docs/RISCVUsage.rst
@@ -197,7 +197,7 @@ The primary goal of experimental support is to assist in 
the process of ratifica
   LLVM implements the `1.0-rc1 draft specification 
`_.
 
 ``experimental-zfa``
-  LLVM implements the `0.2 draft specification 
`__.
+  LLVM implements the `1.0 specification 


[clang] [RISCV] Mark the Zfa extension as non-experimental (PR #68113)

2023-10-03 Thread Alex Bradbury via cfe-commits

https://github.com/asb edited https://github.com/llvm/llvm-project/pull/68113
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [RISCV] Mark the Zfa extension as non-experimental (PR #68113)

2023-10-03 Thread Alex Bradbury via cfe-commits

asb wrote:

> Please update the header comment at the top of RISCVInstrInfoZfa.td

Thanks, split that change between #67964 and this one.

https://github.com/llvm/llvm-project/pull/68113
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [RISCV] Update Zfa extension version to 1.0 (PR #67964)

2023-10-03 Thread Alex Bradbury via cfe-commits

https://github.com/asb closed https://github.com/llvm/llvm-project/pull/67964
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [RISCV] Mark the Zfa extension as non-experimental (PR #68113)

2023-10-03 Thread Alex Bradbury via cfe-commits

https://github.com/asb updated https://github.com/llvm/llvm-project/pull/68113

>From 54783e0af749e95be28c47604e411236cca0efcc Mon Sep 17 00:00:00 2001
From: Alex Bradbury 
Date: Tue, 3 Oct 2023 15:46:28 +0100
Subject: [PATCH 1/2] [RISCV] Mark the Zfa extension as non-experimental

Following the version bump in #67964 and the bug fix in #68026 I believe
we're ready to mark Zfa as non-experimental. For what it's worth, the
GCC torture suite passes now (though it's more of a litmus test than
anything else).
---
 clang/test/Driver/riscv-arch.c | 18 +-
 .../test/Preprocessor/riscv-target-features.c  |  8 
 llvm/docs/RISCVUsage.rst   |  4 +---
 llvm/docs/ReleaseNotes.rst |  2 +-
 llvm/lib/Support/RISCVISAInfo.cpp  |  2 +-
 llvm/lib/Target/RISCV/RISCVFeatures.td |  2 +-
 llvm/test/CodeGen/RISCV/attributes.ll  |  4 ++--
 llvm/test/CodeGen/RISCV/double-zfa.ll  |  4 ++--
 llvm/test/CodeGen/RISCV/fli-licm.ll|  4 ++--
 llvm/test/CodeGen/RISCV/float-zfa.ll   |  4 ++--
 llvm/test/CodeGen/RISCV/half-zfa-fli.ll|  8 
 llvm/test/CodeGen/RISCV/half-zfa.ll|  4 ++--
 llvm/test/CodeGen/RISCV/rvv/vsplats-zfa.ll |  4 ++--
 llvm/test/MC/RISCV/rv32zfa-only-valid.s|  6 +++---
 llvm/test/MC/RISCV/zfa-double-invalid.s|  4 ++--
 llvm/test/MC/RISCV/zfa-half-invalid.s  |  4 ++--
 llvm/test/MC/RISCV/zfa-invalid.s   |  4 ++--
 llvm/test/MC/RISCV/zfa-valid.s | 12 ++--
 llvm/test/MC/RISCV/zfa-zfhmin-zvfh-valid.s | 12 ++--
 llvm/unittests/Support/RISCVISAInfoTest.cpp|  2 +-
 20 files changed, 55 insertions(+), 57 deletions(-)

diff --git a/clang/test/Driver/riscv-arch.c b/clang/test/Driver/riscv-arch.c
index 4896c0184507dd4..0ac81ea982f1b61 100644
--- a/clang/test/Driver/riscv-arch.c
+++ b/clang/test/Driver/riscv-arch.c
@@ -372,24 +372,24 @@
 // RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-ZFHMIN %s
 // RV32-ZFHMIN: "-target-feature" "+zfhmin"
 
-// RUN: not %clang --target=riscv32-unknown-elf -march=rv32izfa -### %s \
+// RUN: not %clang --target=riscv32-unknown-elf -march=rv32iztso -### %s \
 // RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-EXPERIMENTAL-NOFLAG 
%s
-// RV32-EXPERIMENTAL-NOFLAG: error: invalid arch name 'rv32izfa'
+// RV32-EXPERIMENTAL-NOFLAG: error: invalid arch name 'rv32iztso'
 // RV32-EXPERIMENTAL-NOFLAG: requires '-menable-experimental-extensions'
 
-// RUN: not %clang --target=riscv32-unknown-elf -march=rv32izfa 
-menable-experimental-extensions -### %s \
+// RUN: not %clang --target=riscv32-unknown-elf -march=rv32iztso 
-menable-experimental-extensions -### %s \
 // RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-EXPERIMENTAL-NOVERS 
%s
-// RV32-EXPERIMENTAL-NOVERS: error: invalid arch name 'rv32izfa'
+// RV32-EXPERIMENTAL-NOVERS: error: invalid arch name 'rv32iztso'
 // RV32-EXPERIMENTAL-NOVERS: experimental extension requires explicit version 
number
 
-// RUN: not %clang --target=riscv32-unknown-elf -march=rv32izfa0p1 
-menable-experimental-extensions -### %s \
+// RUN: not %clang --target=riscv32-unknown-elf -march=rv32iztso0p7 
-menable-experimental-extensions -### %s \
 // RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-EXPERIMENTAL-BADVERS 
%s
-// RV32-EXPERIMENTAL-BADVERS: error: invalid arch name 'rv32izfa0p1'
-// RV32-EXPERIMENTAL-BADVERS: unsupported version number 0.1 for experimental 
extension 'zfa' (this compiler supports 1.0)
+// RV32-EXPERIMENTAL-BADVERS: error: invalid arch name 'rv32iztso0p7'
+// RV32-EXPERIMENTAL-BADVERS: unsupported version number 0.7 for experimental 
extension 'ztso' (this compiler supports 0.1)
 
-// RUN: %clang --target=riscv32-unknown-elf -march=rv32izfa1p0 
-menable-experimental-extensions -### %s \
+// RUN: %clang --target=riscv32-unknown-elf -march=rv32iztso0p1 
-menable-experimental-extensions -### %s \
 // RUN: -fsyntax-only 2>&1 | FileCheck 
-check-prefix=RV32-EXPERIMENTAL-GOODVERS %s
-// RV32-EXPERIMENTAL-GOODVERS: "-target-feature" "+experimental-zfa"
+// RV32-EXPERIMENTAL-GOODVERS: "-target-feature" "+experimental-ztso"
 
 // RUN: %clang --target=riscv32-unknown-elf -march=rv32izbb1p0 -### %s \
 // RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-ZBB %s
diff --git a/clang/test/Preprocessor/riscv-target-features.c 
b/clang/test/Preprocessor/riscv-target-features.c
index 4b9ec423200017f..242197e3f129a3f 100644
--- a/clang/test/Preprocessor/riscv-target-features.c
+++ b/clang/test/Preprocessor/riscv-target-features.c
@@ -1001,11 +1001,11 @@
 // RUN: -o - | FileCheck --check-prefix=CHECK-ZACAS-EXT %s
 // CHECK-ZACAS-EXT: __riscv_zacas 100{{$}}
 
-// RUN: %clang --target=riscv32-unknown-linux-gnu 
-menable-experimental-extensions \
-// RUN: -march=rv32izfa1p0 -x c -E -dM %s \
+// RUN: %clang --target=riscv32-unknown-linux-gnu \
+// RUN: -march=rv32izfa -x c -E -dM %s \
 // RUN: -o - | File

[clang] [RISCV] Mark the Zfa extension as non-experimental (PR #68113)

2023-10-03 Thread Alex Bradbury via cfe-commits

https://github.com/asb closed https://github.com/llvm/llvm-project/pull/68113
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang-repl] Disable InterpreterExceptionTest on RISC-V (PR #68216)

2023-10-04 Thread Alex Bradbury via cfe-commits

https://github.com/asb created https://github.com/llvm/llvm-project/pull/68216

This test fails as .eh_frame handling is not yet implemented for RISC-V in 
JITLink. #66067 is proposed to address this.

Skip the test until the issue is resolved. It seems that D159167 enabled this 
test for more than just ppc64. As the test always failed, it just wasn't run 
until now, I think skipping is the correct interim approach (as is already done 
for Arm, Darwin, and others).

>From 6436cffbe1d4767155724b1c28acd8b47bb6be88 Mon Sep 17 00:00:00 2001
From: Alex Bradbury 
Date: Wed, 4 Oct 2023 13:51:20 +0100
Subject: [PATCH] [clang-repl] Disable InterpreterExceptionTest on RISC-V

This test fails as .eh_frame handling is not yet implemented for RISC-V
in JITLink. #66067 is proposed to address this.

Skip the test until the issue is resolved. It seems that D159167
enabled this test for more than just ppc64.
---
 .../Interpreter/ExceptionTests/InterpreterExceptionTest.cpp  | 5 +
 1 file changed, 5 insertions(+)

diff --git 
a/clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp 
b/clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp
index 2f1c4efb381f00b..7b47d93446192ba 100644
--- a/clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp
+++ b/clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp
@@ -122,6 +122,11 @@ extern "C" int throw_exception() {
   Triple.getArch() == llvm::Triple::aarch64_32))
 GTEST_SKIP();
 
+  // FIXME: RISC-V fails as .eh_frame handling is not yet implemented in
+  // JITLink for RISC-V. See PR #66067.
+  if (Triple.isRISCV())
+GTEST_SKIP();
+
   llvm::cantFail(Interp->ParseAndExecute(ExceptionCode));
   testing::internal::CaptureStdout();
   auto ThrowException =

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang-repl] Disable InterpreterExceptionTest on RISC-V (PR #68216)

2023-10-04 Thread Alex Bradbury via cfe-commits

https://github.com/asb closed https://github.com/llvm/llvm-project/pull/68216
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 17a58b3 - [clang][RISCV] Fix ABI handling of empty structs with hard FP calling conventions in C++

2023-07-24 Thread Alex Bradbury via cfe-commits

Author: Alex Bradbury
Date: 2023-07-24T10:24:34+01:00
New Revision: 17a58b3ca7ec18585e9ea8ed8b39d72fe36fb6cb

URL: 
https://github.com/llvm/llvm-project/commit/17a58b3ca7ec18585e9ea8ed8b39d72fe36fb6cb
DIFF: 
https://github.com/llvm/llvm-project/commit/17a58b3ca7ec18585e9ea8ed8b39d72fe36fb6cb.diff

LOG: [clang][RISCV] Fix ABI handling of empty structs with hard FP calling 
conventions in C++

As reported in ,
Clang's handling of empty structs in the case of small structs that may
be eligible to be passed using the hard FP calling convention doesn't
match g++. In general, C++ record fields are never empty unless
[[no_unique_address]] is used, but the RISC-V FP ABI overrides this.

After this patch, fields of structs that contain empty records will be
ignored, even in C++, when considering eligibility for the FP calling
convention ('flattening'). See also the relevant psABI issue
 which
seeks to clarify the documentation.

Fixes https://github.com/llvm/llvm-project/issues/58929

Differential Revision: https://reviews.llvm.org/D142327

Added: 


Modified: 
clang/docs/ReleaseNotes.rst
clang/lib/CodeGen/ABIInfoImpl.cpp
clang/lib/CodeGen/ABIInfoImpl.h
clang/lib/CodeGen/Targets/RISCV.cpp
clang/test/CodeGen/RISCV/abi-empty-structs.c

Removed: 




diff  --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index db9149fae797c4..1df474d2672720 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -899,6 +899,9 @@ RISC-V Support
 - The rules for ordering of extensions in ``-march`` strings were relaxed. A
   canonical ordering is no longer enforced on ``z*``, ``s*``, and ``x*``
   prefixed extensions.
+* An ABI mismatch between GCC and Clang related to the handling of empty
+  structs in C++ parameter passing under the hard floating point calling
+  conventions was fixed.
 
 CUDA/HIP Language Changes
 ^

diff  --git a/clang/lib/CodeGen/ABIInfoImpl.cpp 
b/clang/lib/CodeGen/ABIInfoImpl.cpp
index 7c30cecfdb9b77..2b20d5a13346d3 100644
--- a/clang/lib/CodeGen/ABIInfoImpl.cpp
+++ b/clang/lib/CodeGen/ABIInfoImpl.cpp
@@ -246,7 +246,7 @@ Address CodeGen::emitMergePHI(CodeGenFunction &CGF, Address 
Addr1,
 }
 
 bool CodeGen::isEmptyField(ASTContext &Context, const FieldDecl *FD,
-   bool AllowArrays) {
+   bool AllowArrays, bool AsIfNoUniqueAddr) {
   if (FD->isUnnamedBitfield())
 return true;
 
@@ -280,13 +280,14 @@ bool CodeGen::isEmptyField(ASTContext &Context, const 
FieldDecl *FD,
   // not arrays of records, so we must also check whether we stripped off an
   // array type above.
   if (isa(RT->getDecl()) &&
-  (WasArray || !FD->hasAttr()))
+  (WasArray || (!AsIfNoUniqueAddr && !FD->hasAttr(
 return false;
 
-  return isEmptyRecord(Context, FT, AllowArrays);
+  return isEmptyRecord(Context, FT, AllowArrays, AsIfNoUniqueAddr);
 }
 
-bool CodeGen::isEmptyRecord(ASTContext &Context, QualType T, bool AllowArrays) 
{
+bool CodeGen::isEmptyRecord(ASTContext &Context, QualType T, bool AllowArrays,
+bool AsIfNoUniqueAddr) {
   const RecordType *RT = T->getAs();
   if (!RT)
 return false;
@@ -297,11 +298,11 @@ bool CodeGen::isEmptyRecord(ASTContext &Context, QualType 
T, bool AllowArrays) {
   // If this is a C++ record, check the bases first.
   if (const CXXRecordDecl *CXXRD = dyn_cast(RD))
 for (const auto &I : CXXRD->bases())
-  if (!isEmptyRecord(Context, I.getType(), true))
+  if (!isEmptyRecord(Context, I.getType(), true, AsIfNoUniqueAddr))
 return false;
 
   for (const auto *I : RD->fields())
-if (!isEmptyField(Context, I, AllowArrays))
+if (!isEmptyField(Context, I, AllowArrays, AsIfNoUniqueAddr))
   return false;
   return true;
 }

diff  --git a/clang/lib/CodeGen/ABIInfoImpl.h b/clang/lib/CodeGen/ABIInfoImpl.h
index 5f0cc289af68b3..afde08ba100cf0 100644
--- a/clang/lib/CodeGen/ABIInfoImpl.h
+++ b/clang/lib/CodeGen/ABIInfoImpl.h
@@ -122,13 +122,19 @@ Address emitMergePHI(CodeGenFunction &CGF, Address Addr1,
  llvm::BasicBlock *Block2, const llvm::Twine &Name = "");
 
 /// isEmptyField - Return true iff a the field is "empty", that is it
-/// is an unnamed bit-field or an (array of) empty record(s).
-bool isEmptyField(ASTContext &Context, const FieldDecl *FD, bool AllowArrays);
+/// is an unnamed bit-field or an (array of) empty record(s). If
+/// AsIfNoUniqueAddr is true, then C++ record fields are considered empty if
+/// the [[no_unique_address]] attribute would have made them empty.
+bool isEmptyField(ASTContext &Context, const FieldDecl *FD, bool AllowArrays,
+  bool AsIfNoUniqueAddr = false);
 
 /// isEmptyRecord - Return true iff a structure contains only empty
 /// fi

[clang] 569e99a - [clang][docs] Attempt to fix warning when building ReleaseNotes

2023-07-24 Thread Alex Bradbury via cfe-commits

Author: Alex Bradbury
Date: 2023-07-24T10:36:42+01:00
New Revision: 569e99a471f618b7fdf045d5e96f21d3e3a7f898

URL: 
https://github.com/llvm/llvm-project/commit/569e99a471f618b7fdf045d5e96f21d3e3a7f898
DIFF: 
https://github.com/llvm/llvm-project/commit/569e99a471f618b7fdf045d5e96f21d3e3a7f898.diff

LOG: [clang][docs] Attempt to fix warning when building ReleaseNotes

I believe my previous patch, 17a58b3ca7ec18585e9ea8ed8b39d72fe36fb6cb
introduced a warning here.

Added: 


Modified: 
clang/docs/ReleaseNotes.rst

Removed: 




diff  --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 1df474d2672720..8e19b3695ef49e 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -899,7 +899,7 @@ RISC-V Support
 - The rules for ordering of extensions in ``-march`` strings were relaxed. A
   canonical ordering is no longer enforced on ``z*``, ``s*``, and ``x*``
   prefixed extensions.
-* An ABI mismatch between GCC and Clang related to the handling of empty
+- An ABI mismatch between GCC and Clang related to the handling of empty
   structs in C++ parameter passing under the hard floating point calling
   conventions was fixed.
 



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 0fa004e - Revert "[clang][RISCV] Fix ABI handling of empty structs with hard FP calling conventions in C++"

2023-07-24 Thread Alex Bradbury via cfe-commits

Author: Alex Bradbury
Date: 2023-07-24T16:58:48+01:00
New Revision: 0fa004e0724b4398f999b8bffbc37f524e41f66e

URL: 
https://github.com/llvm/llvm-project/commit/0fa004e0724b4398f999b8bffbc37f524e41f66e
DIFF: 
https://github.com/llvm/llvm-project/commit/0fa004e0724b4398f999b8bffbc37f524e41f66e.diff

LOG: Revert "[clang][RISCV] Fix ABI handling of empty structs with hard FP 
calling conventions in C++"

This reverts commit 17a58b3ca7ec18585e9ea8ed8b39d72fe36fb6cb and the
minor documentation fix 569e99a471f618b7fdf045d5e96f21d3e3a7f898.

An issue was reported in https://reviews.llvm.org/D142327#inline-1510301
so reverting until it can be investigated and fixed.

Added: 


Modified: 
clang/docs/ReleaseNotes.rst
clang/lib/CodeGen/ABIInfoImpl.cpp
clang/lib/CodeGen/ABIInfoImpl.h
clang/lib/CodeGen/Targets/RISCV.cpp
clang/test/CodeGen/RISCV/abi-empty-structs.c

Removed: 




diff  --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 4e60efa1c025ed..520e57532467db 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -906,9 +906,6 @@ RISC-V Support
 - The rules for ordering of extensions in ``-march`` strings were relaxed. A
   canonical ordering is no longer enforced on ``z*``, ``s*``, and ``x*``
   prefixed extensions.
-- An ABI mismatch between GCC and Clang related to the handling of empty
-  structs in C++ parameter passing under the hard floating point calling
-  conventions was fixed.
 
 CUDA/HIP Language Changes
 ^

diff  --git a/clang/lib/CodeGen/ABIInfoImpl.cpp 
b/clang/lib/CodeGen/ABIInfoImpl.cpp
index 2b20d5a13346d3..7c30cecfdb9b77 100644
--- a/clang/lib/CodeGen/ABIInfoImpl.cpp
+++ b/clang/lib/CodeGen/ABIInfoImpl.cpp
@@ -246,7 +246,7 @@ Address CodeGen::emitMergePHI(CodeGenFunction &CGF, Address 
Addr1,
 }
 
 bool CodeGen::isEmptyField(ASTContext &Context, const FieldDecl *FD,
-   bool AllowArrays, bool AsIfNoUniqueAddr) {
+   bool AllowArrays) {
   if (FD->isUnnamedBitfield())
 return true;
 
@@ -280,14 +280,13 @@ bool CodeGen::isEmptyField(ASTContext &Context, const 
FieldDecl *FD,
   // not arrays of records, so we must also check whether we stripped off an
   // array type above.
   if (isa(RT->getDecl()) &&
-  (WasArray || (!AsIfNoUniqueAddr && !FD->hasAttr(
+  (WasArray || !FD->hasAttr()))
 return false;
 
-  return isEmptyRecord(Context, FT, AllowArrays, AsIfNoUniqueAddr);
+  return isEmptyRecord(Context, FT, AllowArrays);
 }
 
-bool CodeGen::isEmptyRecord(ASTContext &Context, QualType T, bool AllowArrays,
-bool AsIfNoUniqueAddr) {
+bool CodeGen::isEmptyRecord(ASTContext &Context, QualType T, bool AllowArrays) 
{
   const RecordType *RT = T->getAs();
   if (!RT)
 return false;
@@ -298,11 +297,11 @@ bool CodeGen::isEmptyRecord(ASTContext &Context, QualType 
T, bool AllowArrays,
   // If this is a C++ record, check the bases first.
   if (const CXXRecordDecl *CXXRD = dyn_cast(RD))
 for (const auto &I : CXXRD->bases())
-  if (!isEmptyRecord(Context, I.getType(), true, AsIfNoUniqueAddr))
+  if (!isEmptyRecord(Context, I.getType(), true))
 return false;
 
   for (const auto *I : RD->fields())
-if (!isEmptyField(Context, I, AllowArrays, AsIfNoUniqueAddr))
+if (!isEmptyField(Context, I, AllowArrays))
   return false;
   return true;
 }

diff  --git a/clang/lib/CodeGen/ABIInfoImpl.h b/clang/lib/CodeGen/ABIInfoImpl.h
index afde08ba100cf0..5f0cc289af68b3 100644
--- a/clang/lib/CodeGen/ABIInfoImpl.h
+++ b/clang/lib/CodeGen/ABIInfoImpl.h
@@ -122,19 +122,13 @@ Address emitMergePHI(CodeGenFunction &CGF, Address Addr1,
  llvm::BasicBlock *Block2, const llvm::Twine &Name = "");
 
 /// isEmptyField - Return true iff a the field is "empty", that is it
-/// is an unnamed bit-field or an (array of) empty record(s). If
-/// AsIfNoUniqueAddr is true, then C++ record fields are considered empty if
-/// the [[no_unique_address]] attribute would have made them empty.
-bool isEmptyField(ASTContext &Context, const FieldDecl *FD, bool AllowArrays,
-  bool AsIfNoUniqueAddr = false);
+/// is an unnamed bit-field or an (array of) empty record(s).
+bool isEmptyField(ASTContext &Context, const FieldDecl *FD, bool AllowArrays);
 
 /// isEmptyRecord - Return true iff a structure contains only empty
 /// fields. Note that a structure with a flexible array member is not
-/// considered empty. If AsIfNoUniqueAddr is true, then C++ record fields are
-/// considered empty if the [[no_unique_address]] attribute would have made
-/// them empty.
-bool isEmptyRecord(ASTContext &Context, QualType T, bool AllowArrays,
-   bool AsIfNoUniqueAddr = false);
+/// considered empty.
+bool isEmptyRecord(ASTContext &Context, QualType T, bool AllowArrays);
 
 /// isSingleElementStruct - Determine if 

[clang] Remove experimental from Vector Crypto extensions (PR #69000)

2023-10-13 Thread Alex Bradbury via cfe-commits

asb wrote:

Thanks for the patch, some very quick feedback and I'd highlight the first 
bullet as the most important, as this is potentially a blocker for graduating 
these extensions from experimental.

* My big concern with this would be the intrinsics - could you please comment 
on the status of their standardisation?
* While doing this change, it would make sense to update the header of 
RISCVInstrInfoZvk.td. While it doesn't explicitly say it describes an 
experimental version of the extension, it references 1.0.0-rc1 of the spec 
while presumably there's now a 1.0.0-final?
* Please update llvm/docs/RISCVUsage.rst
* Please add a release note to llvm/docs/ReleaseNotes.rst

https://github.com/llvm/llvm-project/pull/69000
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] e3c57fd - [clang][RISCV] Fix bug in ABI handling of empty structs with hard FP calling conventions in C++

2023-08-07 Thread Alex Bradbury via cfe-commits

Author: Alex Bradbury
Date: 2023-08-07T10:45:22+01:00
New Revision: e3c57fdd8439ba82c67347629a3c66f293e1f3d0

URL: 
https://github.com/llvm/llvm-project/commit/e3c57fdd8439ba82c67347629a3c66f293e1f3d0
DIFF: 
https://github.com/llvm/llvm-project/commit/e3c57fdd8439ba82c67347629a3c66f293e1f3d0.diff

LOG: [clang][RISCV] Fix bug in ABI handling of empty structs with hard FP 
calling conventions in C++

As reported in ,
Clang's handling of empty structs in the case of small structs that may
be eligible to be passed using the hard FP calling convention doesn't
match g++. In general, C++ record fields are never empty unless
[[no_unique_address]] is used, but the RISC-V FP ABI overrides this.

After this patch, fields of structs that contain empty records will be
ignored, even in C++, when considering eligibility for the FP calling
convention ('flattening'). It isn't explicitly noted in the RISC-V
psABI, but arrays of empty records will disqualify a struct for
consideration of using the FP calling convention in g++. This patch
matches that behaviour. The psABI issue
 seeks
to clarify this.

This patch was previously committed but reverted after a bug was found.
This recommit adds additional logic to prevent that bug (adding an extra
check for when a candidate from detectFPCCEligibleStructHelper may not
be valid).

Differential Revision: https://reviews.llvm.org/D142327

Added: 


Modified: 
clang/docs/ReleaseNotes.rst
clang/lib/CodeGen/ABIInfoImpl.cpp
clang/lib/CodeGen/ABIInfoImpl.h
clang/lib/CodeGen/Targets/RISCV.cpp
clang/test/CodeGen/RISCV/abi-empty-structs.c

Removed: 




diff  --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index f03e5231215eb2..4d1ca7afad1f10 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -196,6 +196,9 @@ RISC-V Support
 ^^
 - Unaligned memory accesses can be toggled by ``-m[no-]unaligned-access`` or 
the
   aliases ``-m[no-]strict-align``.
+- An ABI mismatch between GCC and Clang related to the handling of empty
+  structs in C++ parameter passing under the hard floating point calling
+  conventions was fixed.
 
 CUDA/HIP Language Changes
 ^

diff  --git a/clang/lib/CodeGen/ABIInfoImpl.cpp 
b/clang/lib/CodeGen/ABIInfoImpl.cpp
index 7c30cecfdb9b77..2b20d5a13346d3 100644
--- a/clang/lib/CodeGen/ABIInfoImpl.cpp
+++ b/clang/lib/CodeGen/ABIInfoImpl.cpp
@@ -246,7 +246,7 @@ Address CodeGen::emitMergePHI(CodeGenFunction &CGF, Address 
Addr1,
 }
 
 bool CodeGen::isEmptyField(ASTContext &Context, const FieldDecl *FD,
-   bool AllowArrays) {
+   bool AllowArrays, bool AsIfNoUniqueAddr) {
   if (FD->isUnnamedBitfield())
 return true;
 
@@ -280,13 +280,14 @@ bool CodeGen::isEmptyField(ASTContext &Context, const 
FieldDecl *FD,
   // not arrays of records, so we must also check whether we stripped off an
   // array type above.
   if (isa(RT->getDecl()) &&
-  (WasArray || !FD->hasAttr()))
+  (WasArray || (!AsIfNoUniqueAddr && !FD->hasAttr(
 return false;
 
-  return isEmptyRecord(Context, FT, AllowArrays);
+  return isEmptyRecord(Context, FT, AllowArrays, AsIfNoUniqueAddr);
 }
 
-bool CodeGen::isEmptyRecord(ASTContext &Context, QualType T, bool AllowArrays) 
{
+bool CodeGen::isEmptyRecord(ASTContext &Context, QualType T, bool AllowArrays,
+bool AsIfNoUniqueAddr) {
   const RecordType *RT = T->getAs();
   if (!RT)
 return false;
@@ -297,11 +298,11 @@ bool CodeGen::isEmptyRecord(ASTContext &Context, QualType 
T, bool AllowArrays) {
   // If this is a C++ record, check the bases first.
   if (const CXXRecordDecl *CXXRD = dyn_cast(RD))
 for (const auto &I : CXXRD->bases())
-  if (!isEmptyRecord(Context, I.getType(), true))
+  if (!isEmptyRecord(Context, I.getType(), true, AsIfNoUniqueAddr))
 return false;
 
   for (const auto *I : RD->fields())
-if (!isEmptyField(Context, I, AllowArrays))
+if (!isEmptyField(Context, I, AllowArrays, AsIfNoUniqueAddr))
   return false;
   return true;
 }

diff  --git a/clang/lib/CodeGen/ABIInfoImpl.h b/clang/lib/CodeGen/ABIInfoImpl.h
index 5f0cc289af68b3..afde08ba100cf0 100644
--- a/clang/lib/CodeGen/ABIInfoImpl.h
+++ b/clang/lib/CodeGen/ABIInfoImpl.h
@@ -122,13 +122,19 @@ Address emitMergePHI(CodeGenFunction &CGF, Address Addr1,
  llvm::BasicBlock *Block2, const llvm::Twine &Name = "");
 
 /// isEmptyField - Return true iff a the field is "empty", that is it
-/// is an unnamed bit-field or an (array of) empty record(s).
-bool isEmptyField(ASTContext &Context, const FieldDecl *FD, bool AllowArrays);
+/// is an unnamed bit-field or an (array of) empty record(s). If
+/// AsIfNoUniqueAddr is true, then C++ record fields are c

[clang] ac2af81 - [clang][doc][RISCV][LoongArch] Remove release notes for changes backported to 17.0.x

2023-08-10 Thread Alex Bradbury via cfe-commits

Author: Alex Bradbury
Date: 2023-08-10T08:14:38+01:00
New Revision: ac2af811a0b864df0089b454b61d484bfc1ad108

URL: 
https://github.com/llvm/llvm-project/commit/ac2af811a0b864df0089b454b61d484bfc1ad108
DIFF: 
https://github.com/llvm/llvm-project/commit/ac2af811a0b864df0089b454b61d484bfc1ad108.diff

LOG: [clang][doc][RISCV][LoongArch] Remove release notes for changes backported 
to 17.0.x

The RISC-V and LoongArch ABI fixes were backported to 17.0.x
(,
) and so are now
covered in the release notes for 17.0.0.

Added: 


Modified: 
clang/docs/ReleaseNotes.rst

Removed: 




diff  --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 92abb65546caa3..e8533f071e0754 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -200,16 +200,10 @@ Windows Support
 LoongArch Support
 ^
 
-- An ABI mismatch between GCC and Clang related to the handling of empty 
structs
-  in C++ parameter passing under ``lp64d`` ABI was fixed.
-
 RISC-V Support
 ^^
 - Unaligned memory accesses can be toggled by ``-m[no-]unaligned-access`` or 
the
   aliases ``-m[no-]strict-align``.
-- An ABI mismatch between GCC and Clang related to the handling of empty
-  structs in C++ parameter passing under the hard floating point calling
-  conventions was fixed.
 
 CUDA/HIP Language Changes
 ^



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 29f630a - [RISCV][MC] MC layer support for the experimental zacas extension

2023-07-10 Thread Alex Bradbury via cfe-commits

Author: Alex Bradbury
Date: 2023-07-10T08:26:31+01:00
New Revision: 29f630a1ddcbb03caa31b5002f0cbc105ff3a869

URL: 
https://github.com/llvm/llvm-project/commit/29f630a1ddcbb03caa31b5002f0cbc105ff3a869
DIFF: 
https://github.com/llvm/llvm-project/commit/29f630a1ddcbb03caa31b5002f0cbc105ff3a869.diff

LOG: [RISCV][MC] MC layer support for the experimental zacas extension

This implements the v1.0-rc1 draft extension.

amocas.d on RV32 and amocas.q have the restriction that rd and rs2 must
be even registers. I've opted to implement this restriction in
RISCVAsmParser::validateInstruction even though for codegen we'll need a
new register class and can then remove this validation. This also
sidesteps, for now, the issue of amocas.d being different on rv32 vs
rv64.

See  for the
issue of needing an agreed asm register constraint for register pairs.

Differential Revision: https://reviews.llvm.org/D149248

Added: 
llvm/test/MC/RISCV/rv32zacas-invalid.s
llvm/test/MC/RISCV/rv32zacas-valid.s
llvm/test/MC/RISCV/rv64zacas-invalid.s
llvm/test/MC/RISCV/rv64zacas-valid.s

Modified: 
clang/test/Preprocessor/riscv-target-features.c
llvm/docs/RISCVUsage.rst
llvm/docs/ReleaseNotes.rst
llvm/lib/Support/RISCVISAInfo.cpp
llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
llvm/lib/Target/RISCV/RISCVFeatures.td
llvm/lib/Target/RISCV/RISCVInstrInfoA.td
llvm/test/CodeGen/RISCV/attributes.ll
llvm/test/MC/RISCV/attribute-arch.s

Removed: 




diff  --git a/clang/test/Preprocessor/riscv-target-features.c 
b/clang/test/Preprocessor/riscv-target-features.c
index 9de44408b74f5c..27c089494de177 100644
--- a/clang/test/Preprocessor/riscv-target-features.c
+++ b/clang/test/Preprocessor/riscv-target-features.c
@@ -72,6 +72,7 @@
 // CHECK-NOT: __riscv_zfbfmin {{.*$}}
 // CHECK-NOT: __riscv_zvfbfmin {{.*$}}
 // CHECK-NOT: __riscv_zvfbfwma {{.*$}}
+// CHECK-NOT: __riscv_zacas {{.*$}}
 
 // RUN: %clang -target riscv32-unknown-linux-gnu -march=rv32i -x c -E -dM %s \
 // RUN: -o - | FileCheck %s
@@ -771,3 +772,11 @@
 // RUN: | FileCheck --check-prefix=CHECK-COMBINE-INTO-ZVKSG %s
 // CHECK-COMBINE-INTO-ZVKSG: __riscv_zvks 100{{$}}
 // CHECK-COMBINE-INTO-ZVKSG: __riscv_zvksg 100{{$}}
+
+// RUN: %clang -target riscv32 -menable-experimental-extensions \
+// RUN: -march=rv32i_zacas1p0 -x c -E -dM %s \
+// RUN: -o - | FileCheck --check-prefix=CHECK-ZACAS-EXT %s
+// RUN: %clang -target riscv64 -menable-experimental-extensions \
+// RUN: -march=rv64i_zacas1p0 -x c -E -dM %s \
+// RUN: -o - | FileCheck --check-prefix=CHECK-ZACAS-EXT %s
+// CHECK-ZACAS-EXT: __riscv_zacas 100{{$}}

diff  --git a/llvm/docs/RISCVUsage.rst b/llvm/docs/RISCVUsage.rst
index 2f1942d75058ac..be71a9e028acd7 100644
--- a/llvm/docs/RISCVUsage.rst
+++ b/llvm/docs/RISCVUsage.rst
@@ -191,6 +191,9 @@ The primary goal of experimental support is to assist in 
the process of ratifica
 ``experimental-ssaia``
   LLVM implements the `Ratification candidate 3 
`_.
 
+``experimental-zacas``
+  LLVM implements the `1.0-rc1 draft specification 
`_.
+
 ``experimental-zfa``
   LLVM implements the `0.2 draft specification 
`__.
 

diff  --git a/llvm/docs/ReleaseNotes.rst b/llvm/docs/ReleaseNotes.rst
index 4016e1badcbcc6..606adc92f910d6 100644
--- a/llvm/docs/ReleaseNotes.rst
+++ b/llvm/docs/ReleaseNotes.rst
@@ -253,6 +253,8 @@ Changes to the RISC-V Backend
 * Assembly support was added for the experimental Zfbfmin (scalar BF16
   conversions), Zvfbfmin (vector BF16 conversions), and Zvfbfwma (vector BF16
   widening mul-add) extensions.
+* Added assembler/disassembler support for the experimental Zacas (atomic
+  compare-and-swap) extension.
 
 Changes to the WebAssembly Backend
 --

diff  --git a/llvm/lib/Support/RISCVISAInfo.cpp 
b/llvm/lib/Support/RISCVISAInfo.cpp
index 720ed06ecf7f65..3cd1ff4c02e3f4 100644
--- a/llvm/lib/Support/RISCVISAInfo.cpp
+++ b/llvm/lib/Support/RISCVISAInfo.cpp
@@ -153,6 +153,8 @@ static const RISCVSupportedExtension 
SupportedExperimentalExtensions[] = {
 {"smaia", RISCVExtensionVersion{1, 0}},
 {"ssaia", RISCVExtensionVersion{1, 0}},
 
+{"zacas", RISCVExtensionVersion{1, 0}},
+
 {"zfa", RISCVExtensionVersion{0, 2}},
 {"zfbfmin", RISCVExtensionVersion{0, 6}},
 
@@ -944,6 +946,7 @@ static const char *ImpliedExtsF[] = {"zicsr"};
 static const char *ImpliedExtsV[] = {"zvl128b", "zve64d"};
 static const char *ImpliedExtsXTHeadVdot[] = {"v"};
 static const char *ImpliedExtsXsfvcp[] = {"zve32x"};
+static const char *ImpliedExtsZacas[] = {"a"};
 static const char *ImpliedExtsZcb[] = {"zca"};
 static const char *I

[clang] f47404b - [clang][docs] Clarify the semantics of -fexceptions

2023-03-14 Thread Alex Bradbury via cfe-commits

Author: Alex Bradbury
Date: 2023-03-14T19:52:32Z
New Revision: f47404b012d66ed0b411a2b3742931a14e85c80b

URL: 
https://github.com/llvm/llvm-project/commit/f47404b012d66ed0b411a2b3742931a14e85c80b
DIFF: 
https://github.com/llvm/llvm-project/commit/f47404b012d66ed0b411a2b3742931a14e85c80b.diff

LOG: [clang][docs] Clarify the semantics of -fexceptions

As noted in , the
documentation for -fexceptions appears to imply that unwind information
is always generated, which isn't the case.

Differential Revision: https://reviews.llvm.org/D145564

Added: 


Modified: 
clang/docs/CommandGuide/clang.rst

Removed: 




diff  --git a/clang/docs/CommandGuide/clang.rst 
b/clang/docs/CommandGuide/clang.rst
index 7fae1b5cec53c..e076818697eb1 100644
--- a/clang/docs/CommandGuide/clang.rst
+++ b/clang/docs/CommandGuide/clang.rst
@@ -473,8 +473,10 @@ Code Generation Options
 
 .. option:: -fexceptions
 
-  Enable generation of unwind information. This allows exceptions to be thrown
-  through Clang compiled stack frames.  This is on by default in x86-64.
+  Allow exceptions to be thrown through Clang compiled stack frames (on many
+  targets, this will enable unwind information for functions that might have
+  an exception thrown through them). For most targets, this is enabled by
+  default for C++.
 
 .. option:: -ftrapv
 



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] a7e13d6 - [clang][RISCV][test] Add test coverage for _Float16 ABI lowering

2023-03-15 Thread Alex Bradbury via cfe-commits

Author: Alex Bradbury
Date: 2023-03-15T18:00:39Z
New Revision: a7e13d6f1b49d72b59e9ec2252399eda717ea8f6

URL: 
https://github.com/llvm/llvm-project/commit/a7e13d6f1b49d72b59e9ec2252399eda717ea8f6
DIFF: 
https://github.com/llvm/llvm-project/commit/a7e13d6f1b49d72b59e9ec2252399eda717ea8f6.diff

LOG: [clang][RISCV][test] Add test coverage for _Float16 ABI lowering

By the psABI, any test case where a FPR would be used for a float, it
should also be used if you replaced that float with a _Float16. This
doesn't hold true in current Clang for the special cases in the FP
calling convention involving structs. This patch doesn't attempt to fix
that, simply to add coverage. D145074 contains the fix.

Differential Revision: https://reviews.llvm.org/D145070

Added: 


Modified: 
clang/test/CodeGen/RISCV/riscv32-abi.c
clang/test/CodeGen/RISCV/riscv64-abi.c

Removed: 




diff  --git a/clang/test/CodeGen/RISCV/riscv32-abi.c 
b/clang/test/CodeGen/RISCV/riscv32-abi.c
index c00365d89c42..5cabbf4d90a1 100644
--- a/clang/test/CodeGen/RISCV/riscv32-abi.c
+++ b/clang/test/CodeGen/RISCV/riscv32-abi.c
@@ -70,6 +70,12 @@ double f_fp_scalar_2(double x) { return x; }
 //
 long double f_fp_scalar_3(long double x) { return x; }
 
+// ILP32-ILP32F-ILP32D-LABEL: define dso_local half @f_fp_scalar_4
+// ILP32-ILP32F-ILP32D-SAME: (half noundef [[X:%.*]]) #[[ATTR0]] {
+// ILP32-ILP32F-ILP32D:  entry:
+//
+_Float16 f_fp_scalar_4(_Float16 x) { return x; }
+
 // Empty structs or unions are ignored.
 
 struct empty_s {};
@@ -314,11 +320,11 @@ void f_scalar_stack_4(double a, int64_t b, double c, 
int64_t d, int e,
   int64_t f, float g, double h, long double i) {}
 
 // ILP32-ILP32F-ILP32D-LABEL: define dso_local i32 @f_scalar_stack_5
-// ILP32-ILP32F-ILP32D-SAME: (i32 noundef [[A:%.*]], i64 noundef [[B:%.*]], 
float noundef [[C:%.*]], double noundef [[D:%.*]], fp128 noundef [[E:%.*]], i8 
noundef zeroext [[F:%.*]], i8 noundef signext [[G:%.*]], i8 noundef zeroext 
[[H:%.*]]) #[[ATTR0]] {
+// ILP32-ILP32F-ILP32D-SAME: (i32 noundef [[A:%.*]], i64 noundef [[B:%.*]], 
float noundef [[C:%.*]], double noundef [[D:%.*]], fp128 noundef [[E:%.*]], i8 
noundef zeroext [[F:%.*]], i8 noundef signext [[G:%.*]], i8 noundef zeroext 
[[H:%.*]], half noundef [[I:%.*]]) #[[ATTR0]] {
 // ILP32-ILP32F-ILP32D:  entry:
 //
 int f_scalar_stack_5(int32_t a, int64_t b, float c, double d, long double e,
- uint8_t f, int8_t g, uint8_t h) {
+ uint8_t f, int8_t g, uint8_t h, _Float16 i) {
   return g + h;
 }
 
@@ -1520,5 +1526,425 @@ void f_float_u_arg(union float_u a) {}
 union float_u f_ret_float_u(void) {
   return (union float_u){1.0};
 }
+
+// Check that fp, fp+fp, and int+fp structs are lowered correctly. These will
+// be passed in FPR, FPR+FPR, or GPR+FPR regs if sufficient registers are
+// available the widths are <= XLEN and FLEN, and should be expanded to
+// separate arguments in IR. They are passed by the same rules for returns,
+// but will be lowered to simple two-element structs if necessary (as LLVM IR
+// functions cannot return multiple values).
+// FIXME: Essentially all test cases below involving _Float16 in structs
+// aren't lowered according to the rules in the FP calling convention (i.e.
+// are incorrect for ilp32f/ilp32d).
+
+struct float16_s { _Float16 f; };
+
+// A struct containing just one floating-point real is passed as though it
+// were a standalone floating-point real.
+
+// ILP32-ILP32F-ILP32D-LABEL: define dso_local void @f_float16_s_arg
+// ILP32-ILP32F-ILP32D-SAME: (i32 [[A_COERCE:%.*]]) #[[ATTR0]] {
+// ILP32-ILP32F-ILP32D:  entry:
+//
+void f_float16_s_arg(struct float16_s a) {}
+
+// ILP32-ILP32F-ILP32D-LABEL: define dso_local i32 @f_ret_float16_s
+// ILP32-ILP32F-ILP32D-SAME: () #[[ATTR0]] {
+// ILP32-ILP32F-ILP32D:  entry:
+//
+struct float16_s f_ret_float16_s(void) {
+  return (struct float16_s){1.0};
+}
+
+// A struct containing a double and any number of zero-width bitfields is
+// passed as though it were a standalone floating-point real.
+
+struct zbf_float16_s { int : 0; _Float16 f; };
+struct zbf_float16_zbf_s { int : 0; _Float16 f; int : 0; };
+
+// ILP32-ILP32F-ILP32D-LABEL: define dso_local void @f_zbf_float16_s_arg
+// ILP32-ILP32F-ILP32D-SAME: (i32 [[A_COERCE:%.*]]) #[[ATTR0]] {
+// ILP32-ILP32F-ILP32D:  entry:
+//
+void f_zbf_float16_s_arg(struct zbf_float16_s a) {}
+
+// ILP32-ILP32F-ILP32D-LABEL: define dso_local i32 @f_ret_zbf_float16_s
+// ILP32-ILP32F-ILP32D-SAME: () #[[ATTR0]] {
+// ILP32-ILP32F-ILP32D:  entry:
+//
+struct zbf_float16_s f_ret_zbf_float16_s(void) {
+  return (struct zbf_float16_s){1.0};
+}
+
+// ILP32-ILP32F-ILP32D-LABEL: define dso_local void @f_zbf_float16_zbf_s_arg
+// ILP32-ILP32F-ILP32D-SAME: (i32 [[A_COERCE:%.*]]) #[[ATTR0]] {
+// ILP32-ILP32F-ILP32D:  entry:
+//
+void f_zbf_float16_zbf_s_arg(struct zbf_float16_zbf_s a) {}
+
+// IL

  1   2   3   >