summaryrefslogtreecommitdiffstats
path: root/clang/lib/Basic/Targets/RISCV.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Revert "[RISCV] Add Clang frontend support for Bitmanip extension"Scott Egerton2020-01-151-7/+0
| | | | This reverts commit 57cf6ee9c84434161088c39a6f8dd2aae14eb12d.
* [RISCV] Add Clang frontend support for Bitmanip extensionScott Egerton2020-01-141-0/+7
| | | | | | | | | | | | | | 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
* [RISCV] Define __riscv_cmodel_medlow and __riscv_cmodel_medany correctlyKito Cheng2019-09-171-2/+8
| | | | | | | | | | | | | | RISC-V LLVM was only implement small/medlow code model, so it defined __riscv_cmodel_medlow directly without check. Now, we have medium/medany code model in RISC-V back-end, it should define according the actually code model. Reviewed By: lewis-revill Differential Revision: https://reviews.llvm.org/D67065 llvm-svn: 372078
* [RISCV] Correct Logic around ilp32e macrosSam Elliott2019-09-031-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: GCC seperates the `__riscv_float_abi_*` macros and the `__riscv_abi_rve` macro. If the chosen abi is ilp32e, `gcc -march=rv32i -mabi=ilp32i -E -dM` shows that both `__riscv_float_abi_soft` and `__riscv_abi_rve` are set. This patch corrects the compiler logic around these defines. At the moment, this patch will not change clang's behaviour, because we do not accept the `ilp32e` abi yet. Reviewers: luismarques, asb Reviewed By: luismarques Subscribers: rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, kito-cheng, shiva0217, jrtc27, MaskRay, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe, PkmX, jocewei, psnobl, benna, Jim, s.egerton, pzheng, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D66591 llvm-svn: 370709
* [RISCV] Add inline asm constraint A for RISC-VLewis Revill2019-08-161-0/+4
| | | | | | | | | | | | This allows the constraint A to be used in inline asm for RISC-V, which allows an address held in a register to be used. This patch adds the minimal amount of code required to get operands with the right constraints to compile. Differential Revision: https://reviews.llvm.org/D54295 llvm-svn: 369093
* [RISCV] Support 'f' Inline Assembly ConstraintSam Elliott2019-07-311-0/+4
| | | | | | | | | | | | | | | | | | | | | | | Summary: This adds the 'f' inline assembly constraint, as supported by GCC. An 'f'-constrained operand is passed in a floating point register. Exactly which kind of floating-point register (32-bit or 64-bit) is decided based on the operand type and the available standard extensions (-f and -d, respectively). This patch adds support in both the clang frontend, and LLVM itself. Reviewers: asb, lewis-revill Reviewed By: asb Subscribers: hiraditya, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, kito-cheng, shiva0217, jrtc27, MaskRay, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe, PkmX, jocewei, psnobl, benna, Jim, s.egerton, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D65500 llvm-svn: 367403
* [RISCV] Add support for floating point registers in inlineasmSimon Cook2019-07-311-9/+24
| | | | | | | | | This adds support for parsing/emitting in IR the floating-point RISC-V registers in inline assembly clobber lists. Differential Revision: https://reviews.llvm.org/D64737 llvm-svn: 367399
* [RISCV] Hard float ABI supportAlex Bradbury2019-07-181-2/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Revert "[RISCV] Hard float ABI support" r366450Alex Bradbury2019-07-181-11/+2
| | | | | | The commit was missing a few hunks. Will fix and recommit. llvm-svn: 366454
* [RISCV] Hard float ABI supportAlex Bradbury2019-07-181-2/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [RISCV] Add inline asm constraints I, J & K for RISC-VLewis Revill2019-06-111-0/+20
| | | | | | | | | | | | | | | | This allows the constraints I, J & K to be used in inline asm for RISC-V, with the following semantics (equivalent to GCC): I: Any 12-bit signed immediate. J: Integer zero only. K: Any 5-bit unsigned immediate. See the GCC definitions here: https://gcc.gnu.org/onlinedocs/gccint/Machine-Constraints.html Differential Revision: https://reviews.llvm.org/D54091 llvm-svn: 363055
* Fix typo in risc-v register aliases.Eric Christopher2019-05-071-1/+1
| | | | | | | | Patch by John. Differential Revision: https://reviews.llvm.org/D61464 llvm-svn: 360104
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* [PATCH] [RISCV] Extend getTargetDefines for RISCVTargetInfoShiva Chen2018-04-051-0/+52
| | | | | | | | | | | | | | 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
* [RISCV] Add the RISCV target and compiler driverAlex Bradbury2018-01-111-0/+52
As RV64 codegen has not yet been upstreamed into LLVM, we focus on RV32 driver support (RV64 to follow). Differential Revision: https://reviews.llvm.org/D39963 llvm-svn: 322276
OpenPOWER on IntegriCloud