[PATCH] D50043: [RISCV] RISC-V using -fuse-init-array by default

[Alex Bradbury via Phabricator via cfe-commits]

asb accepted this revision.
asb added a comment.
This revision is now accepted and ready to land.

Thanks, looks good to me.


https://reviews.llvm.org/D50043



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

[PATCH] D50246: [RISCV] Add support for computing sysroot for riscv32-unknown-elf

[Alex Bradbury via Phabricator via cfe-commits]

asb added a comment.
Herald added a subscriber: jocewei.

Thanks for the patch and sorry for the delay. Once someone else marked it 
accepted it moves to a separate list in Phabricator - obviously I need to check 
the 'waiting on authors' list better.

As I see it are two changes here:

1. Calculating libcxx include paths based on specified sysroot
2. Computing the sysroot when an explicit path isn't provided

Could you please add a test that covers 2) above?


Repository:
  rC Clang

https://reviews.llvm.org/D50246



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

[PATCH] D39053: [Bitfield] Add more cases to making the bitfield a separate location

[Alex Bradbury via Phabricator via cfe-commits]

asb added a comment.

Just wanted to explicitly say that I'm happy the updated patch reflects the 
changes to docs and comments I requested. @hfinkel - are you happy for this to 
land now?


https://reviews.llvm.org/D39053



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

[PATCH] D46822: [RISCV] Add driver for riscv32-unknown-elf baremetal target

[Alex Bradbury via Phabricator via cfe-commits]

asb created this revision.
asb added reviewers: efriedma, phosek, apazos.
Herald added subscribers: mgrang, edward-jones, zzheng, shiva0217, kito-cheng, 
niosHD, sabuasal, jordy.potman.lists, simoncook, johnrusso, rbar, arichardson, 
mgorny, emaste.
Herald added a reviewer: espindola.

This patch adds a driver for the baremetal RISC-V target (i.e. 
riscv32-unknown-elf). For reference, https://reviews.llvm.org/D39963 added 
basic target info and added support for riscv32-linux-unknown-elf.


Repository:
  rC Clang

https://reviews.llvm.org/D46822

Files:
  lib/Driver/CMakeLists.txt
  lib/Driver/Driver.cpp
  lib/Driver/ToolChains/Gnu.cpp
  lib/Driver/ToolChains/RISCV.cpp
  lib/Driver/ToolChains/RISCV.h
  test/Driver/Inputs/basic_riscv32_tree/bin/riscv32-unknown-elf-ld
  
test/Driver/Inputs/basic_riscv32_tree/lib/gcc/riscv32-unknown-elf/8.0.1/crtbegin.o
  
test/Driver/Inputs/basic_riscv32_tree/lib/gcc/riscv32-unknown-elf/8.0.1/crtend.o
  
test/Driver/Inputs/basic_riscv32_tree/riscv32-unknown-elf/include/c++/8.0.1/.keep
  test/Driver/Inputs/basic_riscv32_tree/riscv32-unknown-elf/lib/crt0.o
  test/Driver/riscv32-toolchain.c

Index: test/Driver/riscv32-toolchain.c
===
--- test/Driver/riscv32-toolchain.c
+++ test/Driver/riscv32-toolchain.c
@@ -3,6 +3,36 @@
 // RUN: %clang %s -### -no-canonical-prefixes -target riscv32 2>&1 | FileCheck -check-prefix=CC1 %s
 // CC1: clang{{.*}} "-cc1" "-triple" "riscv32"
 
+// RUN: %clang %s -### -no-canonical-prefixes \
+// RUN:   -target riscv32-unknown-elf \
+// RUN:   --gcc-toolchain=%S/Inputs/basic_riscv32_tree \
+// RUN:   --sysroot=%S/Inputs/basic_riscv32_tree/riscv32-unknown-elf 2>&1 \
+// RUN:   | FileCheck -check-prefix=C-RV32-BAREMETAL-ILP32 %s
+
+// C-RV32-BAREMETAL-ILP32: "{{.*}}Inputs/basic_riscv32_tree/lib/gcc/riscv32-unknown-elf/8.0.1/../../../../bin{{/|}}riscv32-unknown-elf-ld"
+// C-RV32-BAREMETAL-ILP32: "--sysroot={{.*}}/Inputs/basic_riscv32_tree/riscv32-unknown-elf"
+// C-RV32-BAREMETAL-ILP32: "{{.*}}/Inputs/basic_riscv32_tree/riscv32-unknown-elf/lib{{/|}}crt0.o"
+// C-RV32-BAREMETAL-ILP32: "{{.*}}/Inputs/basic_riscv32_tree/lib/gcc/riscv32-unknown-elf/8.0.1{{/|}}crtbegin.o"
+// C-RV32-BAREMETAL-ILP32: "-L{{.*}}/Inputs/basic_riscv32_tree/riscv32-unknown-elf/lib"
+// C-RV32-BAREMETAL-ILP32: "-L{{.*}}/Inputs/basic_riscv32_tree/lib/gcc/riscv32-unknown-elf/8.0.1"
+// C-RV32-BAREMETAL-ILP32: "--start-group" "-lc" "-lgloss" "--end-group" "-lgcc"
+// C-RV32-BAREMETAL-ILP32: "{{.*}}/Inputs/basic_riscv32_tree/lib/gcc/riscv32-unknown-elf/8.0.1{{/|}}crtend.o"
+
+// RUN: %clangxx %s -### -no-canonical-prefixes \
+// RUN:   -target riscv32-unknown-elf \
+// RUN:   --gcc-toolchain=%S/Inputs/basic_riscv32_tree \
+// RUN:   --sysroot=%S/Inputs/basic_riscv32_tree/riscv32-unknown-elf 2>&1 \
+// RUN:   | FileCheck -check-prefix=CXX-RV32-BAREMETAL-ILP32 %s
+
+// CXX-RV32-BAREMETAL-ILP32: "-internal-isystem" "{{.*}}Inputs/basic_riscv32_tree/lib/gcc/riscv32-unknown-elf/8.0.1/../../../../riscv32-unknown-elf/include/c++{{/|}}8.0.1"
+// CXX-RV32-BAREMETAL-ILP32: "{{.*}}Inputs/basic_riscv32_tree/lib/gcc/riscv32-unknown-elf/8.0.1/../../../../bin{{/|}}riscv32-unknown-elf-ld"
+// CXX-RV32-BAREMETAL-ILP32: "--sysroot={{.*}}/Inputs/basic_riscv32_tree/riscv32-unknown-elf"
+// CXX-RV32-BAREMETAL-ILP32: "{{.*}}/Inputs/basic_riscv32_tree/riscv32-unknown-elf/lib{{/|}}crt0.o"
+// CXX-RV32-BAREMETAL-ILP32: "{{.*}}/Inputs/basic_riscv32_tree/lib/gcc/riscv32-unknown-elf/8.0.1{{/|}}crtbegin.o"
+// CXX-RV32-BAREMETAL-ILP32: "-L{{.*}}/Inputs/basic_riscv32_tree/riscv32-unknown-elf/lib"
+// CXX-RV32-BAREMETAL-ILP32: "-L{{.*}}/Inputs/basic_riscv32_tree/lib/gcc/riscv32-unknown-elf/8.0.1"
+// CXX-RV32-BAREMETAL-ILP32: "-lstdc++" "--start-group" "-lc" "-lgloss" "--end-group" "-lgcc"
+// CXX-RV32-BAREMETAL-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 \
Index: test/Driver/Inputs/basic_riscv32_tree/bin/riscv32-unknown-elf-ld
===
--- /dev/null
+++ test/Driver/Inputs/basic_riscv32_tree/bin/riscv32-unknown-elf-ld
@@ -0,0 +1 @@
+#!/bin/true
Index: lib/Driver/ToolChains/RISCV.h
===
--- /dev/null
+++ lib/Driver/ToolChains/RISCV.h
@@ -0,0 +1,57 @@
+//===--- RISCV.h - RISCV ToolChain Implementations --*- C++ -*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#ifndef LLVM_CLANG_LIB_DRIVER_TOOLCHAINS_RISCV_H
+#define LLVM_CLANG_LIB_DRIVER_TOOLCHAINS_RISCV_H
+
+#include "Gnu.h"
+#include "clang/Driver/ToolChain.h"
+

[PATCH] D46822: [RISCV] Add driver for riscv32-unknown-elf baremetal target

[Alex Bradbury via Phabricator via cfe-commits]

asb added a comment.

In https://reviews.llvm.org/D46822#1098764, @efriedma wrote:

> Could you include some documentation for how to construct a baremetal 
> environment like the one this code expects?  It's not clear what exactly you 
> expect to be installed where.


Thanks for taking a look Eli.

Building gcc+binutils+newlib will spit out a directory tree with the expected 
setup. e.g. a while ago I wrote a blog post 

 trying to show how to build upstream RISC-V gcc+binutils+newlib in the 
simplest way possible. You need a multistage build for C++ support and other 
features, but those instructions are enough to get a baremetal cross compiler. 
The directory layout is the same as if you use the build script in the 
riscv-gnu-toolchain repo , doing 
`./configure --prefix=/my/target/path --with-arch=rv32i --with-abi=ilp32; make 
-j$(nproc)`. This is a more advanced multi-stage build.

Would you like to see more information on this added to the commit message, as 
comments in the code, or elsewhere?

e.g. this is the directory listing of the build output if you follow the linked 
blog instructions: https://pastebin.com/8HeCMpxF


Repository:
  rC Clang

https://reviews.llvm.org/D46822



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

[PATCH] D44888: [RISCV] Default enable linker relaxation and add -mrelax, -mno-relax flags

[Alex Bradbury via Phabricator via cfe-commits]

asb added a comment.

I wonder if it would be safer to change this patch so it adds -mrelax and 
-mno-relax but doesn't compile with linker relaxation by default. That makes it 
easier to test linker relaxation support, and gives more time for testing 
before then flipping to -mrelax as the default.




Comment at: test/Driver/riscv-features.c:8
+// RUN: %clang -target riscv32-unknown-elf -### %s -mno-relax 2>&1 | FileCheck 
%s -check-prefix=NO-RELAX
+
+// RELAX: "-target-feature" "+relax"

We need a another RUN line and CHECK here to determine the default whether 
+relax is passed or not when the user specifies neither -mrelax or -mno-relax.


Repository:
  rL LLVM

https://reviews.llvm.org/D44888



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

[PATCH] D44888: [RISCV] Add -mrelax/-mno-relax flags to enable/disable RISCV linker relaxation

[Alex Bradbury via Phabricator via cfe-commits]

asb added a comment.

This is looking good to me, just needs an update to address this 
 request for a test in 
riscv-features.c that demonstrates the default +relax/-relax setting.


Repository:
  rL LLVM

https://reviews.llvm.org/D44888



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

[PATCH] D44888: [RISCV] Add -mrelax/-mno-relax flags to enable/disable RISCV linker relaxation

[Alex Bradbury via Phabricator via cfe-commits]

asb added a comment.

In https://reviews.llvm.org/D44888#920, @shiva0217 wrote:

> In https://reviews.llvm.org/D44888#1109361, @asb wrote:
>
> > This is looking good to me, just needs an update to address this 
> >  request for a test in 
> > riscv-features.c that demonstrates the default +relax/-relax setting.
>
>
> Hi Alex. I added the testing line on https://reviews.llvm.org/D47127 which is 
> the patch we turn on relaxation as default. Do you think it's ok?


I saw that. I don't mean to be too nit-picky, but there's an advantage in also 
testing the default in this patch - it tests the current behaviour and makes it 
obvious in the follow-up patch that the behaviour actually changed.


Repository:
  rL LLVM

https://reviews.llvm.org/D44888



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

[PATCH] D44888: [RISCV] Add -mrelax/-mno-relax flags to enable/disable RISCV linker relaxation

[Alex Bradbury via Phabricator via cfe-commits]

asb accepted this revision.
asb added a comment.
This revision is now accepted and ready to land.

Looks good to me, thanks!


Repository:
  rL LLVM

https://reviews.llvm.org/D44888



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

[PATCH] D50246: [RISCV] Add support for computing sysroot for riscv32-unknown-elf

[Alex Bradbury via Phabricator via cfe-commits]

asb accepted this revision.
asb added a comment.

Looks good to me, thanks!


Repository:
  rC Clang

https://reviews.llvm.org/D50246



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

[PATCH] D48412: [RISCV] Add support for interrupt attribute

[Alex Bradbury via Phabricator via cfe-commits]

asb accepted this revision.
asb added a comment.
Herald added a subscriber: rkruppe.

This looks good to me with two caveats

- the tests don't seem to check that the "machine" is the default mode when the 
"interrupt" attribute has no arguments.
- Although the conversion from RISCVInterruptAttr::user to "user" etc is 
trivial, it would probably be worth testing the emitted attributes are as 
expected?


https://reviews.llvm.org/D48412



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

[PATCH] D48412: [RISCV] Add support for interrupt attribute

[Alex Bradbury via Phabricator via cfe-commits]

asb accepted this revision.
asb added a comment.

Looks good to me.


https://reviews.llvm.org/D48412



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

[PATCH] D50043: [RISCV] RISC-V using -fuse-init-array by default

[Alex Bradbury via Phabricator via cfe-commits]

asb added a comment.

Could you add a test for this please?


Repository:
  rC Clang

https://reviews.llvm.org/D50043



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

[PATCH] D43105: [RISCV] Enable __int128_t and uint128_t through clang flag

[Alex Bradbury via Phabricator via cfe-commits]

asb added a comment.

In https://reviews.llvm.org/D43105#1003709, @efriedma wrote:

> So you want int128_t for compiler-rt itself, so you can use the soft-float 
> implementation, but you want to make int128_t opt-in to avoid the possibility 
> of someone getting a link error trying to link code built with clang against 
> libgcc.a?  That seems a little convoluted, but I guess it's okay.


That's one particular problem you might encounter if Clang and gcc for RISCV32 
made different choices about enabling int128 by default. More generally, we 
want to ensure the C environment for both GCC and Clang is as close as 
possible, as any difference like this has the potential for causing difficult 
to debug differences in behaviour that confuse end users.


Repository:
  rC Clang

https://reviews.llvm.org/D43105



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

[PATCH] D43105: [RISCV] Enable __int128_t and uint128_t through clang flag

[Alex Bradbury via Phabricator via cfe-commits]

asb added a comment.
Herald added a subscriber: shiva0217.

As @efriedma noted in https://reviews.llvm.org/D43106, it would be good to have 
some test coverage for ABI lowering. I'd suggest updating 
test/Driver/riscv32-abi.c with something like:

  #ifdef __SIZEOF_INT128__
  // CHECK-FORCEINT128-LABEL: define i128 @f_scalar_5(i128 %x)
  __int128_t f_scalar_5(__int128_t x) { return x; }
  #endif

You could also check the updated defines in in test/Preprocessor/init.c (seems 
it should just be the addition of `__SIZEOF_INT128__`).


Repository:
  rC Clang

https://reviews.llvm.org/D43105



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

[PATCH] D43105: [RISCV] Enable __int128_t and __uint128_t through clang flag

[Alex Bradbury via Phabricator via cfe-commits]

asb accepted this revision.
asb added a comment.

I've added two suggestions on further tweaking the tests which I think it would 
be worth adopting. Looks good to me.




Comment at: test/CodeGen/riscv32-abi.c:424-430
+
+// RUN: %clang_cc1 -triple riscv32 -fforce-enable-int128 \
+// RUN: -emit-llvm %s -o - | FileCheck %s -check-prefix=CHECK-FORCEINT128-LABEL
+#ifdef __SIZEOF_INT128__
+// CHECK-FORCEINT128-LABEL: define i128 @f_scalar_5(i128 %x)
+__int128_t f_scalar_5(__int128_t x) { return x; }
+#endif

