Commit Graph

8 Commits

Author SHA1 Message Date
Scott Egerton 61ff296375 [RISCV] Add Clang frontend support for Bitmanip extension
This adds the __riscv_bitmanip macro and the 'b' target feature to enable it.

Differential Revision: https://reviews.llvm.org/D71553
2020-04-09 18:04:22 +01:00
Scott Egerton cbe681bd83 Revert "[RISCV] Add Clang frontend support for Bitmanip extension"
This reverts commit 57cf6ee9c8.
2020-01-15 10:43:42 +00:00
Scott Egerton 57cf6ee9c8 [RISCV] Add Clang frontend support for Bitmanip extension
Summary: This adds the __riscv_bitmanip macro and the 'b' target feature to enable it.

Reviewers: asb, simoncook, lewis-revill, PaoloS, lenary

Reviewed By: lenary

Subscribers: Jim, rbar, johnrusso, sabuasal, niosHD, kito-cheng, shiva0217, jrtc27, MaskRay, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe, PkmX, jocewei, psnobl, benna, pzheng, sameer.abuasal, apazos, luismarques, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D71553
2020-01-14 17:45:45 +00:00
Roger Ferrer Ibanez 8e87396307 [RISCV] Default to ilp32d/lp64d in RISC-V Linux
When running clang as a native compiler in RISC-V Linux the flag
-mabi=ilp32d / -mabi=lp64d is always mandatory. This change makes it the
default there.

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

llvm-svn: 371494
2019-09-10 07:57:36 +00:00
Alex Bradbury e078967adf [RISCV] Hard float ABI support
The RISC-V hard float calling convention requires the frontend to:

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

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

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

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

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

llvm-svn: 366480
2019-07-18 18:29:59 +00:00
Alex Bradbury 9b732fe99b Revert "[RISCV] Hard float ABI support" r366450
The commit was missing a few hunks. Will fix and recommit.

llvm-svn: 366454
2019-07-18 16:13:17 +00:00
Alex Bradbury fc3aa2ab48 [RISCV] Hard float ABI support
The RISC-V hard float calling convention requires the frontend to:

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

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

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

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

llvm-svn: 366450
2019-07-18 15:33:41 +00:00
Shiva Chen 4891dbf557 [PATCH] [RISCV] Extend getTargetDefines for RISCVTargetInfo
Summary:
This patch extend getTargetDefines and implement handleTargetFeatures
and hasFeature. and define corresponding marco for those features.

Reviewers: asb, apazos, eli.friedman

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

Patch by Kito Cheng.

llvm-svn: 329278
2018-04-05 12:54:00 +00:00