I'd probably insert this around line 26 (just after f_scalar_4) and put the RUN 
line at the very top of the file with -check-prefixes=CHECK,CHECK-FORCEINT128. 
This would demonstrate and verify that all other ABI lowering remains totally 
unaffected, which probably can't hurt. Note that `$CHECKPREFIX-LABEL` is a 
[FileCheck 
feature](https://llvm.org/docs/CommandGuide/FileCheck.html#the-check-label-directive),
 so the prefix should be defined without `-LABEL`.



Comment at: test/Preprocessor/init.c:10213-10216
+// RUN: %clang_cc1 -E -dM -ffreestanding \
+// RUN: -triple=riscv32 -fforce-enable-int128 < /dev/null \
+// RUN:   | FileCheck -match-full-lines -check-prefix=RISCV32-INT128 %s
+// RISCV32-INT128: #define __SIZEOF_INT128__ 16

It would be slightly better to define this in a similar way to the 
RISCV32-LINUX checks, so that the test also picks up the fact that other 
defines (such as _INTMAX_WIDTH__) remain unmodified.


Repository:
  rC Clang

https://reviews.llvm.org/D43105



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

[PATCH] D43105: [RISCV] Enable __int128_t and __uint128_t through clang flag

[Alex Bradbury via Phabricator via cfe-commits]

asb added inline comments.



Comment at: test/CodeGen/riscv32-abi.c:2-3
 // 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-prefix=CHECK-FORCEINT128
 

Nit: this is slightly different to what I suggested. 
`-check-prefixes=CHECK,CHECK-FORCEINT128` would mean that all the other 
lowerings are rechecked with -fforce-eanble-int128 and are seen to remain 
unchanged.


Repository:
  rC Clang

https://reviews.llvm.org/D43105



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

[PATCH] D41271: [RISCV] Propagate -mabi and -march values to GNU assembler.

[Alex Bradbury via Phabricator via cfe-commits]

asb edited subscribers, added: cfe-commits; removed: llvm-commits.
asb added a comment.

Removing llvm-commits and adding cfe-commits.

Thanks Ana. This looks good to me. We probably should have a default march, but 
I don't know what it should be. If most clang targets default to a 
Linux-capable baseline it should probably be -march=rv32gc or -march=rv64gc 
depending on if the target is rv32/rv64.


https://reviews.llvm.org/D41271



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

[PATCH] D41271: [RISCV] Propagate -mabi and -march values to GNU assembler.

[Alex Bradbury via Phabricator via cfe-commits]

asb added inline comments.



Comment at: test/Driver/riscv-gnutools.c:6
+// RUN: %clang -target riscv64-unknown-elf -fno-integrated-as %s -### \
+// RUN: 2>&1 | FileCheck -check-prefix=MABI-ILP64 %s
+

s/MABI-ILP64/MABI-LP64


https://reviews.llvm.org/D41271



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

[PATCH] D39963: [RISCV] Add initial RISC-V target and driver support

[Alex Bradbury via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rC322276: [RISCV] Add the RISCV target and compiler driver 
(authored by asb, committed by ).

Changed prior to commit:
  https://reviews.llvm.org/D39963?vs=126771&id=129436#toc

Repository:
  rC Clang

https://reviews.llvm.org/D39963

Files:
  lib/Basic/CMakeLists.txt
  lib/Basic/Targets.cpp
  lib/Basic/Targets/RISCV.cpp
  lib/Basic/Targets/RISCV.h
  lib/Driver/CMakeLists.txt
  lib/Driver/ToolChains/Arch/RISCV.cpp
  lib/Driver/ToolChains/Arch/RISCV.h
  lib/Driver/ToolChains/Clang.cpp
  lib/Driver/ToolChains/Clang.h
  lib/Driver/ToolChains/Gnu.cpp
  lib/Driver/ToolChains/Linux.cpp
  test/Driver/Inputs/multilib_riscv_linux_sdk/bin/.keep
  test/Driver/Inputs/multilib_riscv_linux_sdk/include/.keep
  test/Driver/Inputs/multilib_riscv_linux_sdk/riscv64-unknown-linux-gnu/bin/ld
  test/Driver/Inputs/multilib_riscv_linux_sdk/sysroot/lib/.keep
  test/Driver/Inputs/multilib_riscv_linux_sdk/sysroot/lib32/ilp32/.keep
  test/Driver/Inputs/multilib_riscv_linux_sdk/sysroot/lib32/ilp32d/.keep
  test/Driver/Inputs/multilib_riscv_linux_sdk/sysroot/lib64/lp64/.keep
  test/Driver/Inputs/multilib_riscv_linux_sdk/sysroot/lib64/lp64d/.keep
  test/Driver/Inputs/multilib_riscv_linux_sdk/sysroot/usr/lib32/ilp32/.keep
  test/Driver/Inputs/multilib_riscv_linux_sdk/sysroot/usr/lib32/ilp32d/.keep
  test/Driver/Inputs/multilib_riscv_linux_sdk/sysroot/usr/lib64/lp64/.keep
  test/Driver/Inputs/multilib_riscv_linux_sdk/sysroot/usr/lib64/lp64d/.keep
  test/Driver/frame-pointer.c
  test/Driver/riscv-abi.c
  test/Driver/riscv-features.c
  test/Driver/riscv32-toolchain.c
  test/Driver/riscv64-toolchain.c
  test/Preprocessor/init.c

Index: test/Preprocessor/init.c
===
--- test/Preprocessor/init.c
+++ test/Preprocessor/init.c
@@ -10003,3 +10003,398 @@
 // ARM-DARWIN-BAREMETAL-64: #define __PTRDIFF_TYPE__ long int
 // ARM-DARWIN-BAREMETAL-64: #define __SIZE_TYPE__ long unsigned int
 
+// RUN: %clang_cc1 -E -dM -ffreestanding -triple=riscv32 < /dev/null \
+// RUN:   | FileCheck -match-full-lines -check-prefix=RISCV32 %s
+// RISCV32: #define _ILP32 1
+// RISCV32: #define __ATOMIC_ACQUIRE 2
+// RISCV32: #define __ATOMIC_ACQ_REL 4
+// RISCV32: #define __ATOMIC_CONSUME 1
+// RISCV32: #define __ATOMIC_RELAXED 0
+// RISCV32: #define __ATOMIC_RELEASE 3
+// RISCV32: #define __ATOMIC_SEQ_CST 5
+// RISCV32: #define __BIGGEST_ALIGNMENT__ 16
+// RISCV32: #define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__
+// RISCV32: #define __CHAR16_TYPE__ unsigned short
+// RISCV32: #define __CHAR32_TYPE__ unsigned int
+// RISCV32: #define __CHAR_BIT__ 8
+// RISCV32: #define __DBL_DECIMAL_DIG__ 17
+// RISCV32: #define __DBL_DENORM_MIN__ 4.9406564584124654e-324
+// RISCV32: #define __DBL_DIG__ 15
+// RISCV32: #define __DBL_EPSILON__ 2.2204460492503131e-16
+// RISCV32: #define __DBL_HAS_DENORM__ 1
+// RISCV32: #define __DBL_HAS_INFINITY__ 1
+// RISCV32: #define __DBL_HAS_QUIET_NAN__ 1
+// RISCV32: #define __DBL_MANT_DIG__ 53
+// RISCV32: #define __DBL_MAX_10_EXP__ 308
+// RISCV32: #define __DBL_MAX_EXP__ 1024
+// RISCV32: #define __DBL_MAX__ 1.7976931348623157e+308
+// RISCV32: #define __DBL_MIN_10_EXP__ (-307)
+// RISCV32: #define __DBL_MIN_EXP__ (-1021)
+// RISCV32: #define __DBL_MIN__ 2.2250738585072014e-308
+// RISCV32: #define __DECIMAL_DIG__ __LDBL_DECIMAL_DIG__
+// RISCV32: #define __ELF__ 1
+// RISCV32: #define __FINITE_MATH_ONLY__ 0
+// RISCV32: #define __FLT_DECIMAL_DIG__ 9
+// RISCV32: #define __FLT_DENORM_MIN__ 1.40129846e-45F
+// RISCV32: #define __FLT_DIG__ 6
+// RISCV32: #define __FLT_EPSILON__ 1.19209290e-7F
+// RISCV32: #define __FLT_EVAL_METHOD__ 0
+// RISCV32: #define __FLT_HAS_DENORM__ 1
+// RISCV32: #define __FLT_HAS_INFINITY__ 1
+// RISCV32: #define __FLT_HAS_QUIET_NAN__ 1
+// RISCV32: #define __FLT_MANT_DIG__ 24
+// RISCV32: #define __FLT_MAX_10_EXP__ 38
+// RISCV32: #define __FLT_MAX_EXP__ 128
+// RISCV32: #define __FLT_MAX__ 3.40282347e+38F
+// RISCV32: #define __FLT_MIN_10_EXP__ (-37)
+// RISCV32: #define __FLT_MIN_EXP__ (-125)
+// RISCV32: #define __FLT_MIN__ 1.17549435e-38F
+// RISCV32: #define __FLT_RADIX__ 2
+// RISCV32: #define __GCC_ATOMIC_BOOL_LOCK_FREE 1
+// RISCV32: #define __GCC_ATOMIC_CHAR16_T_LOCK_FREE 1
+// RISCV32: #define __GCC_ATOMIC_CHAR32_T_LOCK_FREE 1
+// RISCV32: #define __GCC_ATOMIC_CHAR_LOCK_FREE 1
+// RISCV32: #define __GCC_ATOMIC_INT_LOCK_FREE 1
+// RISCV32: #define __GCC_ATOMIC_LLONG_LOCK_FREE 1
+// RISCV32: #define __GCC_ATOMIC_LONG_LOCK_FREE 1
+// RISCV32: #define __GCC_ATOMIC_POINTER_LOCK_FREE 1
+// RISCV32: #define __GCC_ATOMIC_SHORT_LOCK_FREE 1
+// RISCV32: #define __GCC_ATOMIC_TEST_AND_SET_TRUEVAL 1
+// RISCV32: #define __GCC_ATOMIC_WCHAR_T_LOCK_FREE 1
+// RISCV32: #define __GNUC_MINOR__ {{.*}}
+// RISCV32: #define __GNUC_PATCHLEVEL__ {{.*}}
+// RISCV32: #define __GNUC_STDC_INLINE__ 1
+// RISCV32: #define __GNUC__ {{.*}}
+// RISCV32: #define __GXX_ABI_VERSION {{.*}}
+// R

[PATCH] D41271: [RISCV] Propagate -mabi and -march values to GNU assembler.

[Alex Bradbury via Phabricator via cfe-commits]

asb added a comment.

I've just had a painful time landing https://reviews.llvm.org/D39963 due to 
failures on the Windows buildbots. I think you'll have problems on Windows with 
the tests in this patch, as Windows surely won't default to /usr/bin/as. Sadly 
I don't have access to a windows Clang build to confirm what path it will 
default to.


https://reviews.llvm.org/D41271



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

[PATCH] D44189: [RISCV] Verify the input value of -march=

[Alex Bradbury via Phabricator via cfe-commits]

asb added a comment.

Thanks for submitting this Kito. I've added some minor in-line comments. It 
might also be worth adding a couple of extra cases to the tests:

- Repeated letters in the ISA string (e.g. rv32immafd)
- Upper case letters in the ISA string. We currently reject these (as does 
GCC). It would be worth having a test that tracks this behaviour

We could probably give more informative error messages than just "invalid arch 
name". Especially for common errors like -march=rv32. If not adding such 
diagnostics in this patch, it would be good to add a `// TODO` note to record 
that we'd like to do better.




Comment at: lib/Driver/ToolChains/Arch/RISCV.cpp:34
+
+// The canonical order specified in ISA manual.
+StringRef StdExts = "mafdc";

I'd reference Table 22.1 in RISC-V User-Level ISA V2.2 for anyone who wants to 
verify this.



Comment at: lib/Driver/ToolChains/Arch/RISCV.cpp:37-38
+
+bool hasF = false, hasD = false;
+char baseline = MArch[4];
+

Should be HasF, HasD, and Baseline to conform to standard LLVM naming 
conventions.



Comment at: lib/Driver/ToolChains/Arch/RISCV.cpp:65
+for (char c : Exts) {
+  // Check march is satisfied the canonical order.
+  while (StdExtsItr != StdExts.end() && *StdExtsItr != c)

I'd phrase this as "Check ISA extensions are specified in the canonical order."



Comment at: lib/Driver/ToolChains/Arch/RISCV.cpp:99
+
+// Dependency check
+if (hasD && !hasF)

I'd be tempted to give a bit more explanation a bit more "It's illegal to 
specify the 'd' (double-precision floating point) extension without also 
specifying the 'f' (single precision floating-point) extension".


https://reviews.llvm.org/D44189



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

[PATCH] D57055: [RISCV] Mark TLS as supported

[Alex Bradbury via Phabricator via cfe-commits]

asb added a comment.

Could you add a test for this? I'm not sure if this is best done with a test 
that uses __has_feature or otherwise (I note other targets don't seem to have 
similar tests currently), but I think it would be handy.


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D57055/new/

https://reviews.llvm.org/D57055



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

[PATCH] D57450: [RISCV] Set MaxAtomicInlineWidth and MaxAtomicPromoteWidth for RV32/RV64 targets with atomics

[Alex Bradbury via Phabricator via cfe-commits]

asb created this revision.
asb added reviewers: jfb, jyknight, wmi.
Herald added subscribers: jocewei, PkmX, rkruppe, the_o, brucehoult, 
MartinMosbeck, rogfer01, edward-jones, zzheng, jrtc27, shiva0217, kito-cheng, 
niosHD, sabuasal, apazos, simoncook, johnrusso, rbar.

This ensures that libcalls aren't generated when the target supports atomics. 
Atomics aren't in the base RV32I/RV64I instruction sets, so 
MaxAtomicInlineWidth and MaxAtomicPromoteWidth are set only when the atomics 
extension is being targeted. This must be done in setMaxAtomicWidth, as this 
should be done after handleTargetFeatures has been called.


Repository:
  rC Clang

https://reviews.llvm.org/D57450

Files:
  lib/Basic/Targets/RISCV.h
  test/CodeGen/riscv-atomics.c

Index: test/CodeGen/riscv-atomics.c
===
--- /dev/null
+++ test/CodeGen/riscv-atomics.c
@@ -0,0 +1,68 @@
+// RUN: %clang_cc1 -triple riscv32 -O1 -emit-llvm %s -o - \
+// RUN:   | FileCheck %s -check-prefix=RV32I
+// RUN: %clang_cc1 -triple riscv32 -target-feature +a -O1 -emit-llvm %s -o - \
+// RUN:   | FileCheck %s -check-prefix=RV32IA
+// RUN: %clang_cc1 -triple riscv64 -O1 -emit-llvm %s -o - \
+// RUN:   | FileCheck %s -check-prefix=RV64I
+// RUN: %clang_cc1 -triple riscv64 -target-feature +a -O1 -emit-llvm %s -o - \
+// RUN:   | FileCheck %s -check-prefix=RV64IA
+
+// This test demonstrates that MaxAtomicInlineWidth is set appropriately when
+// the atomics instruction set extension is enabled.
+
+#include 
+#include 
+
+void test_i8_atomics(_Atomic(int8_t) * a, int8_t b) {
+  // RV32I:  call zeroext i8 @__atomic_load_1
+  // RV32I:  call void @__atomic_store_1
+  // RV32I:  call zeroext i8 @__atomic_fetch_add_1
+  // RV32IA: load atomic i8, i8* %a seq_cst, align 1
+  // RV32IA: store atomic i8 %b, i8* %a seq_cst, align 1
+  // RV32IA: atomicrmw add i8* %a, i8 %b seq_cst
+  // RV64I:  call zeroext i8 @__atomic_load_1
+  // RV64I:  call void @__atomic_store_1
+  // RV64I:  call zeroext i8 @__atomic_fetch_add_1
+  // RV64IA: load atomic i8, i8* %a seq_cst, align 1
+  // RV64IA: store atomic i8 %b, i8* %a seq_cst, align 1
+  // RV64IA: atomicrmw add i8* %a, i8 %b seq_cst
+  __c11_atomic_load(a, memory_order_seq_cst);
+  __c11_atomic_store(a, b, memory_order_seq_cst);
+  __c11_atomic_fetch_add(a, b, memory_order_seq_cst);
+}
+
+void test_i32_atomics(_Atomic(int32_t) * a, int32_t b) {
+  // RV32I:  call i32 @__atomic_load_4
+  // RV32I:  call void @__atomic_store_4
+  // RV32I:  call i32 @__atomic_fetch_add_4
+  // RV32IA: load atomic i32, i32* %a seq_cst, align 4
+  // RV32IA: store atomic i32 %b, i32* %a seq_cst, align 4
+  // RV32IA: atomicrmw add i32* %a, i32 %b seq_cst
+  // RV64I:  call signext i32 @__atomic_load_4
+  // RV64I:  call void @__atomic_store_4
+  // RV64I:  call signext i32 @__atomic_fetch_add_4
+  // RV64IA: load atomic i32, i32* %a seq_cst, align 4
+  // RV64IA: store atomic i32 %b, i32* %a seq_cst, align 4
+  // RV64IA: atomicrmw add i32* %a, i32 %b seq_cst
+  __c11_atomic_load(a, memory_order_seq_cst);
+  __c11_atomic_store(a, b, memory_order_seq_cst);
+  __c11_atomic_fetch_add(a, b, memory_order_seq_cst);
+}
+
+void test_i64_atomics(_Atomic(int64_t) * a, int64_t b) {
+  // RV32I:  call i64 @__atomic_load_8
+  // RV32I:  call void @__atomic_store_8
+  // RV32I:  call i64 @__atomic_fetch_add_8
+  // RV32IA: call i64 @__atomic_load_8
+  // RV32IA: call void @__atomic_store_8
+  // RV32IA: call i64 @__atomic_fetch_add_8
+  // RV64I:  call i64 @__atomic_load_8
+  // RV64I:  call void @__atomic_store_8
+  // RV64I:  call i64 @__atomic_fetch_add_8
+  // RV64IA: load atomic i64, i64* %a seq_cst, align 8
+  // RV64IA: store atomic i64 %b, i64* %a seq_cst, align 8
+  // RV64IA: atomicrmw add i64* %a, i64 %b seq_cst
+  __c11_atomic_load(a, memory_order_seq_cst);
+  __c11_atomic_store(a, b, memory_order_seq_cst);
+  __c11_atomic_fetch_add(a, b, memory_order_seq_cst);
+}
Index: lib/Basic/Targets/RISCV.h
===
--- lib/Basic/Targets/RISCV.h
+++ lib/Basic/Targets/RISCV.h
@@ -88,6 +88,11 @@
 }
 return false;
   }
+
+  void setMaxAtomicWidth() override {
+if (HasA)
+  MaxAtomicPromoteWidth = MaxAtomicInlineWidth = 32;
+  }
 };
 class LLVM_LIBRARY_VISIBILITY RISCV64TargetInfo : public RISCVTargetInfo {
 public:
@@ -106,6 +111,11 @@
 }
 return false;
   }
+
+  void setMaxAtomicWidth() override {
+if (HasA)
+  MaxAtomicPromoteWidth = MaxAtomicInlineWidth = 64;
+  }
 };
 } // namespace targets
 } // namespace clang
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D57242: [RISCV] Specify MaxAtomicInlineWidth for RISC-V

[Alex Bradbury via Phabricator via cfe-commits]

asb added a comment.

Thanks Lewis, I actually had a patch for this which I forgot to clean up and 
submit. I've done so now: D57450 . That adds 
tests, and sets MaxAtomicInlineWidth and MaxAtomicPromoteWidth conditionally 
based on whether the target has the atomics extension or not.


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D57242/new/

https://reviews.llvm.org/D57242



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

[PATCH] D54091: [RISCV] Add inline asm constraints I, J & K for RISC-V

[Alex Bradbury via Phabricator via cfe-commits]

asb requested changes to this revision.
asb added a comment.
This revision now requires changes to proceed.

Thanks for the patch Lewis. Could I please request the following changes:

- It would be handy to link to 
https://gcc.gnu.org/onlinedocs/gccint/Machine-Constraints.html in the patch 
summary, so people can easily double-check the constraint definitions for 
themselves
- Could you add tests for values outside of the expected range. AArch64 and X86 
do this in test/Sema/inline-asm-validate-{aarch64,x86}.c
- It would be worth expanding riscv-inline-asm.c to provide simple sanity 
checks for "m" and "r"


Repository:
  rC Clang

https://reviews.llvm.org/D54091



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

[PATCH] D54816: [RISCV] Mark unit tests as "requires: riscv-registered-target"

[Alex Bradbury via Phabricator via cfe-commits]

asb added a comment.

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.


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D54816/new/

https://reviews.llvm.org/D54816



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

[PATCH] D59233: libclang/CIndexer.cpp: Use loadquery() on AIX for path to library

[Alex Bradbury via Phabricator via cfe-commits]

asb added a comment.

In D59233#1439656 , 
@hubert.reinterpretcast wrote:

> Thanks @xingxue for the review. I will update for the error handling before 
> committing.


Use of report_fatal_error/llvm_unreachable isn't fully consistent within the 
LLVM codebase, but I think your choices here are sensible.


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D59233/new/

https://reviews.llvm.org/D59233



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

[PATCH] D59298: [RISCV] Pass -target-abi to -cc1as

[Alex Bradbury via Phabricator via cfe-commits]

asb accepted this revision.
asb added a comment.
This revision is now accepted and ready to land.
Herald added subscribers: benna, psnobl.

Thanks, LGTM.


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D59298/new/

https://reviews.llvm.org/D59298



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

[PATCH] D53392: [RISCV] Collect library directories and triples for riscv64 triple too

[Alex Bradbury via Phabricator via cfe-commits]

asb accepted this revision.
asb added a comment.
This revision is now accepted and ready to land.
Herald added subscribers: benna, psnobl, MaskRay.

This got missed somehow as I had a functionally identical patch in my local 
development tree (though not with as thorough tests - thanks for that!). LGTM, 
thanks Ed.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D53392/new/

https://reviews.llvm.org/D53392



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

[PATCH] D53392: [RISCV] Collect library directories and triples for riscv64 triple too

[Alex Bradbury via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL357699: [RISCV] Collect library directories and triples for 
riscv64 triple too (authored by asb, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D53392?vs=170374&id=193709#toc

Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D53392/new/

https://reviews.llvm.org/D53392

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

Index: cfe/trunk/lib/Driver/ToolChains/Gnu.cpp
===
--- cfe/trunk/lib/Driver/ToolChains/Gnu.cpp
+++ cfe/trunk/lib/Driver/ToolChains/Gnu.cpp
@@ -1976,10 +1976,14 @@
   "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 @@
 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:
Index: cfe/trunk/test/Driver/Inputs/basic_riscv64_tree/bin/riscv64-unknown-elf-ld
===
--- cfe/trunk/test/Driver/Inputs/basic_riscv64_tree/bin/riscv64-unknown-elf-ld
+++ cfe/trunk/test/Driver/Inputs/basic_riscv64_tree/bin/riscv64-unknown-elf-ld
@@ -0,0 +1 @@
+#!/bin/true
Index: cfe/trunk/test/Driver/riscv64-toolchain.c
===
--- cfe/trunk/test/Driver/riscv64-toolchain.c
+++ cfe/trunk/test/Driver/riscv64-toolchain.c
@@ -3,6 +3,102 @@
 // RUN: %clang %s -### -no-canonical-prefixes -target riscv64 2>&1 | FileCheck -check-prefix=CC1 %s
 // CC1: clang{{.*}} "-cc1" "-triple" "riscv64"
 
+// RUN: %clang %s -### -no-canonical-prefixes \
+// RUN:   -target riscv64-unknown-elf \
+// RUN:   --gcc-toolchain=%S/Inputs/basic_riscv64_tree \
+// RUN:   --sysroot=%S/Inputs/basic_riscv64_tree/riscv64-unknown-elf 2>&1 \
+// RUN:   | FileCheck -check-prefix=C-RV64-BAREMETAL-LP64 %s
+
+// C-RV64-BAREMETAL-LP64: "-fuse-init-array"
+// C-RV64-BAREMETAL-LP64: "{{.*}}Inputs/basic_riscv64_tree/lib/gcc/riscv64-unknown-elf/8.0.1/../../../../bin{{/|}}riscv64-unknown-elf-ld"
+// C-RV64-BAREMETAL-LP64: "--sysroot={{.*}}/Inputs/basic_riscv64_tree/riscv64-unknown-elf"
+// C-RV64-BAREMETAL-LP64: "{{.*}}/Inputs/basic_riscv64_tree/riscv64-unknown-elf/lib{{/|}}crt0.o"
+// C-RV64-BAREMETAL-LP64: "{{.*}}/Inputs/basic_riscv64_tree/lib/gcc/riscv64-unknown-elf/8.0.1{{/|}}crtbegin.o"
+// C-RV64-BAREMETAL-LP64: "-L{{.*}}/Inputs/basic_riscv64_tree/riscv64-unknown-elf/lib"
+// C-RV64-BAREMETAL-LP64: "-L{{.*}}/Inputs/basic_riscv64_tree/lib/gcc/riscv64-unknown-elf/8.0.1"
+// C-RV64-BAREMETAL-LP64: "--start-group" "-lc" "-lgloss" "--end-group" "-lgcc"
+// C-RV64-BAREMETAL-LP64: "{{.*}}/Inputs/basic_riscv64_tree/lib/gcc/riscv64-unknown-elf/8.0.1{{/|}}crtend.o"
+
+// RUN: %clang %s -### -no-canonical-prefixes \
+// RUN:   -target riscv64-unknown-elf \
+// RUN:   --sysroot= \
+// RUN:   --gcc

[PATCH] D60456: [RISCV][WIP/RFC] Hard float ABI support

[Alex Bradbury via Phabricator via cfe-commits]

asb created this revision.
asb added a reviewer: rjmccall.
Herald added subscribers: benna, psnobl, jocewei, PkmX, rkruppe, the_o, 
brucehoult, MartinMosbeck, rogfer01, edward-jones, zzheng, jrtc27, shiva0217, 
kito-cheng, niosHD, sabuasal, apazos, simoncook, johnrusso, rbar.
Herald added a project: clang.

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.

I'm sharing just in case there are any concerns about this general approach. 
Known deficiencies in this patch are all related to testing:

- Needs more basic ilp32d/lp64f/lp64d tests
- Not enough coverage of bitfields in structs, packed+aligned structs etc


Repository:
  rC Clang

https://reviews.llvm.org/D60456

Files:
  lib/Basic/Targets/RISCV.h
  lib/CodeGen/TargetInfo.cpp
  test/CodeGen/riscv32-ilp32-ilp32f-abi.c
  test/CodeGen/riscv32-ilp32-ilp32f-ilp32d-abi.c
  test/CodeGen/riscv32-ilp32f-abi.c
  test/CodeGen/riscv32-ilp32f-ilp32d-abi.c

Index: test/CodeGen/riscv32-ilp32f-ilp32d-abi.c
===
--- /dev/null
+++ test/CodeGen/riscv32-ilp32f-ilp32d-abi.c
@@ -0,0 +1,230 @@
+// RUN: %clang_cc1 -triple riscv32 -target-feature +f -target-abi ilp32f -emit-llvm %s -o - \
+// RUN: | FileCheck %s
+
+#include 
+
+// Verify that the tracking of used GPRs and FPRs works correctly by checking
+// that small integers are sign/zero extended when passed in registers.
+
+// Floats are passed in FPRs, so argument 'i' will be passed zero-extended 
+// because it will be passed in a GPR.
+
+// CHECK: define void @f_fpr_tracking(float %a, float %b, float %c, float %d, float %e, float %f, float %g, float %h, i8 zeroext %i)
+void f_fpr_tracking(float a, float b, float c, float d, float e, float f,
+float g, float h, uint8_t i) {}
+
+// 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).
+
+// A struct containing just one floating-point real is passed as though it 
+// were a standalone floating-point real.
+
+struct float_s { float f; };
+
+// CHECK: define void @f_float_s_arg(float)
+void f_float_s_arg(struct float_s a) {}
+
+// CHECK: define float @f_ret_float_s()
+struct float_s f_ret_float_s() {
+  return (struct float_s){1.0};
+}
+
+// Check that structs containing two float values (FLEN <= width) are expanded
+// provided sufficient FPRs are available.
+
+struct float_float_s { float f; float g; };
+
+// CHECK: define void @f_float_float_s_arg(float, float)
+void f_float_float_s_arg(struct float_float_s a) {}
+
+// CHECK: define { float, float } @f_ret_float_float_s()
+struct float_float_s f_ret_float_float_s() {
+  return (struct float_float_s){1.0, 2.0};
+}
+
+// CHECK: define void @f_float_float_s_arg_insufficient_fprs(float %a, float %b, float %c, float %d, float %e, float %f, float %g, [2 x i32] %h.coerce)
+void f_float_float_s_arg_insufficient_fprs(float a, float b, float c, float d, 
+float e, float f, float g, struct float_float_s h) {}
+
+// Check that structs containing int+float values are expanded, provided
+// sufficient FPRs and GPRs are available. The integer components are neither
+// sign or zero-extended.
+
+struct float_int8_s { float f; int8_t i; };
+struct float_uint8_s { float f; uint8_t i; };
+struct float_int32_s { float f; int32_t i; };
+struct float_int64_s { float f; int64_t i; };
+
+// CHECK: define void @f_float_int8_s_arg(float, i8)
+void f_float_int8_s_arg(struct float_int8_s a) {}
+
+// CHECK: define { float, i8 } @f_ret_float_int8_s()
+struct float_int8_s f_ret_float_int8_s() {
+  return (struct float_in

[PATCH] D60456: [RISCV][WIP/RFC] Hard float ABI support

[Alex Bradbury via Phabricator via cfe-commits]

asb updated this revision to Diff 198797.
asb marked 3 inline comments as done.
asb added a comment.

Update:

- Expanded and improved tests
- Set ABI defines
- Remove errant TODO
- Use alignTo

Still to do:

- Review and test bitfield handling (which is likely incomplete)


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D60456/new/

https://reviews.llvm.org/D60456

Files:
  clang/lib/Basic/Targets/RISCV.cpp
  clang/lib/Basic/Targets/RISCV.h
  clang/lib/CodeGen/TargetInfo.cpp
  clang/test/CodeGen/riscv32-ilp32-ilp32f-abi.c
  clang/test/CodeGen/riscv32-ilp32-ilp32f-ilp32d-abi.c
  clang/test/CodeGen/riscv32-ilp32d-abi.c
  clang/test/CodeGen/riscv32-ilp32f-abi.c
  clang/test/CodeGen/riscv32-ilp32f-ilp32d-abi.c
  clang/test/CodeGen/riscv64-lp64-lp64f-abi.c
  clang/test/CodeGen/riscv64-lp64-lp64f-lp64d-abi.c
  clang/test/CodeGen/riscv64-lp64d-abi.c
  clang/test/CodeGen/riscv64-lp64f-lp64d-abi.c

Index: clang/test/CodeGen/riscv64-lp64f-lp64d-abi.c
===
--- /dev/null
+++ clang/test/CodeGen/riscv64-lp64f-lp64d-abi.c
@@ -0,0 +1,222 @@
+// RUN: %clang_cc1 -triple riscv64 -target-feature +f -target-abi lp64f -emit-llvm %s -o - \
+// RUN: | FileCheck %s
+// RUN: %clang_cc1 -triple riscv64 -target-feature +d -target-abi lp64d -emit-llvm %s -o - \
+// RUN: | FileCheck %s
+
+#include 
+
+// Verify that the tracking of used GPRs and FPRs works correctly by checking
+// that small integers are sign/zero extended when passed in registers.
+
+// Floats are passed in FPRs, so argument 'i' will be passed zero-extended
+// because it will be passed in a GPR.
+
+// CHECK: define void @f_fpr_tracking(float %a, float %b, float %c, float %d, float %e, float %f, float %g, float %h, i8 zeroext %i)
+void f_fpr_tracking(float a, float b, float c, float d, float e, float f,
+float g, float h, uint8_t i) {}
+
+// 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).
+
+// A struct containing just one floating-point real is passed as though it
+// were a standalone floating-point real.
+
+struct float_s { float f; };
+
+// CHECK: define void @f_float_s_arg(float)
+void f_float_s_arg(struct float_s a) {}
+
+// CHECK: define float @f_ret_float_s()
+struct float_s f_ret_float_s() {
+  return (struct float_s){1.0};
+}
+
+// Check that structs containing two float values (FLEN <= width) are expanded
+// provided sufficient FPRs are available.
+
+struct float_float_s { float f; float g; };
+
+// CHECK: define void @f_float_float_s_arg(float, float)
+void f_float_float_s_arg(struct float_float_s a) {}
+
+// CHECK: define { float, float } @f_ret_float_float_s()
+struct float_float_s f_ret_float_float_s() {
+  return (struct float_float_s){1.0, 2.0};
+}
+
+// CHECK: define void @f_float_float_s_arg_insufficient_fprs(float %a, float %b, float %c, float %d, float %e, float %f, float %g, i64 %h.coerce)
+void f_float_float_s_arg_insufficient_fprs(float a, float b, float c, float d,
+float e, float f, float g, struct float_float_s h) {}
+
+// Check that structs containing int+float values are expanded, provided
+// sufficient FPRs and GPRs are available. The integer components are neither
+// sign or zero-extended.
+
+struct float_int8_s { float f; int8_t i; };
+struct float_uint8_s { float f; uint8_t i; };
+struct float_int32_s { float f; int32_t i; };
+struct float_int64_s { float f; int64_t i; };
+
+// CHECK: define void @f_float_int8_s_arg(float, i8)
+void f_float_int8_s_arg(struct float_int8_s a) {}
+
+// CHECK: define { float, i8 } @f_ret_float_int8_s()
+struct float_int8_s f_ret_float_int8_s() {
+  return (struct float_int8_s){1.0, 2};
+}
+
+// CHECK: define void @f_float_uint8_s_arg(float, i8)
+void f_float_uint8_s_arg(struct float_uint8_s a) {}
+
+// CHECK: define { float, i8 } @f_ret_float_uint8_s()
+struct float_uint8_s f_ret_float_uint8_s() {
+  return (struct float_uint8_s){1.0, 2};
+}
+
+// CHECK: define void @f_float_int32_s_arg(float, i32)
+void f_float_int32_s_arg(struct float_int32_s a) {}
+
+// CHECK: define { float, i32 } @f_ret_float_int32_s()
+struct float_int32_s f_ret_float_int32_s() {
+  return (struct float_int32_s){1.0, 2};
+}
+
+// CHECK: define void @f_float_int64_s_arg(float, i64)
+void f_float_int64_s_arg(struct float_int64_s a) {}
+
+// CHECK: define { float, i64 } @f_ret_float_int64_s()
+struct float_int64_s f_ret_float_int64_s() {
+  return (struct float_int64_s){1.0, 2};
+}
+
+// CHECK: define void @f_float_int8_s_arg_insufficient_gprs(i32 signext %a, i32 signext %b, i32 signext %c, i32 signext %d, i32 signext %e, i32 signext %f, i32 signext %g, i32 signe

[PATCH] D60456: [RISCV][WIP/RFC] Hard float ABI support

[Alex Bradbury via Phabricator via cfe-commits]

asb added inline comments.



Comment at: lib/CodeGen/TargetInfo.cpp:9223
+
+  bool IsInt = Ty->isIntegralOrEnumerationType();
+  bool IsFloat = Ty->isRealFloatingType();

rjmccall wrote:
> Should this include pointers?  Pointers are often interchangeably with 
> integers by ABIs.
> 
> The same question also applies to C++ references and data-member-pointer 
> types, and maybe others that I'm not thinking of.
The ABI doesn't consider pointers and integers interchangeable in this case. An 
"integer" is indeed an integer.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D60456/new/

https://reviews.llvm.org/D60456



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

[PATCH] D47127: [RISCV] Default enable RISCV linker relaxation

[Alex Bradbury via Phabricator via cfe-commits]

asb edited subscribers, added: cfe-commits; removed: llvm-commits.
asb added a comment.

Removing llvm-commits and adding cfe-commits. This patch is mistakenly marked 
as targeting the LLVM repo rather than Clang.


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D47127/new/

https://reviews.llvm.org/D47127



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

[PATCH] D57450: [RISCV] Set MaxAtomicInlineWidth and MaxAtomicPromoteWidth for RV32/RV64 targets with atomics

[Alex Bradbury via Phabricator via cfe-commits]

asb added a comment.
Herald added a project: clang.

Ping?


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D57450/new/

https://reviews.llvm.org/D57450



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

[PATCH] D57450: [RISCV] Set MaxAtomicInlineWidth and MaxAtomicPromoteWidth for RV32/RV64 targets with atomics

[Alex Bradbury via Phabricator via cfe-commits]

asb added a comment.

In D57450#1402153 , @rogfer01 wrote:

> Looks sensible to me.
>
> I'm just curious why we want to prevent emission of atomic LLVM instructions 
> at this point. Won't LLVM's AtomicExpand perform a similar lowering already? 
> Perhaps the goal is to save that pass some work?


There was some discussion about whether the frontend should lower to libcalls 
or not here https://bugs.llvm.org/show_bug.cgi?id=31620 and it seems the 
decided path was that it's better for the frontend to lower, even if 
AtomicExpandPass does have some support for introducing these libcalls. 
Additionally, setting the max atomic inline width should mean that 
`__atomic_is_lock_free` is evaluated correctly.


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D57450/new/

https://reviews.llvm.org/D57450



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

[PATCH] D57795: [RISCV] Add FreeBSD targets

[Alex Bradbury via Phabricator via cfe-commits]

asb accepted this revision.
asb added a comment.
This revision is now accepted and ready to land.

This looks good to me, thanks!


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D57795/new/

https://reviews.llvm.org/D57795



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

[PATCH] D54091: [RISCV] Add inline asm constraints I, J & K for RISC-V

[Alex Bradbury via Phabricator via cfe-commits]

asb accepted this revision.
asb added a comment.
This revision is now accepted and ready to land.
Herald added a subscriber: Jim.

This looks good to me, but is blocked on the dependent patch being updated. I 
added a minor comment on riscv-inline-asm.c




Comment at: test/CodeGen/riscv-inline-asm.c:1
+// RUN: %clang_cc1 -triple riscv32 -target-feature +f -O2 -emit-llvm %s -o - \
+// RUN: | FileCheck %s

No need to enable +f for the test, as written.


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D54091/new/

https://reviews.llvm.org/D54091



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

[PATCH] D60974: Clang IFSO driver action.

[Alex Bradbury via Phabricator via cfe-commits]

asb added inline comments.



Comment at: cfe/trunk/lib/Frontend/CMakeLists.txt:58
   clangDriver
+  clangIndex
   clangEdit

plotfi wrote:
> MaskRay wrote:
> > This is a layering issue. clangIndex depends on clangFrontend so 
> > clangFrontend should not depend on clangIndex.
> > 
> > The circular dependency is allowed for static libraries but it breaks 
> > `-DBUILD_SHARED_LIBS=on`:
> > 
> > ```
> > CMake Error: The inter-target dependency graph contains the following 
> > strongly connected component (cycle):
> >   "clangFrontend" of type SHARED_LIBRARY
> > depends on "clangIndex" (weak)
> >   "clangIndex" of type SHARED_LIBRARY
> > depends on "clangFrontend" (weak)
> > At least one of these targets is not a STATIC_LIBRARY.  Cyclic dependencies 
> > are allowed only among static libraries.
> > ```
> Is there a bot affected by this? I will take a look.
Sadly there is no -DBUILD_SHARED_LIBS=True bot. This layering issue will break 
builds for all downstream users using that option though.


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D60974/new/

https://reviews.llvm.org/D60974



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

[PATCH] D54295: [RISCV] Add inline asm constraint A for RISC-V

[Alex Bradbury via Phabricator via cfe-commits]

asb accepted this revision.
asb added a comment.

LGTM, thanks!


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D54295/new/

https://reviews.llvm.org/D54295



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

[PATCH] D63498: [RISC-V] Add -msave-restore and -mno-save-restore to clang driver

[Alex Bradbury via Phabricator via cfe-commits]

asb added a comment.

Can you add a CHECK line that shows the expected warning is emitted?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D63498/new/

https://reviews.llvm.org/D63498



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

[PATCH] D63497: Add support for openSUSE RISC-V triple

[Alex Bradbury via Phabricator via cfe-commits]

asb added a comment.

Thanks for the contribution! I'd recommend adding a skeleton toolchain dir 
structure to clang/test/Driver/Inputs and adding a test to 
clang/test/Driver/riscv64-toolchain.c. You should be able to see examples in 
test/Driver/Inputs.


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D63497/new/

https://reviews.llvm.org/D63497



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

[PATCH] D57055: [RISCV] Mark TLS as supported

[Alex Bradbury via Phabricator via cfe-commits]

asb accepted this revision.
asb added a comment.
Herald added subscribers: Jim, benna, psnobl.

LGTM, thanks!


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D57055/new/

https://reviews.llvm.org/D57055



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

[PATCH] D60456: [RISCV] Hard float ABI support

[Alex Bradbury via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL366450: [RISCV] Hard float ABI support (authored by asb, 
committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D60456?vs=208477&id=210586#toc

Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D60456/new/

https://reviews.llvm.org/D60456

Files:
  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/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-lp64-lp64f-abi.c
  cfe/trunk/test/CodeGen/riscv64-lp64-lp64f-lp64d-abi.c
  cfe/trunk/test/CodeGen/riscv64-lp64d-abi.c
  cfe/trunk/test/CodeGen/riscv64-lp64f-lp64d-abi.c
  cfe/trunk/test/Preprocessor/riscv-target-features.c

Index: cfe/trunk/lib/CodeGen/TargetInfo.cpp
===
--- cfe/trunk/lib/CodeGen/TargetInfo.cpp
+++ cfe/trunk/lib/CodeGen/TargetInfo.cpp
@@ -9188,25 +9188,44 @@
 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::Type *&Field1Ty,
+  CharUnits &Field1Off,
+  llvm::Type *&Field2Ty,
+  CharUnits &Field2Off) const;
 
 public:
-  RISCVABIInfo(CodeGen::CodeGenTypes &CGT, unsigned XLen)
-  : DefaultABIInfo(CGT), XLen(XLen) {}
+  RISCVABIInfo(CodeGen::CodeGenTypes &CGT, unsigned XLen, unsigned FLen)
+  : DefaultABIInfo(CGT), XLen(XLen), FLen(FLen) {}
 
   // 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) const;
+  ABIArgInfo classifyArgumentType(QualType Ty, bool IsFixed, int &ArgGPRsLeft,
+  int &ArgFPRsLeft) const;
   ABIArgInfo classifyReturnType(QualType RetTy) const;
 
   Address EmitVAArg(CodeGenFunction &CGF, Address VAListAddr,
 QualType Ty) const override;
 
   ABIArgInfo extendType(QualType Ty) const;
+
+  bool detectFPCCEligibleStruct(QualType Ty, llvm::Type *&Field1Ty, CharUnits &Field1Off,
+llvm::Type *&Field2Ty, CharUnits &Field2Off,
+int &NeededArgGPRs, int &NeededArgFPRs) const;
+  ABIArgInfo coerceAndExpandFPCCEligibleStruct(llvm::Type *Field1Ty,
+   CharUnits Field1Off,
+   llvm::Type *Field2Ty,
+   CharUnits Field2Off) const;
 };
 } // end anonymous namespace
 
@@ -9228,18 +9247,214 @@
   // different 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();
 
   int ArgNum = 0;
   for (auto &ArgInfo : FI.arguments()) {
 bool IsFixed = ArgNum < NumFixedArgs;
-ArgInfo.info = classifyArgumentType(ArgInfo.type, IsFixed, ArgGPRsLeft);
+ArgInfo.info =
+classifyArgumentType(ArgInfo.type, IsFixed, ArgGPRsLeft, ArgFPRsLeft);
 ArgNum++;
   }
 }
 
+// Returns true if the struct is a potential candidate for the floating point
+// calling convention. If this function returns true, the caller is
+// responsible for checking that if there is only a single field then that
+// field is a float.
+bool RISCVABIInfo::detectFPCCEligibleStructHelper(QualType Ty, CharUnits CurOff,
+  llvm::Type *&Field1Ty,
+  CharUnits &Field1Off,
+  llvm::Type *&Field2Ty,
+  CharUnits &Field2Off) const {
+  bool IsInt = Ty->isIntegralOrEnumerationType();
+  bool IsFloat = Ty->isRealFloatingType();
+
+  if (IsInt || IsFloat) {
+uint64_t Size = getContext().getTy

[PATCH] D65500: [RISCV] Support 'f' Inline Assembly Constraint

[Alex Bradbury via Phabricator via cfe-commits]

asb accepted this revision.
asb added a comment.
This revision is now accepted and ready to land.

LGTM, thanks!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65500/new/

https://reviews.llvm.org/D65500



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

[PATCH] D65634: [RISCV] Default to lp64d in 64-bit RISC-V Linux

[Alex Bradbury via Phabricator via cfe-commits]

asb added a comment.

Thank Roger. While we're doing this, I think it would make sense to default to 
ilp32d on 32-bit Linux? I know the glibc support etc is less mature than for 
RV64, but it seems the sensible thing to do.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65634/new/

https://reviews.llvm.org/D65634



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

[PATCH] D65693: [driver][riscv] Support riscv64-linux-gnu multiarch paths

[Alex Bradbury via Phabricator via cfe-commits]

asb requested changes to this revision.
asb added a comment.
This revision now requires changes to proceed.

Many thanks for the patch. Could you please add some tests for this behaviour? 
I imagine you'll want to add a new directory in test/Driver/Inputs with a 
Debian tree skeleton. See D63497  for a 
relevant example.

Also, when submitting patches please try to generate the patch with -U9 
(see here 
) so we 
can see full context in the Phabricator Web UI.


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65693/new/

https://reviews.llvm.org/D65693



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

[PATCH] D65634: [RISCV] Default to ilp32d/lp64d in RISC-V Linux

[Alex Bradbury via Phabricator via cfe-commits]

asb added a comment.

In D65634#1618443 , @rogfer01 wrote:

> Thanks @asb @lenary for the review!
>
> I understand that, after this change, we will also want to make 
> `-march=rv{32,64}gc` the default in Linux as well. Otherwise there will be an 
> ABI mismatch with the default `-march=rv{32.64}i` in a default invocation.
>
> Does this make sense?


Yes, that makes sense to me.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65634/new/

https://reviews.llvm.org/D65634



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

[PATCH] D63498: [RISC-V] Add -msave-restore and -mno-save-restore to clang driver

[Alex Bradbury via Phabricator via cfe-commits]

asb accepted this revision.
asb added a comment.
This revision is now accepted and ready to land.

LGTM, thanks! There was some discussion about the potential stdout+stderr 
merging issues 
http://lists.llvm.org/pipermail/llvm-dev/2017-February/110469.html but I don't 
think it resulted in any new recommended best practice.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D63498/new/

https://reviews.llvm.org/D63498



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

[PATCH] D64008: [RISCV] Avoid save-restore target feature warning

[Alex Bradbury via Phabricator via cfe-commits]

asb accepted this revision.
asb added a comment.
This revision is now accepted and ready to land.

LGTM, thanks.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64008/new/

https://reviews.llvm.org/D64008



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

[PATCH] D63417: [RISCV] Specify registers used for exception handling

[Alex Bradbury via Phabricator via cfe-commits]

asb requested changes to this revision.
asb added a comment.
This revision now requires changes to proceed.

Could you please add a riscv64 RUN line too, for completeness? Other archs seem 
to call the equivalent test file `builtins-archname.c` rather than 
`builtin-archname.c`, so I'd adjust the naming to match.

Then this looks good to me. Thanks!


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D63417/new/

https://reviews.llvm.org/D63417



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

[PATCH] D63417: [RISCV] Specify registers used for exception handling

[Alex Bradbury via Phabricator via cfe-commits]

asb accepted this revision.
asb added a comment.
This revision is now accepted and ready to land.

Thanks, looks good to me!


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D63417/new/

https://reviews.llvm.org/D63417



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

[PATCH] D63417: [RISCV] Specify registers used for exception handling

[Alex Bradbury via Phabricator via cfe-commits]

asb added inline comments.



Comment at: test/CodeGen/builtins-riscv.c:4
+
+void test_eh_return_data_regno()
+{

Nit: having `{` on this line would be more consistent with usual LLVM style


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D63417/new/

https://reviews.llvm.org/D63417



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

[PATCH] D63417: [RISCV] Specify registers used for exception handling

[Alex Bradbury via Phabricator via cfe-commits]

asb added a comment.

Ed, if you haven't already could you request commit access so you can commit 
these approved patches yourself? See 
https://llvm.org/docs/DeveloperPolicy.html#obtaining-commit-access for details.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D63417/new/

https://reviews.llvm.org/D63417



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

[PATCH] D63497: Add support for openSUSE RISC-V triple

[Alex Bradbury via Phabricator via cfe-commits]

asb accepted this revision.
asb added a comment.
This revision is now accepted and ready to land.
Herald added a subscriber: lenary.

LGTM, thanks!


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D63497/new/

https://reviews.llvm.org/D63497



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

[PATCH] D60456: [RISCV] Hard float ABI support

[Alex Bradbury via Phabricator via cfe-commits]

asb added inline comments.



Comment at: clang/lib/CodeGen/TargetInfo.cpp:9232
+if (IsFloat && Size > FLen)
+  return false;
+// Can't be eligible if an integer type was already found (only fp+int or

rjmccall wrote:
> Is this the only consideration for floating-point types?  Clang does have 
> increasing support for `half` / various `float16` types.
These types aren't supported on RISC-V currently. As the ABI hasn't really been 
explicitly confirmed, I've defaulted to the integer ABI in that case. Could 
move to an assert if you prefer, though obviously any future move to enable 
half floats for RISC-V should include ABI tests too.



Comment at: clang/lib/CodeGen/TargetInfo.cpp:9236
+if (IsInt && Field1Ty && Field1Ty->isIntegerTy())
+  return false;
+if (!Field1Ty) {

rjmccall wrote:
> The comment here is wrong because fp+fp is allowed, right?
> 
> Is this not already caught by the post-processing checks you do in 
> `detectFPCCEligibleStruct`?  Would it make more sense to just do all those 
> checks there?
Thanks, I meant to say int+int isn't eligible. Reworded to say that.

I don't think it would simplify things to do all checks in 
detectFPCCEligibleStruct. More repetition would be required in order to do 
checks on both Float1Ty and Float2Ty.



Comment at: clang/lib/CodeGen/TargetInfo.cpp:9288
+  return false;
+for (const FieldDecl *FD : RD->fields()) {
+  const ASTRecordLayout &Layout = getContext().getASTRecordLayout(RD);

rjmccall wrote:
> I really expect there to be something in this block about whether the field 
> is a bit-field.  What exactly does your ABI specify if there's a bit-field?
I've updated to handle bitfields and submitted a [pull 
request](https://github.com/riscv/riscv-elf-psabi-doc/pull/100) to the RISC-V 
psABI to improve the documentation. Unfortunately the handling of zero-width 
bitfields is a little weird, but the preference seems to be to just document 
what GCC does.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D60456/new/

https://reviews.llvm.org/D60456



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

[PATCH] D63417: [RISCV] Specify registers used for exception handling

[Alex Bradbury via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL365305: [RISCV] Specify registers used for exception 
handling (authored by asb, committed by ).
Herald added subscribers: llvm-commits, lenary, MaskRay.
Herald added a project: LLVM.

Changed prior to commit:
  https://reviews.llvm.org/D63417?vs=207769&id=208339#toc

Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D63417/new/

https://reviews.llvm.org/D63417

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


Index: cfe/trunk/test/CodeGen/builtins-riscv.c
===
--- cfe/trunk/test/CodeGen/builtins-riscv.c
+++ cfe/trunk/test/CodeGen/builtins-riscv.c
@@ -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);
+}
Index: cfe/trunk/lib/Basic/Targets/RISCV.h
===
--- cfe/trunk/lib/Basic/Targets/RISCV.h
+++ cfe/trunk/lib/Basic/Targets/RISCV.h
@@ -57,6 +57,15 @@
 
   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,


Index: cfe/trunk/test/CodeGen/builtins-riscv.c
===
--- cfe/trunk/test/CodeGen/builtins-riscv.c
+++ cfe/trunk/test/CodeGen/builtins-riscv.c
@@ -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);
+}
Index: cfe/trunk/lib/Basic/Targets/RISCV.h
===
--- cfe/trunk/lib/Basic/Targets/RISCV.h
+++ cfe/trunk/lib/Basic/Targets/RISCV.h
@@ -57,6 +57,15 @@
 
   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,
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D60456: [RISCV] Hard float ABI support

[Alex Bradbury via Phabricator via cfe-commits]

asb updated this revision to Diff 208308.
asb marked 7 inline comments as done.
asb retitled this revision from "[RISCV][WIP/RFC] Hard float ABI support" to 
"[RISCV] Hard float ABI support".
asb edited the summary of this revision.
asb added a comment.
Herald added subscribers: lenary, Jim, MaskRay.

Address all review comments from @rjmccall. Bitfield handling matches observed 
behaviour of GCC and I have an active PR 
 to properly document 
this in the RISC-V psabi. Tests are updated to check this behaviour.

Many thanks for the review comments - do you think this is ready to land?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D60456/new/

https://reviews.llvm.org/D60456

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

Index: clang/test/Preprocessor/riscv-target-features.c
===
--- clang/test/Preprocessor/riscv-target-features.c
+++ clang/test/Preprocessor/riscv-target-features.c
@@ -47,3 +47,27 @@
 // RUN: %clang -target riscv64-unknown-linux-gnu -march=rv64ic -x c -E -dM %s \
 // RUN: -o - | FileCheck --check-prefix=CHECK-C-EXT %s
 // CHECK-C-EXT: __riscv_compressed 1
+
+// RUN: %clang -target riscv32-unknown-linux-gnu -march=rv32ifd -x c -E -dM %s \
+// RUN: -o - | FileCheck --check-prefix=CHECK-SOFT %s
+// RUN: %clang -target riscv64-unknown-linux-gnu -march=rv64ifd -x c -E -dM %s \
+// RUN: -o - | FileCheck --check-prefix=CHECK-SOFT %s
+// CHECK-SOFT: __riscv_float_abi_soft 1
+// CHECK-SOFT-NOT: __riscv_float_abi_single
+// CHECK-SOFT-NOT: __riscv_float_abi_double
+
+// RUN: %clang -target riscv32-unknown-linux-gnu -march=rv32ifd -mabi=ilp32f -x c -E -dM %s \
+// RUN: -o - | FileCheck --check-prefix=CHECK-SINGLE %s
+// RUN: %clang -target riscv64-unknown-linux-gnu -march=rv64ifd -mabi=lp64f -x c -E -dM %s \
+// RUN: -o - | FileCheck --check-prefix=CHECK-SINGLE %s
+// CHECK-SINGLE: __riscv_float_abi_single 1
+// CHECK-SINGLE-NOT: __riscv_float_abi_soft
+// CHECK-SINGLE-NOT: __riscv_float_abi_double
+
+// RUN: %clang -target riscv32-unknown-linux-gnu -march=rv32ifd -mabi=ilp32f -x c -E -dM %s \
+// RUN: -o - | FileCheck --check-prefix=CHECK-DOUBLE %s
+// RUN: %clang -target riscv64-unknown-linux-gnu -march=rv64ifd -mabi=lp64f -x c -E -dM %s \
+// RUN: -o - | FileCheck --check-prefix=CHECK-DOUBLE %s
+// CHECK-DOUBLE: __riscv_float_abi_double 1
+// CHECK-DOUBLE-NOT: __riscv_float_abi_soft
+// CHECK-DOUBLE-NOT: __riscv_float_abi_single
Index: clang/test/CodeGen/riscv64-lp64f-lp64d-abi.c
===
--- /dev/null
+++ clang/test/CodeGen/riscv64-lp64f-lp64d-abi.c
@@ -0,0 +1,265 @@
+// RUN: %clang_cc1 -triple riscv64 -target-feature +f -target-abi lp64f -emit-llvm %s -o - \
+// RUN: | FileCheck %s
+// RUN: %clang_cc1 -triple riscv64 -target-feature +d -target-abi lp64d -emit-llvm %s -o - \
+// RUN: | FileCheck %s
+
+#include 
+
+// Verify that the tracking of used GPRs and FPRs works correctly by checking
+// that small integers are sign/zero extended when passed in registers.
+
+// Floats are passed in FPRs, so argument 'i' will be passed zero-extended
+// because it will be passed in a GPR.
+
+// CHECK: define void @f_fpr_tracking(float %a, float %b, float %c, float %d, float %e, float %f, float %g, float %h, i8 zeroext %i)
+void f_fpr_tracking(float a, float b, float c, float d, float e, float f,
+float g, float h, uint8_t i) {}
+
+// 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).
+
+// A struct containing just one floating-point real is passed as though it
+// were a standalone floating-point real.
+
+struct float_s { float f; };
+
+// CHECK: define void @f_float_s_arg(float)
+void f_float_s_arg(struct float_s a) {}
+
+// CHECK: define float @f_ret_float_s()
+struct float_s f_ret_float_s() {
+  return (struct float_s){1.0};
+}
+
+// A struct containing a float and any number of zero-width bitfields is
+// passed as though it were a standalone floating-point real.
+
+struct zbf_float_s { int : 0; flo

[PATCH] D60456: [RISCV] Hard float ABI support

[Alex Bradbury via Phabricator via cfe-commits]

asb marked an inline comment as done.
asb added inline comments.



Comment at: clang/lib/CodeGen/TargetInfo.cpp:9352
+return false;
+  // As a quirk of the ABI, zero-width bitfields aren't ignored for fp+fp
+  // or int+fp structs, but are ignored for a struct with an fp field and

rogfer01 wrote:
> I found some mismatch in behaviour between gcc and g++ that we may want to 
> address in the psABI first.
> 
> For instance, given the following struct (I'm using gcc 8.3.0)
> 
> ```lang=cpp
> // t.c
> struct A
> {
>   int :0;
>   double d;
>   int :0;
>   long x;
>   int :0;
> };
> 
> extern void bar(struct A);
> void foo(struct A a)
> {
>   a.d =- a.d;
>   a.x += 1;
>   return bar(a);
> }
> ```
> 
> we are emitting this
> 
> ```
> $ clang --target=riscv64 -march=rv64gc -mabi=lp64d -S -o-  t.c -O2  
> ...
> foo:# @foo
> # %bb.0:# %entry
> addia2, zero, -1
> sllia2, a2, 63
> xor a0, a0, a2
> addia1, a1, 1
> tailbar
> ```
> 
> which matches with what g++ does (i.e in both cases `a0` is `a.d` and `a1` is 
> `a.x`)
> 
> ```
> $ ./riscv64-unknown-linux-gnu-g++ -S -O2 -o- -x c test.cc
> ...
> foo:
>   fmv.d.x fa5,a0
>   addisp,sp,-16
>   fneg.d  fa5,fa5
>   addia1,a1,1
>   addisp,sp,16
>   fmv.x.d a0,fa5
>   tailbar
> ```
> 
> But I found a mismatch while using C++. Clang emits the same for C and C++ 
> (modulo `.cfi` stuff)
> 
> ```
> $ clang --target=riscv64 -march=rv64gc -mabi=lp64d -S -o-  -x c++ t.c -O2  
> _Z3foo1A:   # @_Z3foo1A
> .cfi_startproc
> # %bb.0:# %entry
> addia2, zero, -1
> sllia2, a2, 63
> xor a0, a0, a2
> addia1, a1, 1
> .cfi_def_cfa_offset 0
> tail_Z3bar1A
> ```
> 
> But g++ seems to ignore the zero-width bitfields: `fa0` is  `a.d` and `a0` is 
> `a.x`
> 
> ```
> $ riscv64-unknown-linux-gnu-g++  -S -O2 -x c++ t.c -o-
> ...
> _Z3foo1A:
> .LFB0:
> .cfi_startproc
> fneg.d  fa0,fa0
> addisp,sp,-16
> .cfi_def_cfa_offset 16
> addia0,a0,1
> addisp,sp,16
> .cfi_def_cfa_offset 0
> tail_Z3bar1A
> .cfi_endproc
> ```
> 
> This is a bit worrying as it might complicate interoperability between C and 
> C++ (I tried wrapping everything inside an `extern "C"` just in case but it 
> didn't change g++'s behaviour).
> 
> Do you mind to confirm this issue?
Thanks, I'm seeing this in GCC 9.1.0 as well. I left[ a 
comment](https://github.com/riscv/riscv-elf-psabi-doc/issues/99#issuecomment-509233798)
 on the relevant psABI issue. It seems there is a GCC bug here, but hopefully 
someone can confirm what the "correct" behaviour is.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D60456/new/

https://reviews.llvm.org/D60456



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

[PATCH] D60456: [RISCV] Hard float ABI support

[Alex Bradbury via Phabricator via cfe-commits]

asb updated this revision to Diff 208392.
asb marked an inline comment as done.
asb added a comment.

Updated to address comment typo picked up by @rogfer01 (thanks!).

As noted in another comment, it's not entirely clear what zero-width bitfield 
behaviour to match (see here 
)
 as GCC seems buggy and the ABI is under-specified. Ideally I'd like to land 
this patch and follow-up to adjust the zero-width bitfield behaviour if 
necessary once that psABI issue is resolved.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D60456/new/

https://reviews.llvm.org/D60456

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

Index: clang/test/Preprocessor/riscv-target-features.c
===
--- clang/test/Preprocessor/riscv-target-features.c
+++ clang/test/Preprocessor/riscv-target-features.c
@@ -47,3 +47,27 @@
 // RUN: %clang -target riscv64-unknown-linux-gnu -march=rv64ic -x c -E -dM %s \
 // RUN: -o - | FileCheck --check-prefix=CHECK-C-EXT %s
 // CHECK-C-EXT: __riscv_compressed 1
+
+// RUN: %clang -target riscv32-unknown-linux-gnu -march=rv32ifd -x c -E -dM %s \
+// RUN: -o - | FileCheck --check-prefix=CHECK-SOFT %s
+// RUN: %clang -target riscv64-unknown-linux-gnu -march=rv64ifd -x c -E -dM %s \
+// RUN: -o - | FileCheck --check-prefix=CHECK-SOFT %s
+// CHECK-SOFT: __riscv_float_abi_soft 1
+// CHECK-SOFT-NOT: __riscv_float_abi_single
+// CHECK-SOFT-NOT: __riscv_float_abi_double
+
+// RUN: %clang -target riscv32-unknown-linux-gnu -march=rv32ifd -mabi=ilp32f -x c -E -dM %s \
+// RUN: -o - | FileCheck --check-prefix=CHECK-SINGLE %s
+// RUN: %clang -target riscv64-unknown-linux-gnu -march=rv64ifd -mabi=lp64f -x c -E -dM %s \
+// RUN: -o - | FileCheck --check-prefix=CHECK-SINGLE %s
+// CHECK-SINGLE: __riscv_float_abi_single 1
+// CHECK-SINGLE-NOT: __riscv_float_abi_soft
+// CHECK-SINGLE-NOT: __riscv_float_abi_double
+
+// RUN: %clang -target riscv32-unknown-linux-gnu -march=rv32ifd -mabi=ilp32f -x c -E -dM %s \
+// RUN: -o - | FileCheck --check-prefix=CHECK-DOUBLE %s
+// RUN: %clang -target riscv64-unknown-linux-gnu -march=rv64ifd -mabi=lp64f -x c -E -dM %s \
+// RUN: -o - | FileCheck --check-prefix=CHECK-DOUBLE %s
+// CHECK-DOUBLE: __riscv_float_abi_double 1
+// CHECK-DOUBLE-NOT: __riscv_float_abi_soft
+// CHECK-DOUBLE-NOT: __riscv_float_abi_single
Index: clang/test/CodeGen/riscv64-lp64f-lp64d-abi.c
===
--- /dev/null
+++ clang/test/CodeGen/riscv64-lp64f-lp64d-abi.c
@@ -0,0 +1,265 @@
+// RUN: %clang_cc1 -triple riscv64 -target-feature +f -target-abi lp64f -emit-llvm %s -o - \
+// RUN: | FileCheck %s
+// RUN: %clang_cc1 -triple riscv64 -target-feature +d -target-abi lp64d -emit-llvm %s -o - \
+// RUN: | FileCheck %s
+
+#include 
+
+// Verify that the tracking of used GPRs and FPRs works correctly by checking
+// that small integers are sign/zero extended when passed in registers.
+
+// Floats are passed in FPRs, so argument 'i' will be passed zero-extended
+// because it will be passed in a GPR.
+
+// CHECK: define void @f_fpr_tracking(float %a, float %b, float %c, float %d, float %e, float %f, float %g, float %h, i8 zeroext %i)
+void f_fpr_tracking(float a, float b, float c, float d, float e, float f,
+float g, float h, uint8_t i) {}
+
+// 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).
+
+// A struct containing just one floating-point real is passed as though it
+// were a standalone floating-point real.
+
+struct float_s { float f; };
+
+// CHECK: define void @f_float_s_arg(float)
+void f_float_s_arg(struct float_s a) {}
+
+// CHECK: define float @f_ret_float_s()
+struct float_s f_ret_float_s() {
+  return (struct float_s){1.0};
+}
+
+// A struct containing a float and any number of zero-width bitfields is
+// passed as though it were a standalone floating-point real.
+
+struct zbf_float_s { int : 0; float f; };
+struct zbf_float_zbf_s { int : 0; float f; int : 0; };
+
+// CHECK: define void @f

[PATCH] D60456: [RISCV] Hard float ABI support

[Alex Bradbury via Phabricator via cfe-commits]

asb added inline comments.



Comment at: clang/lib/CodeGen/TargetInfo.cpp:9236
+if (IsInt && Field1Ty && Field1Ty->isIntegerTy())
+  return false;
+if (!Field1Ty) {

rjmccall wrote:
> asb wrote:
> > rjmccall wrote:
> > > The comment here is wrong because fp+fp is allowed, right?
> > > 
> > > Is this not already caught by the post-processing checks you do in 
> > > `detectFPCCEligibleStruct`?  Would it make more sense to just do all 
> > > those checks there?
> > Thanks, I meant to say int+int isn't eligible. Reworded to say that.
> > 
> > I don't think it would simplify things to do all checks in 
> > detectFPCCEligibleStruct. More repetition would be required in order to do 
> > checks on both Float1Ty and Float2Ty.
> Okay.  It just seemed to me that responsibility was oddly split between the 
> functions.
I added a comment to document this. It's not something I'd expose in a public 
API, but I think it's defensible to catch this case outside of the helper. I 
had another look at refactoring but the readability just seemed to be reduced 
when pulling out all the checks to the caller (rather than catching the single 
case that detectFPCCEligibleStructHelper can't handle).



Comment at: clang/lib/CodeGen/TargetInfo.cpp:9340
+if (getContext().getTypeSize(QTy) > XLen && BitWidth <= XLen)
+  QTy = getContext().getIntTypeForBitwidth(XLen, false);
+if (BitWidth == 0) {

rjmccall wrote:
> Okay.  So consecutive bit-fields are considered individually, not packed into 
> a single storage unit and then considered?  Unfortunate ABI rule, but if it's 
> what you have to implement, so be it.
I'm afraid that's the rule as written, and what gcc seems to implement.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D60456/new/

https://reviews.llvm.org/D60456



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

[PATCH] D60456: [RISCV] Hard float ABI support

[Alex Bradbury via Phabricator via cfe-commits]

asb updated this revision to Diff 208477.
asb marked 4 inline comments as done.
asb added a comment.

Tweaked a code comment.

Just to confirm, @rjmccall are you happy for me to commit this?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D60456/new/

https://reviews.llvm.org/D60456

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

Index: clang/test/Preprocessor/riscv-target-features.c
===
--- clang/test/Preprocessor/riscv-target-features.c
+++ clang/test/Preprocessor/riscv-target-features.c
@@ -47,3 +47,27 @@
 // RUN: %clang -target riscv64-unknown-linux-gnu -march=rv64ic -x c -E -dM %s \
 // RUN: -o - | FileCheck --check-prefix=CHECK-C-EXT %s
 // CHECK-C-EXT: __riscv_compressed 1
+
+// RUN: %clang -target riscv32-unknown-linux-gnu -march=rv32ifd -x c -E -dM %s \
+// RUN: -o - | FileCheck --check-prefix=CHECK-SOFT %s
+// RUN: %clang -target riscv64-unknown-linux-gnu -march=rv64ifd -x c -E -dM %s \
+// RUN: -o - | FileCheck --check-prefix=CHECK-SOFT %s
+// CHECK-SOFT: __riscv_float_abi_soft 1
+// CHECK-SOFT-NOT: __riscv_float_abi_single
+// CHECK-SOFT-NOT: __riscv_float_abi_double
+
+// RUN: %clang -target riscv32-unknown-linux-gnu -march=rv32ifd -mabi=ilp32f -x c -E -dM %s \
+// RUN: -o - | FileCheck --check-prefix=CHECK-SINGLE %s
+// RUN: %clang -target riscv64-unknown-linux-gnu -march=rv64ifd -mabi=lp64f -x c -E -dM %s \
+// RUN: -o - | FileCheck --check-prefix=CHECK-SINGLE %s
+// CHECK-SINGLE: __riscv_float_abi_single 1
+// CHECK-SINGLE-NOT: __riscv_float_abi_soft
+// CHECK-SINGLE-NOT: __riscv_float_abi_double
+
+// RUN: %clang -target riscv32-unknown-linux-gnu -march=rv32ifd -mabi=ilp32f -x c -E -dM %s \
+// RUN: -o - | FileCheck --check-prefix=CHECK-DOUBLE %s
+// RUN: %clang -target riscv64-unknown-linux-gnu -march=rv64ifd -mabi=lp64f -x c -E -dM %s \
+// RUN: -o - | FileCheck --check-prefix=CHECK-DOUBLE %s
+// CHECK-DOUBLE: __riscv_float_abi_double 1
+// CHECK-DOUBLE-NOT: __riscv_float_abi_soft
+// CHECK-DOUBLE-NOT: __riscv_float_abi_single
Index: clang/test/CodeGen/riscv64-lp64f-lp64d-abi.c
===
--- /dev/null
+++ clang/test/CodeGen/riscv64-lp64f-lp64d-abi.c
@@ -0,0 +1,265 @@
+// RUN: %clang_cc1 -triple riscv64 -target-feature +f -target-abi lp64f -emit-llvm %s -o - \
+// RUN: | FileCheck %s
+// RUN: %clang_cc1 -triple riscv64 -target-feature +d -target-abi lp64d -emit-llvm %s -o - \
+// RUN: | FileCheck %s
+
+#include 
+
+// Verify that the tracking of used GPRs and FPRs works correctly by checking
+// that small integers are sign/zero extended when passed in registers.
+
+// Floats are passed in FPRs, so argument 'i' will be passed zero-extended
+// because it will be passed in a GPR.
+
+// CHECK: define void @f_fpr_tracking(float %a, float %b, float %c, float %d, float %e, float %f, float %g, float %h, i8 zeroext %i)
+void f_fpr_tracking(float a, float b, float c, float d, float e, float f,
+float g, float h, uint8_t i) {}
+
+// 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).
+
+// A struct containing just one floating-point real is passed as though it
+// were a standalone floating-point real.
+
+struct float_s { float f; };
+
+// CHECK: define void @f_float_s_arg(float)
+void f_float_s_arg(struct float_s a) {}
+
+// CHECK: define float @f_ret_float_s()
+struct float_s f_ret_float_s() {
+  return (struct float_s){1.0};
+}
+
+// A struct containing a float and any number of zero-width bitfields is
+// passed as though it were a standalone floating-point real.
+
+struct zbf_float_s { int : 0; float f; };
+struct zbf_float_zbf_s { int : 0; float f; int : 0; };
+
+// CHECK: define void @f_zbf_float_s_arg(float)
+void f_zbf_float_s_arg(struct zbf_float_s a) {}
+
+// CHECK: define float @f_ret_zbf_float_s()
+struct zbf_float_s f_ret_zbf_float_s() {
+  return (struct zbf_float_s){1.0};
+}
+
+// CHECK: define void @f_zbf_float_zbf_s_arg(float)
+void f_zbf_float_zbf_s_arg(struct zbf_float_zbf_s a) {}
+
+// CHECK: define float @f_ret_zbf_float_zbf_s()

[PATCH] D60456: [RISCV] Hard float ABI support

[Alex Bradbury via Phabricator via cfe-commits]

asb added a comment.

Thanks for the careful review John, I really appreciate it!


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D60456/new/

https://reviews.llvm.org/D60456



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

[PATCH] D45237: [RISCV] Fix logic to check if frame pointer should be used

[Alex Bradbury via Phabricator via cfe-commits]

asb accepted this revision.
asb added a comment.
This revision is now accepted and ready to land.

Thanks, looks good to me.


https://reviews.llvm.org/D45237



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

[PATCH] D45284: [RISCV] More validations on the input value of -march=

[Alex Bradbury via Phabricator via cfe-commits]

asb added a comment.

I've added a few comments on tweaking the error messages based on your tests.




Comment at: test/Driver/riscv-arch.c:157
+// RV32-STR: error: invalid arch name 'rv32',
+// RV32-STR: string must begin with rv32 or rv64
+

But the given string does begin with rv32. 'string must begin with rv32{i,e,g} 
or rv64{i,g}'?



Comment at: test/Driver/riscv-arch.c:167
+// RV32-ORDER: error: invalid arch name 'rv32imcq',
+// RV32-ORDER: unsupported  canonical order of extension 'q'
+

I don't think this message is clear, specifically 'unsupported canonical 
order...'. How about 'error: standard extension not given in canonical order'



Comment at: test/Driver/riscv-arch.c:203
+// RV32SX-NAME: unsupported non-standard supervisor-level extension
+// RV32SX-NAME: name missing 'sx'
+

I think this would be clearer if you said "name missing after 'sx'"



Comment at: test/Driver/riscv-arch.c:208
+// RV32S-NAME: error: invalid arch name 'rv32is',
+// RV32S-NAME:unsupported standard supervisor-level extension name missing 's'
+

Ditto.



Comment at: test/Driver/riscv-arch.c:213
+// RV32ALL-NAME: error: invalid arch name 'rv32ix_s_sx',
+// RV32ALL-NAME: unsupported non-standard user-level extension name missing 'x'
+

Ditto.


https://reviews.llvm.org/D45284



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

[PATCH] D44888: [RISCV] Default enable linker relaxation and add -mrelax, -mno-relax flags

[Alex Bradbury via Phabricator via cfe-commits]

asb added a comment.

Looks good to me, just missing help text on the command line options.


Repository:
  rL LLVM

https://reviews.llvm.org/D44888



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

[PATCH] D45284: [RISCV] More validations on the input value of -march=

[Alex Bradbury via Phabricator via cfe-commits]

asb added inline comments.



Comment at: lib/Driver/ToolChains/Arch/RISCV.cpp:50
+
+static void getExtensionVersion(StringRef In, std::string &Version) {
+  auto I = In.begin();

You should probably document the limitation that this doesn't currently parse 
minor versions e.g. i2p0.



Comment at: lib/Driver/ToolChains/Arch/RISCV.cpp:144-146
+  // Currently LLVM does not support 'e'.
+  D.Diag(diag::err_drv_invalid_riscv_arch_name)
+<< MArch << "unsupported standard user-level extension 'e'";

This could be tightened up by also rejected rv64e as invalid.



Comment at: lib/Driver/ToolChains/Arch/RISCV.cpp:201-202
+  if (StdExtsItr == StdExtsEnd) {
+size_t Pos;
+if (hasExtension(StdExts, std::string(1, c), Pos)) {
+  D.Diag(diag::err_drv_invalid_riscv_ext_arch_name)

I'd suggest either just using StringRef::contains and getting rid of 
hasExtension, or adding a doc comment to hasExtension to explain its semantics.

It might also be worth adding a comment to explain why you want to check the 
extension is present in the StdExts string (e.g. We have reached the end of the 
StdExts string. Either the current extension was given outside of the canonical 
order (in which case issue an error), or else no canonical ordering is defined 
meaning no error should be generated'.



Comment at: lib/Driver/ToolChains/Arch/RISCV.cpp:211
   // Move to next char to prevent repeated letter.
   ++StdExtsItr;
 

Won't this now iterate StdExtsItr past StdExtsEnd if StdExtsItr == StdExtsEnd 
but the hasExtension call is false?



Comment at: lib/Driver/ToolChains/Arch/RISCV.cpp:265-267
 if (HasD && !HasF)
-  D.Diag(diag::err_drv_invalid_arch_name) << MArch;
+  D.Diag(diag::err_drv_invalid_riscv_arch_name) << MArch
+<< "d requires f extension to also be specified";

Add a TODO about other dependencies perhaps? e.g. ef and efd are invalid, and q 
requires rv64.


https://reviews.llvm.org/D45284



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

[PATCH] D44888: [RISCV] Default enable linker relaxation and add -mrelax, -mno-relax flags

[Alex Bradbury via Phabricator via cfe-commits]

asb requested changes to this revision.
asb added a comment.
This revision now requires changes to proceed.

Thanks Kito. -mrelax and -mno-relax currently only affect the backend. For 
completeness, I think this patch needs to pass the appropriate flag to the 
linker depending on relax/no-relax.


Repository:
  rL LLVM

https://reviews.llvm.org/D44888



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

[PATCH] D45284: [RISCV] More validations on the input value of -march=

[Alex Bradbury via Phabricator via cfe-commits]

asb added a comment.
Herald added a subscriber: edward-jones.

This is looking great, the only remaining code comment I have is that 
getExtensionFeatures needs a comment describing it.

The remaining issue I have is more of a spec issue - do canonical ordering 
requirements apply to extension categories? e.g. is sfoo_xbar illegal because 
it should be ordered xbar_sfoo? From my reading of the note below table 22.1 in 
the spec I think it is illegal and ordering of non-standard user-level vs 
standard supervisor-level vs nons-standard supervisor-level should be checked. 
Do you agree with my interpretation?


https://reviews.llvm.org/D45284



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

[PATCH] D39053: [Bitfield] Add more cases to making the bitfield a separate location

[Alex Bradbury via Phabricator via cfe-commits]

asb added a comment.

Hi @spetrovic - I think Hal Finkel's earlier request to update the comments of 
IsBetterAsSingleFieldRun remains unaddressed. It looks like at least the 
comment string immediately before `auto IsBetterAsSingleFieldRun` needs to be 
updated to reflect the changed behaviour.

The documentation `-ffine-grained-bitfield-accesses` option may also need to be 
updated. Iit currently reads "Use separate accesses for bitfields with legal 
widths and alignments.". I think "Use separate accesses for consecutive 
bitfield runs with legal widths and alignments" might better reflect the 
behaviour after this patch. Do you agree?


https://reviews.llvm.org/D39053



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

[PATCH] D45284: [RISCV] More validations on the input value of -march=

[Alex Bradbury via Phabricator via cfe-commits]

asb added a comment.

In https://reviews.llvm.org/D45284#1074282, @apazos wrote:

> Hi Alex, it seems the table expects these extensions in a canonical order 
> too: all x extensions, followed by all s extensions, and then all sx 
> extensions.
>
> I can make the change, no problem. I have also coded other error situations 
> described below.
>
> But f I cannot push a test we can enable, because we error out when we find 
> the first non-supported extension in the string with unsupported extension 
> message, and stop parsing the string.


In the best case we would first parse the string and give errors based on the 
string being malformed before determining which extensions the compiler 
supports and complaining if the extension is not supported. This would probably 
move us towards a two-pass scheme where structs are are generated from the 
string, (parsing stage) which are then processed. e.g. `{ enum ExtType Type; 
StringRef name; int MajorVersion; int MinorVersion; }`. The parser can issue 
errors encountered when extracting this struct (e.g. malformed version 
identifiers), including erroring if the ordering of the ExtType relative to the 
previous ExtType is unexpected. The next step is complaining about semantic 
issues (clashing extensions or extensions with missing dependencies) as well as 
extensions that aren't supported.

However I realise that might be a larger refactoring. This is already the most 
complete RISC-V ISA string parser in existence (as far as I know), which goes 
some way beyond our near-term requirements. I'd be happy to merge this current 
version and evolve it in-tree if you prefer, or of course I'll happily review 
further updates to this patch.


https://reviews.llvm.org/D45284



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

[PATCH] D45284: [RISCV] More validations on the input value of -march=

[Alex Bradbury via Phabricator via cfe-commits]

asb accepted this revision.
asb added a comment.
This revision is now accepted and ready to land.

Looks good to me - thanks!


https://reviews.llvm.org/D45284



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

[PATCH] D67185: [RISCV] Add support for -ffixed-xX flags

[Alex Bradbury via Phabricator via cfe-commits]

asb added a comment.

In D67185#1707849 , @lenary wrote:

> Note, D68862  is in-progress at the moment, 
> which is related to this patch.


Indeed - Simon, could you please go through that patch and ensure that the 
implementation here is aligned to it (or indeed, feed back on that patch if you 
feel they should be doing something differently). Thanks!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D67185/new/

https://reviews.llvm.org/D67185



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

[PATCH] D71124: [RISCV] support clang driver to select cpu

[Alex Bradbury via Phabricator via cfe-commits]

asb accepted this revision.
asb added a comment.

LGTM, thanks!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D71124/new/

https://reviews.llvm.org/D71124



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

[PATCH] D73891: [RISCV] Support experimental/unratified extensions

[Alex Bradbury via Phabricator via cfe-commits]

asb added a comment.

I've approved D65649  now, so I think this one 
can land as soon as that one does.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D73891/new/

https://reviews.llvm.org/D73891



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

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

[Alex Bradbury via Phabricator via cfe-commits]

asb added a comment.

Ping on this. The patch still applies cleanly against current HEAD.

@efriedma: was your comment an LGTM?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D79155/new/

https://reviews.llvm.org/D79155



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

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

[Alex Bradbury via Phabricator via cfe-commits]

asb added a comment.

In D79155#2088191 , @efriedma wrote:

> Please add a comment explaining what OffsetInRecord means; then LGTM.


Thanks. It's not easy to follow, but having stepped through it I agree with yu 
that it is the size in bits of the current run. I'll add that comment and 
commit.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D79155/new/

https://reviews.llvm.org/D79155



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

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

[Alex Bradbury via Phabricator via cfe-commits]

This revision was not accepted when it landed; it landed in state "Needs 
Review".
This revision was automatically updated to reflect the committed changes.
Closed by commit rG3dcfd482cb17: [CodeGen] Increase applicability of 
ffine-grained-bitfield-accesses for targets… (authored by asb).

Changed prior to commit:
  https://reviews.llvm.org/D79155?vs=261138&id=270344#toc

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D79155/new/

https://reviews.llvm.org/D79155

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


Index: clang/test/CodeGenCXX/finegrain-bitfield-type.cpp
===
--- clang/test/CodeGenCXX/finegrain-bitfield-type.cpp
+++ 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 @@
 // 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 }
Index: clang/lib/CodeGen/CGRecordLayoutBuilder.cpp
===
--- clang/lib/CodeGen/CGRecordLayoutBuilder.cpp
+++ clang/lib/CodeGen/CGRecordLayoutBuilder.cpp
@@ -406,15 +406,17 @@
 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.


Index: clang/test/CodeGenCXX/finegrain-bitfield-type.cpp
===
--- clang/test/CodeGenCXX/finegrain-bitfield-type.cpp
+++ 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 @@
 // 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 }
Index: clang/lib/CodeGen/CGRecordLayoutBuilder.cpp
===
--- clang/lib/CodeGen/CGRecordLayoutBuilder.cpp
+++ clang/lib/CodeGen/CGRecordLayoutBuilder.cpp
@@ -406,15 +406,17 @@
 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,
  

[PATCH] D71124: [RISCV] support clang driver to select cpu

[Alex Bradbury via Phabricator via cfe-commits]

asb added a comment.

This has been hanging around for a while, but I think we'd basically agreed 
this is the right logic. The comments have ended up referring to flags that 
don't exist on Clang making it a little hard to follow, and I've added a 
request to slightly expand testing. If you make those cleanups I think it 
should be ready for a final review and merge.

As Sam says, lets flag this in today's RISC-V LLVM call to double-check 
everyone is happy.




Comment at: clang/lib/Driver/ToolChains/Arch/RISCV.cpp:622
+  // 1. Explicit choices using `--with-arch=`
+  // 2. Based on `-mcpu` if target cpu has default isa extension feature
+  // 3. A default based on `--with-abi=`, if provided

As clang has no with-arch or with-abi, this comment seems inaccurate?



Comment at: clang/test/Driver/riscv-cpus.c:2
+// Check target CPUs are correctly passed.
+
+// RUN: %clang -target riscv32 -### -c %s 2>&1 -mcpu=rocket-rv32 | FileCheck 
-check-prefix=MCPU-ROCKETCHIP32 %s

I think for completeness this test should be validating the interaction of the 
ABI choosing logic with CPU selection as well. With the implemented logic I 
believe it should show that lp64d is selected for -mcpu=sifive-u54 and that 
-mcpu=sifive-u54 -mabi=lp64 will respect the ABI choice


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D71124/new/

https://reviews.llvm.org/D71124



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

[PATCH] D80802: [RISCV] Upgrade RVV MC to v0.9.

[Alex Bradbury via Phabricator via cfe-commits]

asb added a comment.

I've gone through and can't see any obvious issues. I defer to one of the 
RISC-V Vector extension usual suspects for giving a LGTM on the detail of the 
altered instructions etc. Once we have that, this looks good to land IMHO.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D80802/new/

https://reviews.llvm.org/D80802



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

[PATCH] D81583: Update SystemZ ABI to handle C++20 [[no_unique_address]] attribute

[Alex Bradbury via Phabricator via cfe-commits]

asb added a comment.

This LGTM from a RISC-V perspective. I'll likely follow up with a RISC-V test 
case similar to the SystemZ one post-commit, but given this is really fixing a 
cross-platform ABI issue this seems non-urgent. Thanks for spotting and 
addressing this issue.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D81583/new/

https://reviews.llvm.org/D81583



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

[PATCH] D71124: [RISCV] support clang driver to select cpu

[Alex Bradbury via Phabricator via cfe-commits]

asb added a comment.

I've added some suggestions to clarify the code comments. I think before 
landing it would be good to address the crash Sam pointed out for an invalid 
-march, but otherwise I think this looks good to me (at least, it seems worth 
landing this and if further issues crop up we can fix them and request them for 
merging into the LLVM 11 branch).




Comment at: clang/lib/Driver/ToolChains/Arch/RISCV.cpp:556
   //
-  // The logic uses the following, in order:
+  // The logic uses in GCC 9.2.0 as the following, in order:
   // 1. Explicit choices using `--with-abi=`

"The logic used in GCC 9.2.0 i the following, in order:"



Comment at: clang/lib/Driver/ToolChains/Arch/RISCV.cpp:566
+  //
+  // In order to make chosing logic more clear, clang uses the following logic,
+  // in order:

"Clang uses the following logic;"



Comment at: clang/lib/Driver/ToolChains/Arch/RISCV.cpp:569
+  // 1. Explicit choices using `-mabi=`
+  // 2. A default based on clang's choosing arch logic. The order of default
+  // arch login is `-march`, `-mcpu` and target triples`.

"A default based on the architecture as determined by getRISCVArch"



Comment at: clang/lib/Driver/ToolChains/Arch/RISCV.cpp:576
 
-  // 2. Choose a default based on `-march=`
+  // 2. Choose a default based on clang's choosing arch logic.
   //

"Choose a default based on the target architecture"



Comment at: clang/lib/Driver/ToolChains/Arch/RISCV.cpp:615
   //
-  // The logic uses the following, in order:
+  // The logic uses in GCC 9.2.0 as the following, in order:
   // 1. Explicit choices using `--with-arch=`

"The logic used in GCC 9.2.0 is the following, in order:"



Comment at: clang/lib/Driver/ToolChains/Arch/RISCV.cpp:627
+  // 1. Explicit choices using `-march=`
+  // 2. Based on `-mcpu` if target cpu has default isa extension feature
+  // 3. A default based on `-mabi`, if provided

Based on `-mcpu` if the target CPU has a default ISA string



Comment at: clang/lib/Driver/ToolChains/Arch/RISCV.h:29
const llvm::Triple &Triple);
+StringRef getMArchFromMabi(StringRef MABI);
+StringRef getMArchFromTriple(const llvm::Triple &Triple);

These functions aren't defined anywhere - delete?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D71124/new/

https://reviews.llvm.org/D71124



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

[PATCH] D83819: [RISCV] Add error checking for extensions missing separating underscores

[Alex Bradbury via Phabricator via cfe-commits]

asb accepted this revision.
asb added a comment.
This revision is now accepted and ready to land.

LGTM, thanks!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D83819/new/

https://reviews.llvm.org/D83819



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

[PATCH] D69987: [RISCV] Assemble/Disassemble v-ext instructions.

[Alex Bradbury via Phabricator via cfe-commits]

asb accepted this revision.
asb added a comment.
This revision is now accepted and ready to land.

In D69987#2079524 , @rogfer01 wrote:

> The patch as it stands now LGTM and I think it can be committed. Is there any 
> objection remaining?
>
> Any further comments @simoncook @asb?


This LGTM - thanks @HsiangKai and everyone who's been working on this. As Simon 
said before, it's really nicely laid out which makes it much easier to review.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D69987/new/

https://reviews.llvm.org/D69987



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

[PATCH] D69987: [RISCV] Assemble/Disassemble v-ext instructions.

[Alex Bradbury via Phabricator via cfe-commits]

asb added inline comments.



Comment at: llvm/lib/Target/RISCV/RISCVInstrInfoV.td:9
+///
+/// This file describes the RISC-V instructions from the standard 'V',
+/// Vector instruction set extension.

Please add similar language as in RISCVInstrInfoB.td to indicate the version 
being described and explain this version is experimental and hasn't been 
ratified.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D69987/new/

https://reviews.llvm.org/D69987



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

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

[Alex Bradbury via Phabricator via cfe-commits]

asb created this revision.
asb added reviewers: wmi, hfinkel, efriedma.
Herald added subscribers: cfe-commits, luismarques, sameer.abuasal, s.egerton, 
lenary, PkmX, simoncook.
Herald added a project: clang.
asb added a subscriber: apazos.

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.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D79155

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


Index: clang/test/CodeGenCXX/finegrain-bitfield-type.cpp
===
--- clang/test/CodeGenCXX/finegrain-bitfield-type.cpp
+++ 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 @@
 // 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 }
Index: clang/lib/CodeGen/CGRecordLayoutBuilder.cpp
===
--- clang/lib/CodeGen/CGRecordLayoutBuilder.cpp
+++ clang/lib/CodeGen/CGRecordLayoutBuilder.cpp
@@ -414,7 +414,8 @@
   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.


Index: clang/test/CodeGenCXX/finegrain-bitfield-type.cpp
===
--- clang/test/CodeGenCXX/finegrain-bitfield-type.cpp
+++ 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 @@
 // 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 }
Index: clang/lib/CodeGen/CGRecordLayoutBuilder.cpp
===
--- clang/lib/CodeGen/CGRecordLayoutBuilder.cpp
+++ clang/lib/CodeGen/CGRecordLayoutBuilder.cpp
@@ -414,7 +414,8 @@
   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.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Alex Bradbury via Phabricator via cfe-commits]

asb updated this revision to Diff 261138.
asb added a comment.

Updated patch to include full context.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D79155/new/

https://reviews.llvm.org/D79155

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


Index: clang/test/CodeGenCXX/finegrain-bitfield-type.cpp
===
--- clang/test/CodeGenCXX/finegrain-bitfield-type.cpp
+++ 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 @@
 // 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 }
Index: clang/lib/CodeGen/CGRecordLayoutBuilder.cpp
===
--- clang/lib/CodeGen/CGRecordLayoutBuilder.cpp
+++ clang/lib/CodeGen/CGRecordLayoutBuilder.cpp
@@ -414,7 +414,8 @@
   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.


Index: clang/test/CodeGenCXX/finegrain-bitfield-type.cpp
===
--- clang/test/CodeGenCXX/finegrain-bitfield-type.cpp
+++ 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 @@
 // 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 }
Index: clang/lib/CodeGen/CGRecordLayoutBuilder.cpp
===
--- clang/lib/CodeGen/CGRecordLayoutBuilder.cpp
+++ clang/lib/CodeGen/CGRecordLayoutBuilder.cpp
@@ -414,7 +414,8 @@
   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.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D79770: [RISCV] Fix passing two floating-point values in complex separately by two GPRs on RV64

[Alex Bradbury via Phabricator via cfe-commits]

asb accepted this revision.
asb added a comment.
This revision is now accepted and ready to land.

Good catch, thanks for the fix! The logic was incorrectly written assuming 
`isFloatingType` would return false for complex values which is of course 
incorrect.




Comment at: clang/lib/CodeGen/TargetInfo.cpp:10241-10242
   // Pass floating point values via FPRs if possible.
-  if (IsFixed && Ty->isFloatingType() && FLen >= Size && ArgFPRsLeft) {
+  if (IsFixed && Ty->isFloatingType() && !Ty->isComplexType() &&
+  FLen >= Size && ArgFPRsLeft) {
 ArgFPRsLeft--;

luismarques wrote:
> Do you have tests that show the impact of the added `FLen >= Size && 
> ArgFPRsLeft` conditions for other values besides complex floats?
That's actually not an added clause - it's just been clang-formatted onto a new 
line.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D79770/new/

https://reviews.llvm.org/D79770



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

[PATCH] D40023: [RISCV] Implement ABI lowering

[Alex Bradbury via Phabricator via cfe-commits]

asb added a comment.

In https://reviews.llvm.org/D40023#933464, @majnemer wrote:

> So how does something like the following work:
>
>   union U { float f; int i; };
>   void f(union U u);
>   
>
> The flattening described in 
> https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.md#hardware-floating-point-calling-convention
>  makes sense for arrays and structs but I couldn't find where unions were 
> described.


You're right that's not currently described - I have an issue tracking this 
here: https://github.com/riscv/riscv-elf-psabi-doc/issues/24. Last time I tried 
to check gcc behaviour it seemed that such cases would be passed according to 
the integer calling convention, but I'd be happier if one of the GCC devs would 
confirm.


https://reviews.llvm.org/D40023



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

[PATCH] D39963: [RISCV][RFC] Add initial RISC-V target and driver support

[Alex Bradbury via Phabricator via cfe-commits]

asb marked an inline comment as done.
asb added a comment.

In https://reviews.llvm.org/D39963#931026, @apazos wrote:

> Can you push this as a patch to review/commit instead of RFC? It has received 
> a lot of comments/corrections already and I think it is getting in a shape we 
> can merge.


I might move the baremetal support to separate patch and discuss that on the 
mailing list. I'll remove the [RFC] tag in the next update, adding tests.




Comment at: test/Preprocessor/init.c:9991
+// RUN: %clang_cc1 -E -dM -ffreestanding -triple=riscv32 < /dev/null \
+// RUN:   | FileCheck -match-full-lines -check-prefix=RISCV32 %s
+// RISCV32: #define _ILP32 1

apazos wrote:
> Shouldn't we just check for the target specific defines  in these tests?
Many of the other tests seem to test a similarly large set of defines, plus I 
think you _do_ want to check the majority of these (especially the ones related 
to C types).


https://reviews.llvm.org/D39963



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

[PATCH] D39963: [RISCV] Add initial RISC-V target and driver support

[Alex Bradbury via Phabricator via cfe-commits]

asb updated this revision to Diff 126404.
asb marked 3 inline comments as done.
asb retitled this revision from "[RISCV][RFC] Add initial RISC-V target and 
driver support" to "[RISCV] Add initial RISC-V target and driver support".
asb edited the summary of this revision.
asb added a comment.
Herald added a subscriber: sabuasal.

Patch updates:

- Address review comments
- (u)int64_type is `long int` on RV64 rather than `long long int`
- Remove driver for bare metal RV32 target (to be posted in a subsequent patch 
and maybe discussed on cfe-dev).

>From my perspective, the only deficiency in this patch is now the tests (which 
>I'll add to this review ASAP). Let me know if you see other remaining problems.


https://reviews.llvm.org/D39963

Files:
  lib/Basic/CMakeLists.txt
  lib/Basic/Targets.cpp
  lib/Basic/Targets/RISCV.cpp
  lib/Basic/Targets/RISCV.h
  lib/Driver/CMakeLists.txt
  lib/Driver/ToolChains/Arch/RISCV.cpp
  lib/Driver/ToolChains/Arch/RISCV.h
  lib/Driver/ToolChains/Clang.cpp
  lib/Driver/ToolChains/Clang.h
  lib/Driver/ToolChains/Gnu.cpp
  lib/Driver/ToolChains/Linux.cpp
  test/Driver/frame-pointer.c
  test/Driver/riscv-abi.c
  test/Driver/riscv-features.c
  test/Driver/riscv32-toolchain.c
  test/Driver/riscv64-toolchain.c
  test/Preprocessor/init.c

Index: test/Preprocessor/init.c
===
--- test/Preprocessor/init.c
+++ test/Preprocessor/init.c
@@ -10003,3 +10003,398 @@
 // ARM-DARWIN-BAREMETAL-64: #define __PTRDIFF_TYPE__ long int
 // ARM-DARWIN-BAREMETAL-64: #define __SIZE_TYPE__ long unsigned int
 
+// RUN: %clang_cc1 -E -dM -ffreestanding -triple=riscv32 < /dev/null \
+// RUN:   | FileCheck -match-full-lines -check-prefix=RISCV32 %s
+// RISCV32: #define _ILP32 1
+// RISCV32: #define __ATOMIC_ACQUIRE 2
+// RISCV32: #define __ATOMIC_ACQ_REL 4
+// RISCV32: #define __ATOMIC_CONSUME 1
+// RISCV32: #define __ATOMIC_RELAXED 0
+// RISCV32: #define __ATOMIC_RELEASE 3
+// RISCV32: #define __ATOMIC_SEQ_CST 5
+// RISCV32: #define __BIGGEST_ALIGNMENT__ 16
+// RISCV32: #define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__
+// RISCV32: #define __CHAR16_TYPE__ unsigned short
+// RISCV32: #define __CHAR32_TYPE__ unsigned int
+// RISCV32: #define __CHAR_BIT__ 8
+// RISCV32: #define __DBL_DECIMAL_DIG__ 17
+// RISCV32: #define __DBL_DENORM_MIN__ 4.9406564584124654e-324
+// RISCV32: #define __DBL_DIG__ 15
+// RISCV32: #define __DBL_EPSILON__ 2.2204460492503131e-16
+// RISCV32: #define __DBL_HAS_DENORM__ 1
+// RISCV32: #define __DBL_HAS_INFINITY__ 1
+// RISCV32: #define __DBL_HAS_QUIET_NAN__ 1
+// RISCV32: #define __DBL_MANT_DIG__ 53
+// RISCV32: #define __DBL_MAX_10_EXP__ 308
+// RISCV32: #define __DBL_MAX_EXP__ 1024
+// RISCV32: #define __DBL_MAX__ 1.7976931348623157e+308
+// RISCV32: #define __DBL_MIN_10_EXP__ (-307)
+// RISCV32: #define __DBL_MIN_EXP__ (-1021)
+// RISCV32: #define __DBL_MIN__ 2.2250738585072014e-308
+// RISCV32: #define __DECIMAL_DIG__ __LDBL_DECIMAL_DIG__
+// RISCV32: #define __ELF__ 1
+// RISCV32: #define __FINITE_MATH_ONLY__ 0
+// RISCV32: #define __FLT_DECIMAL_DIG__ 9
+// RISCV32: #define __FLT_DENORM_MIN__ 1.40129846e-45F
+// RISCV32: #define __FLT_DIG__ 6
+// RISCV32: #define __FLT_EPSILON__ 1.19209290e-7F
+// RISCV32: #define __FLT_EVAL_METHOD__ 0
+// RISCV32: #define __FLT_HAS_DENORM__ 1
+// RISCV32: #define __FLT_HAS_INFINITY__ 1
+// RISCV32: #define __FLT_HAS_QUIET_NAN__ 1
+// RISCV32: #define __FLT_MANT_DIG__ 24
+// RISCV32: #define __FLT_MAX_10_EXP__ 38
+// RISCV32: #define __FLT_MAX_EXP__ 128
+// RISCV32: #define __FLT_MAX__ 3.40282347e+38F
+// RISCV32: #define __FLT_MIN_10_EXP__ (-37)
+// RISCV32: #define __FLT_MIN_EXP__ (-125)
+// RISCV32: #define __FLT_MIN__ 1.17549435e-38F
+// RISCV32: #define __FLT_RADIX__ 2
+// RISCV32: #define __GCC_ATOMIC_BOOL_LOCK_FREE 1
+// RISCV32: #define __GCC_ATOMIC_CHAR16_T_LOCK_FREE 1
+// RISCV32: #define __GCC_ATOMIC_CHAR32_T_LOCK_FREE 1
+// RISCV32: #define __GCC_ATOMIC_CHAR_LOCK_FREE 1
+// RISCV32: #define __GCC_ATOMIC_INT_LOCK_FREE 1
+// RISCV32: #define __GCC_ATOMIC_LLONG_LOCK_FREE 1
+// RISCV32: #define __GCC_ATOMIC_LONG_LOCK_FREE 1
+// RISCV32: #define __GCC_ATOMIC_POINTER_LOCK_FREE 1
+// RISCV32: #define __GCC_ATOMIC_SHORT_LOCK_FREE 1
+// RISCV32: #define __GCC_ATOMIC_TEST_AND_SET_TRUEVAL 1
+// RISCV32: #define __GCC_ATOMIC_WCHAR_T_LOCK_FREE 1
+// RISCV32: #define __GNUC_MINOR__ {{.*}}
+// RISCV32: #define __GNUC_PATCHLEVEL__ {{.*}}
+// RISCV32: #define __GNUC_STDC_INLINE__ 1
+// RISCV32: #define __GNUC__ {{.*}}
+// RISCV32: #define __GXX_ABI_VERSION {{.*}}
+// RISCV32: #define __ILP32__ 1
+// RISCV32: #define __INT16_C_SUFFIX__
+// RISCV32: #define __INT16_MAX__ 32767
+// RISCV32: #define __INT16_TYPE__ short
+// RISCV32: #define __INT32_C_SUFFIX__
+// RISCV32: #define __INT32_MAX__ 2147483647
+// RISCV32: #define __INT32_TYPE__ int
+// RISCV32: #define __INT64_C_SUFFIX__ LL
+// RISCV32: #define __INT64_MAX__ 9223372036854775807LL
+// RISCV32: #define __INT64_TYPE__ long long int

[PATCH] D39963: [RISCV] Add initial RISC-V target and driver support

[Alex Bradbury via Phabricator via cfe-commits]

asb updated this revision to Diff 126769.
asb edited the summary of this revision.
asb added a comment.

Update to add test cases based on the multilib Linux SDK produced by 
https://github.com/riscv/riscv-gnu-toolchain/.


https://reviews.llvm.org/D39963

Files:
  lib/Basic/CMakeLists.txt
  lib/Basic/Targets.cpp
  lib/Basic/Targets/RISCV.cpp
  lib/Basic/Targets/RISCV.h
  lib/Driver/CMakeLists.txt
  lib/Driver/ToolChains/Arch/RISCV.cpp
  lib/Driver/ToolChains/Arch/RISCV.h
  lib/Driver/ToolChains/Clang.cpp
  lib/Driver/ToolChains/Clang.h
  lib/Driver/ToolChains/Gnu.cpp
  lib/Driver/ToolChains/Linux.cpp
  test/Driver/Inputs/multilib_riscv_linux_sdk/bin/.keep
  test/Driver/Inputs/multilib_riscv_linux_sdk/include/.keep
  
test/Driver/Inputs/multilib_riscv_linux_sdk/lib/gcc/riscv64-unknown-linux-gnu/7.2.0/crtbegin.o
  
test/Driver/Inputs/multilib_riscv_linux_sdk/lib/gcc/riscv64-unknown-linux-gnu/7.2.0/lib32/ilp32/crtbegin.o
  
test/Driver/Inputs/multilib_riscv_linux_sdk/lib/gcc/riscv64-unknown-linux-gnu/7.2.0/lib32/ilp32d/crtbegin.o
  
test/Driver/Inputs/multilib_riscv_linux_sdk/lib/gcc/riscv64-unknown-linux-gnu/7.2.0/lib64/lp64/crtbegin.o
  
test/Driver/Inputs/multilib_riscv_linux_sdk/lib/gcc/riscv64-unknown-linux-gnu/7.2.0/lib64/lp64d/crtbegin.o
  test/Driver/Inputs/multilib_riscv_linux_sdk/riscv64-unknown-linux-gnu/bin/ld
  test/Driver/Inputs/multilib_riscv_linux_sdk/sysroot/lib/.keep
  test/Driver/Inputs/multilib_riscv_linux_sdk/sysroot/lib32/ilp32/.keep
  test/Driver/Inputs/multilib_riscv_linux_sdk/sysroot/lib32/ilp32d/.keep
  test/Driver/Inputs/multilib_riscv_linux_sdk/sysroot/lib64/lp64/.keep
  test/Driver/Inputs/multilib_riscv_linux_sdk/sysroot/lib64/lp64d/.keep
  test/Driver/Inputs/multilib_riscv_linux_sdk/sysroot/usr/lib32/ilp32/.keep
  test/Driver/Inputs/multilib_riscv_linux_sdk/sysroot/usr/lib32/ilp32d/.keep
  test/Driver/Inputs/multilib_riscv_linux_sdk/sysroot/usr/lib64/lp64/.keep
  test/Driver/Inputs/multilib_riscv_linux_sdk/sysroot/usr/lib64/lp64d/.keep
  test/Driver/frame-pointer.c
  test/Driver/riscv-abi.c
  test/Driver/riscv-features.c
  test/Driver/riscv32-toolchain.c
  test/Driver/riscv64-toolchain.c
  test/Preprocessor/init.c

Index: test/Preprocessor/init.c
===
--- test/Preprocessor/init.c
+++ test/Preprocessor/init.c
@@ -10003,3 +10003,398 @@
 // ARM-DARWIN-BAREMETAL-64: #define __PTRDIFF_TYPE__ long int
 // ARM-DARWIN-BAREMETAL-64: #define __SIZE_TYPE__ long unsigned int
 
+// RUN: %clang_cc1 -E -dM -ffreestanding -triple=riscv32 < /dev/null \
+// RUN:   | FileCheck -match-full-lines -check-prefix=RISCV32 %s
+// RISCV32: #define _ILP32 1
+// RISCV32: #define __ATOMIC_ACQUIRE 2
+// RISCV32: #define __ATOMIC_ACQ_REL 4
+// RISCV32: #define __ATOMIC_CONSUME 1
+// RISCV32: #define __ATOMIC_RELAXED 0
+// RISCV32: #define __ATOMIC_RELEASE 3
+// RISCV32: #define __ATOMIC_SEQ_CST 5
+// RISCV32: #define __BIGGEST_ALIGNMENT__ 16
+// RISCV32: #define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__
+// RISCV32: #define __CHAR16_TYPE__ unsigned short
+// RISCV32: #define __CHAR32_TYPE__ unsigned int
+// RISCV32: #define __CHAR_BIT__ 8
+// RISCV32: #define __DBL_DECIMAL_DIG__ 17
+// RISCV32: #define __DBL_DENORM_MIN__ 4.9406564584124654e-324
+// RISCV32: #define __DBL_DIG__ 15
+// RISCV32: #define __DBL_EPSILON__ 2.2204460492503131e-16
+// RISCV32: #define __DBL_HAS_DENORM__ 1
+// RISCV32: #define __DBL_HAS_INFINITY__ 1
+// RISCV32: #define __DBL_HAS_QUIET_NAN__ 1
+// RISCV32: #define __DBL_MANT_DIG__ 53
+// RISCV32: #define __DBL_MAX_10_EXP__ 308
+// RISCV32: #define __DBL_MAX_EXP__ 1024
+// RISCV32: #define __DBL_MAX__ 1.7976931348623157e+308
+// RISCV32: #define __DBL_MIN_10_EXP__ (-307)
+// RISCV32: #define __DBL_MIN_EXP__ (-1021)
+// RISCV32: #define __DBL_MIN__ 2.2250738585072014e-308
+// RISCV32: #define __DECIMAL_DIG__ __LDBL_DECIMAL_DIG__
+// RISCV32: #define __ELF__ 1
+// RISCV32: #define __FINITE_MATH_ONLY__ 0
+// RISCV32: #define __FLT_DECIMAL_DIG__ 9
+// RISCV32: #define __FLT_DENORM_MIN__ 1.40129846e-45F
+// RISCV32: #define __FLT_DIG__ 6
+// RISCV32: #define __FLT_EPSILON__ 1.19209290e-7F
+// RISCV32: #define __FLT_EVAL_METHOD__ 0
+// RISCV32: #define __FLT_HAS_DENORM__ 1
+// RISCV32: #define __FLT_HAS_INFINITY__ 1
+// RISCV32: #define __FLT_HAS_QUIET_NAN__ 1
+// RISCV32: #define __FLT_MANT_DIG__ 24
+// RISCV32: #define __FLT_MAX_10_EXP__ 38
+// RISCV32: #define __FLT_MAX_EXP__ 128
+// RISCV32: #define __FLT_MAX__ 3.40282347e+38F
+// RISCV32: #define __FLT_MIN_10_EXP__ (-37)
+// RISCV32: #define __FLT_MIN_EXP__ (-125)
+// RISCV32: #define __FLT_MIN__ 1.17549435e-38F
+// RISCV32: #define __FLT_RADIX__ 2
+// RISCV32: #define __GCC_ATOMIC_BOOL_LOCK_FREE 1
+// RISCV32: #define __GCC_ATOMIC_CHAR16_T_LOCK_FREE 1
+// RISCV32: #define __GCC_ATOMIC_CHAR32_T_LOCK_FREE 1
+// RISCV32: #define __GCC_ATOMIC_CHAR_LOCK_FREE 1
+// RISCV32: #define __GCC_ATOMIC_INT_LOCK_FREE 1
+// RISCV32: #define __GCC_ATOMIC_LLONG_LOCK_FREE 1
+// RISCV32: #define __

[PATCH] D39963: [RISCV] Add initial RISC-V target and driver support

[Alex Bradbury via Phabricator via cfe-commits]

asb updated this revision to Diff 126771.
asb added a comment.

Apologies, the last version had a few lines of debug code left in.

I should say that this is to the best of my knowledge ready to merge (i.e. 
there are no outstanding flagged issues). Particularly now that the majority of 
the RV32I codegen patches are merged in LLVM, it would be really helpful to get 
this merged in to clang asap in order to make larger scale testing of the LLVM 
backend possible without out-of-tree patches.


https://reviews.llvm.org/D39963

Files:
  lib/Basic/CMakeLists.txt
  lib/Basic/Targets.cpp
  lib/Basic/Targets/RISCV.cpp
  lib/Basic/Targets/RISCV.h
  lib/Driver/CMakeLists.txt
  lib/Driver/ToolChains/Arch/RISCV.cpp
  lib/Driver/ToolChains/Arch/RISCV.h
  lib/Driver/ToolChains/Clang.cpp
  lib/Driver/ToolChains/Clang.h
  lib/Driver/ToolChains/Gnu.cpp
  lib/Driver/ToolChains/Linux.cpp
  test/Driver/Inputs/multilib_riscv_linux_sdk/bin/.keep
  test/Driver/Inputs/multilib_riscv_linux_sdk/include/.keep
  
test/Driver/Inputs/multilib_riscv_linux_sdk/lib/gcc/riscv64-unknown-linux-gnu/7.2.0/crtbegin.o
  
test/Driver/Inputs/multilib_riscv_linux_sdk/lib/gcc/riscv64-unknown-linux-gnu/7.2.0/lib32/ilp32/crtbegin.o
  
test/Driver/Inputs/multilib_riscv_linux_sdk/lib/gcc/riscv64-unknown-linux-gnu/7.2.0/lib32/ilp32d/crtbegin.o
  
test/Driver/Inputs/multilib_riscv_linux_sdk/lib/gcc/riscv64-unknown-linux-gnu/7.2.0/lib64/lp64/crtbegin.o
  
test/Driver/Inputs/multilib_riscv_linux_sdk/lib/gcc/riscv64-unknown-linux-gnu/7.2.0/lib64/lp64d/crtbegin.o
  test/Driver/Inputs/multilib_riscv_linux_sdk/riscv64-unknown-linux-gnu/bin/ld
  test/Driver/Inputs/multilib_riscv_linux_sdk/sysroot/lib/.keep
  test/Driver/Inputs/multilib_riscv_linux_sdk/sysroot/lib32/ilp32/.keep
  test/Driver/Inputs/multilib_riscv_linux_sdk/sysroot/lib32/ilp32d/.keep
  test/Driver/Inputs/multilib_riscv_linux_sdk/sysroot/lib64/lp64/.keep
  test/Driver/Inputs/multilib_riscv_linux_sdk/sysroot/lib64/lp64d/.keep
  test/Driver/Inputs/multilib_riscv_linux_sdk/sysroot/usr/lib32/ilp32/.keep
  test/Driver/Inputs/multilib_riscv_linux_sdk/sysroot/usr/lib32/ilp32d/.keep
  test/Driver/Inputs/multilib_riscv_linux_sdk/sysroot/usr/lib64/lp64/.keep
  test/Driver/Inputs/multilib_riscv_linux_sdk/sysroot/usr/lib64/lp64d/.keep
  test/Driver/frame-pointer.c
  test/Driver/riscv-abi.c
  test/Driver/riscv-features.c
  test/Driver/riscv32-toolchain.c
  test/Driver/riscv64-toolchain.c
  test/Preprocessor/init.c

Index: test/Preprocessor/init.c
===
--- test/Preprocessor/init.c
+++ test/Preprocessor/init.c
@@ -10003,3 +10003,398 @@
 // ARM-DARWIN-BAREMETAL-64: #define __PTRDIFF_TYPE__ long int
 // ARM-DARWIN-BAREMETAL-64: #define __SIZE_TYPE__ long unsigned int
 
+// RUN: %clang_cc1 -E -dM -ffreestanding -triple=riscv32 < /dev/null \
+// RUN:   | FileCheck -match-full-lines -check-prefix=RISCV32 %s
+// RISCV32: #define _ILP32 1
+// RISCV32: #define __ATOMIC_ACQUIRE 2
+// RISCV32: #define __ATOMIC_ACQ_REL 4
+// RISCV32: #define __ATOMIC_CONSUME 1
+// RISCV32: #define __ATOMIC_RELAXED 0
+// RISCV32: #define __ATOMIC_RELEASE 3
+// RISCV32: #define __ATOMIC_SEQ_CST 5
+// RISCV32: #define __BIGGEST_ALIGNMENT__ 16
+// RISCV32: #define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__
+// RISCV32: #define __CHAR16_TYPE__ unsigned short
+// RISCV32: #define __CHAR32_TYPE__ unsigned int
+// RISCV32: #define __CHAR_BIT__ 8
+// RISCV32: #define __DBL_DECIMAL_DIG__ 17
+// RISCV32: #define __DBL_DENORM_MIN__ 4.9406564584124654e-324
+// RISCV32: #define __DBL_DIG__ 15
+// RISCV32: #define __DBL_EPSILON__ 2.2204460492503131e-16
+// RISCV32: #define __DBL_HAS_DENORM__ 1
+// RISCV32: #define __DBL_HAS_INFINITY__ 1
+// RISCV32: #define __DBL_HAS_QUIET_NAN__ 1
+// RISCV32: #define __DBL_MANT_DIG__ 53
+// RISCV32: #define __DBL_MAX_10_EXP__ 308
+// RISCV32: #define __DBL_MAX_EXP__ 1024
+// RISCV32: #define __DBL_MAX__ 1.7976931348623157e+308
+// RISCV32: #define __DBL_MIN_10_EXP__ (-307)
+// RISCV32: #define __DBL_MIN_EXP__ (-1021)
+// RISCV32: #define __DBL_MIN__ 2.2250738585072014e-308
+// RISCV32: #define __DECIMAL_DIG__ __LDBL_DECIMAL_DIG__
+// RISCV32: #define __ELF__ 1
+// RISCV32: #define __FINITE_MATH_ONLY__ 0
+// RISCV32: #define __FLT_DECIMAL_DIG__ 9
+// RISCV32: #define __FLT_DENORM_MIN__ 1.40129846e-45F
+// RISCV32: #define __FLT_DIG__ 6
+// RISCV32: #define __FLT_EPSILON__ 1.19209290e-7F
+// RISCV32: #define __FLT_EVAL_METHOD__ 0
+// RISCV32: #define __FLT_HAS_DENORM__ 1
+// RISCV32: #define __FLT_HAS_INFINITY__ 1
+// RISCV32: #define __FLT_HAS_QUIET_NAN__ 1
+// RISCV32: #define __FLT_MANT_DIG__ 24
+// RISCV32: #define __FLT_MAX_10_EXP__ 38
+// RISCV32: #define __FLT_MAX_EXP__ 128
+// RISCV32: #define __FLT_MAX__ 3.40282347e+38F
+// RISCV32: #define __FLT_MIN_10_EXP__ (-37)
+// RISCV32: #define __FLT_MIN_EXP__ (-125)
+// RISCV32: #define __FLT_MIN__ 1.17549435e-38F
+// RISCV32: #define __FLT_RADIX__ 2
+// RISCV32: #define __GCC_ATOMIC_BOOL_LOCK_FREE 1
+// RISCV32:

[PATCH] D133444: [RISCV] Update error message to not call 'RV32' and 'RV64' an extension.

[Alex Bradbury via Phabricator via cfe-commits]

asb accepted this revision.
asb added a comment.
This revision is now accepted and ready to land.

LGTM, thanks!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D133444/new/

https://reviews.llvm.org/D133444

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

[PATCH] D133443: [RISCV][MC] Add support for experimental Zawrs extension

[Alex Bradbury via Phabricator via cfe-commits]

asb added a comment.

The change in set of instructions without changing the version number is 
concerning - do you know anyone involved in that group? It would be good to 
feedback the difficulties this can cause for us. It's also not clear if there 
might be changes again during ratification without changing the version number, 
which wouldn't be ideal (though probably just about livable given it's marked 
as experimental).

Let's discuss briefly in the meeting tomorrow. Implementation-wise it all seems 
straightforward.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D133443/new/

https://reviews.llvm.org/D133443

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

[PATCH] D133443: [RISCV][MC] Add support for experimental Zawrs extension

[Alex Bradbury via Phabricator via cfe-commits]

asb added a comment.

I think the summary of our discussion on this was:

- The versioning confusion is unfortunate - ideally there would be discussion 
elsewhere at RVI on improving the situation (either ELF attributes to indicate 
extensions are experimental, or making that unnecessary via never using 1.0 
until something is ratified)
- But the above isn't a blocker to merging. As the extension is gated by the 
experimental flag, even if there are last minute changes the impact on users 
should be minimal / non-existent.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D133443/new/

https://reviews.llvm.org/D133443

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

[PATCH] D70401: [RISCV] CodeGen of RVE and ilp32e/lp64e ABIs

[Alex Bradbury via Phabricator via cfe-commits]

asb added a comment.

Thanks, I'll take another look. Rereading my previous comment I just wanted to 
clarify one part so it's not misunderstood. I said " I think it's unfortunate 
that this need for the ABI hasn't translated into effort to finalise the ABI 
definition in the psABI doc and to at least get it to match what GCC actually 
implements" - I wanted to be __very__ clear this isn't a criticism of those 
trying to maintain the ABI doc, it's about companies who want to ship RVE 
hardware and software not contributing to that process.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D70401/new/

https://reviews.llvm.org/D70401

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

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

[Alex Bradbury via Phabricator via cfe-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG4f40ca53cefb: [RISCV] Implement support for the Zicbom and 
Zicboz extensions (authored by asb).
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Changed prior to commit:
  https://reviews.llvm.org/D117432?vs=415498&id=440563#toc

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D117432/new/

https://reviews.llvm.org/D117432

Files:
  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/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/rv32zicbom-valid.s
  llvm/test/MC/RISCV/rv32zicboz-invalid.s
  llvm/test/MC/RISCV/rv32zicboz-valid.s

Index: llvm/test/MC/RISCV/rv32zicboz-valid.s
===
--- /dev/null
+++ llvm/test/MC/RISCV/rv32zicboz-valid.s
@@ -0,0 +1,17 @@
+# RUN: llvm-mc %s -triple=riscv32 -mattr=+zicboz -show-encoding \
+# RUN: | FileCheck -check-prefixes=CHECK-ASM,CHECK-ASM-AND-OBJ %s
+# RUN: llvm-mc %s -triple=riscv64 -mattr=+zicboz -show-encoding \
+# RUN: | FileCheck -check-prefixes=CHECK-ASM,CHECK-ASM-AND-OBJ %s
+# RUN: llvm-mc -filetype=obj -triple=riscv32 -mattr=+zicboz < %s \
+# RUN: | llvm-objdump --mattr=+zicboz -d -r - \
+# RUN: | FileCheck --check-prefix=CHECK-ASM-AND-OBJ %s
+# RUN: llvm-mc -filetype=obj -triple=riscv64 -mattr=+zicboz < %s \
+# RUN: | llvm-objdump --mattr=+zicboz -d -r - \
+# RUN: | FileCheck --check-prefix=CHECK-ASM-AND-OBJ %s
+
+# CHECK-ASM-AND-OBJ: cbo.zero (t0)
+# CHECK-ASM: encoding: [0x0f,0xa0,0x42,0x00]
+cbo.zero (t0)
+# CHECK-ASM-AND-OBJ: cbo.zero (t0)
+# CHECK-ASM: encoding: [0x0f,0xa0,0x42,0x00]
+cbo.zero 0(t0)
Index: llvm/test/MC/RISCV/rv32zicboz-invalid.s
===
--- /dev/null
+++ llvm/test/MC/RISCV/rv32zicboz-invalid.s
@@ -0,0 +1,16 @@
+# RUN: not llvm-mc -triple riscv32 -mattr=+zicboz < %s 2>&1 | FileCheck %s
+# RUN: not llvm-mc -triple riscv64 -mattr=+zicboz < %s 2>&1 | FileCheck %s
+
+# Must have a single register argument.
+cbo.zero # CHECK: :[[@LINE]]:1: error: too few operands for instruction
+cbo.zero 1 # CHECK: :[[@LINE]]:12: error: expected '(' after optional integer offset
+cbo.zero t0, t1 # CHECK: :[[@LINE]]:10: error: expected '(' or optional integer offset
+
+# Non-zero offsets are not supported.
+cbo.zero 1(t0) # CHECK: :[[@LINE]]:10: error: optional integer offset must be 0
+
+# Instructions from other zicbo* extensions aren't available without enabling
+# the appropriate -mattr flag.
+cbo.clean (t0) # CHECK: :[[@LINE]]:1: error: instruction requires the following: 'Zicbom' (Cache-Block Management Instructions)
+cbo.flush (t1) # CHECK: :[[@LINE]]:1: error: instruction requires the following: 'Zicbom' (Cache-Block Management Instructions)
+cbo.inval (t2) # CHECK: :[[@LINE]]:1: error: instruction requires the following: 'Zicbom' (Cache-Block Management Instructions)
Index: llvm/test/MC/RISCV/rv32zicbom-valid.s
===
--- /dev/null
+++ llvm/test/MC/RISCV/rv32zicbom-valid.s
@@ -0,0 +1,31 @@
+# RUN: llvm-mc %s -triple=riscv32 -mattr=+zicbom -show-encoding \
+# RUN: | FileCheck -check-prefixes=CHECK-ASM,CHECK-ASM-AND-OBJ %s
+# RUN: llvm-mc %s -triple=riscv64 -mattr=+zicbom -show-encoding \
+# RUN: | FileCheck -check-prefixes=CHECK-ASM,CHECK-ASM-AND-OBJ %s
+# RUN: llvm-mc -filetype=obj -triple=riscv32 -mattr=+zicbom < %s \
+# RUN: | llvm-objdump --mattr=+zicbom -d -r - \
+# RUN: | FileCheck --check-prefix=CHECK-ASM-AND-OBJ %s
+# RUN: llvm-mc -filetype=obj -triple=riscv64 -mattr=+zicbom < %s \
+# RUN: | llvm-objdump --mattr=+zicbom -d -r - \
+# RUN: | FileCheck --check-prefix=CHECK-ASM-AND-OBJ %s
+
+# CHECK-ASM-AND-OBJ: cbo.clean (t0)
+# CHECK-ASM: encoding: [0x0f,0xa0,0x12,0x00]
+cbo.clean (t0)
+# CHECK-ASM-AND-OBJ: cbo.clean (t0)
+# CHECK-ASM: encoding: [0x0f,0xa0,0x12,0x00]
+cbo.clean 0(t0)
+
+# CHECK-ASM-AND-OBJ: cbo.flush (t1)
+# CHECK-ASM: encoding: [0x0f,0x20,0x23,0x00]
+cbo.flush (t1)
+# CHECK-ASM-AND-OBJ: cbo.flush (t1)
+# CHECK-ASM: encoding: [0x0f,0x20,0x23,0x00]
+cbo.flush 0(t1)
+
+# CHECK-ASM-AND-OBJ: cbo.inval (t2)
+# CHECK-ASM: encoding: [0x0f,0xa0,0x03,0x00]
+cbo.inval (t2)
+# CHECK-ASM-AND-OBJ: cbo.inval (t2)
+# CHECK-ASM: encoding: [0x0f,0xa0,0x03,0x00]
+cbo.inval 0(t2)
Index: llvm/test/MC/RISCV/rv32zicbom-invalid.s
===
--- /dev/null
+++ llvm/test/MC/RISCV/rv32zicbom-invalid.s
@@ -0,0 +1,24 @@
+# RUN: not llvm-mc -triple riscv32 -mattr=+zicbom < %s 2>&1 | Fi

[PATCH] D117433: [RISCV] Implement support for the Zicbop extension

[Alex Bradbury via Phabricator via cfe-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG7bcfcabbd14e: [RISCV] Implement support for the Zicbop 
extension (authored by asb).
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Changed prior to commit:
  https://reviews.llvm.org/D117433?vs=415500&id=440564#toc

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D117433/new/

https://reviews.llvm.org/D117433

Files:
  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/rv32zicbop-invalid.s
  llvm/test/MC/RISCV/rv32zicbop-valid.s
  llvm/test/MC/RISCV/rv32zicboz-invalid.s

Index: llvm/test/MC/RISCV/rv32zicboz-invalid.s
===
--- llvm/test/MC/RISCV/rv32zicboz-invalid.s
+++ llvm/test/MC/RISCV/rv32zicboz-invalid.s
@@ -14,3 +14,6 @@
 cbo.clean (t0) # CHECK: :[[@LINE]]:1: error: instruction requires the following: 'Zicbom' (Cache-Block Management Instructions)
 cbo.flush (t1) # CHECK: :[[@LINE]]:1: error: instruction requires the following: 'Zicbom' (Cache-Block Management Instructions)
 cbo.inval (t2) # CHECK: :[[@LINE]]:1: error: instruction requires the following: 'Zicbom' (Cache-Block Management Instructions)
+prefetch.i 0(t3) # CHECK: :[[@LINE]]:1: error: instruction requires the following: 'Zicbop' (Cache-Block Prefetch Instructions)
+prefetch.r 0(t4) # CHECK: :[[@LINE]]:1: error: instruction requires the following: 'Zicbop' (Cache-Block Prefetch Instructions)
+prefetch.w 0(t5) # CHECK: :[[@LINE]]:1: error: instruction requires the following: 'Zicbop' (Cache-Block Prefetch Instructions)
Index: llvm/test/MC/RISCV/rv32zicbop-valid.s
===
--- /dev/null
+++ llvm/test/MC/RISCV/rv32zicbop-valid.s
@@ -0,0 +1,40 @@
+# RUN: llvm-mc %s -triple=riscv32 -mattr=+zicbop -show-encoding \
+# RUN: | FileCheck -check-prefixes=CHECK-ASM,CHECK-ASM-AND-OBJ %s
+# RUN: llvm-mc %s -triple=riscv64 -mattr=+zicbop -show-encoding \
+# RUN: | FileCheck -check-prefixes=CHECK-ASM,CHECK-ASM-AND-OBJ %s
+# RUN: llvm-mc -filetype=obj -triple=riscv32 -mattr=+zicbop < %s \
+# RUN: | llvm-objdump --mattr=+zicbop -d -r - \
+# RUN: | FileCheck --check-prefix=CHECK-ASM-AND-OBJ %s
+# RUN: llvm-mc -filetype=obj -triple=riscv64 -mattr=+zicbop < %s \
+# RUN: | llvm-objdump --mattr=+zicbop -d -r - \
+# RUN: | FileCheck --check-prefix=CHECK-ASM-AND-OBJ %s
+
+# CHECK-ASM-AND-OBJ: prefetch.i -2048(t0)
+# CHECK-ASM: encoding: [0x13,0xe0,0x02,0x80]
+prefetch.i -2048(t0)
+# CHECK-ASM-AND-OBJ: prefetch.i 2016(t0)
+# CHECK-ASM: encoding: [0x13,0xe0,0x02,0x7e]
+prefetch.i 2016(t0)
+
+# CHECK-ASM-AND-OBJ: prefetch.r -2048(t1)
+# CHECK-ASM: encoding: [0x13,0x60,0x13,0x80]
+prefetch.r -0x800(t1)
+# CHECK-ASM-AND-OBJ: prefetch.r 2016(t1)
+# CHECK-ASM: encoding: [0x13,0x60,0x13,0x7e]
+prefetch.r 0x7e0(t1)
+
+# CHECK-ASM-AND-OBJ: prefetch.w -2048(t2)
+# CHECK-ASM: encoding: [0x13,0xe0,0x33,0x80]
+prefetch.w -2048(t2)
+# CHECK-ASM-AND-OBJ: prefetch.w 2016(t2)
+# CHECK-ASM: encoding: [0x13,0xe0,0x33,0x7e]
+prefetch.w 2016(t2)
+
+# Ensure that enabling zicbop doesn't cause issues decoding ori instructions.
+
+# CHECK-ASM-AND-OBJ: ori a0, a1, -2048
+# CHECK-ASM: encoding: [0x13,0xe5,0x05,0x80]
+ori a0, a1, -2048
+# CHECK-ASM-AND-OBJ: ori a0, a1, 0
+# CHECK-ASM: encoding: [0x13,0xe5,0x05,0x00]
+ori a0, a1, 0
Index: llvm/test/MC/RISCV/rv32zicbop-invalid.s
===
--- /dev/null
+++ llvm/test/MC/RISCV/rv32zicbop-invalid.s
@@ -0,0 +1,29 @@
+# RUN: not llvm-mc -triple riscv32 -mattr=+zicbop < %s 2>&1 | FileCheck %s
+# RUN: not llvm-mc -triple riscv64 -mattr=+zicbop < %s 2>&1 | FileCheck %s
+
+# Memory operand not formatted correctly.
+prefetch.i a0, 32 # CHECK: :[[@LINE]]:12: error: immediate must be a multiple of 32 bytes in the range [-2048, 2016]
+prefetch.r 32, a0 # CHECK: :[[@LINE]]:16: error: invalid operand for instruction
+prefetch.w a0(32) # CHECK: :[[@LINE]]:14: error: unexpected token
+
+# Out of range offset.
+prefetch.i -2080(a0) # CHECK: :[[@LINE]]:12: error: immediate must be a multiple of 32 bytes in the range [-2048, 2016]
+prefetch.r 2048(a0) # CHECK: :[[@LINE]]:12: error: immediate must be a multiple of 32 bytes in the range [-2048, 2016]
+prefetch.w 2050(a0) # CHECK: :[[@LINE]]:12: error: immediate must be a multiple of 32 bytes in the range [-2048, 2016]
+
+# Offsets that aren't multiples of 32.
+pref