Commit
60ea6f35a270d11c91770a2fc366888e7d3859f4
by simon.tatham[ARM] Allow selecting hard-float ABI in integer-only MVE.
Armv8.1-M can be configured to support the integer subset of the MVE vector instructions, and no floating point. In that situation, the FP and vector registers still exist, and so do the load, store and move instructions that transfer data in and out of them. So there's no reason the hard floating point ABI can't be supported, and you might reasonably want to use it, for the sake of intrinsics-based code passing explicit MVE vector types between functions.
But the selection of the hard float ABI in the backend was gated on Subtarget->hasVFP2Base(), which is false in the case of integer MVE and no FP.
As a result, you'd silently get the soft float ABI even if you deliberately tried to select it, e.g. with clang options such as --target=arm-none-eabi -mfloat-abi=hard -march=armv8.1m.main+nofp+mve
The hard float ABI should have been gated on the weaker condition Subtarget->hasFPRegs(), because the only requirement for being able to pass arguments in the FP registers is that the registers themselves should exist.
I haven't added a new test, because changing the existing CodeGen/Thumb2/float-ops.ll test seemed sufficient. But I've added a comment explaining why the results are expected to be what they are.
Reviewed By: lenary
Differential Revision: https://reviews.llvm.org/D142703
|
 | clang/docs/ReleaseNotes.rst (diff) |
 | llvm/lib/Target/ARM/ARMFastISel.cpp (diff) |
 | llvm/docs/ReleaseNotes.rst (diff) |
 | llvm/test/CodeGen/Thumb2/float-ops.ll (diff) |
 | llvm/lib/Target/ARM/ARMISelLowering.cpp (diff) |
Commit
1ac248e485c2ee88fcaf1694942b599ea987a726
by springerm[mlir][bufferization][NFC] Rename getAliasingOpOperand/getAliasingOpResult
* `getAliasingOpOperand` => `getAliasingOpOperands` * `getAliasingOpResult` => `getAliasingOpResults`
Also a few minor code cleanups and better documentation.
Differential Revision: https://reviews.llvm.org/D142979
|
 | mlir/lib/Dialect/Bufferization/IR/BufferizationOps.cpp (diff) |
 | mlir/lib/Dialect/Arith/Transforms/BufferizableOpInterfaceImpl.cpp (diff) |
 | mlir/lib/Dialect/SparseTensor/Transforms/BufferizableOpInterfaceImpl.cpp (diff) |
 | mlir/include/mlir/Dialect/Bufferization/IR/BufferizableOpInterface.td (diff) |
 | mlir/lib/Dialect/Bufferization/Transforms/OneShotAnalysis.cpp (diff) |
 | mlir/lib/Dialect/Shape/Transforms/BufferizableOpInterfaceImpl.cpp (diff) |
 | mlir/lib/Dialect/Bufferization/Transforms/FuncBufferizableOpInterfaceImpl.cpp (diff) |
 | mlir/include/mlir/Dialect/Bufferization/IR/BufferizationOps.td (diff) |
 | mlir/include/mlir/Dialect/Bufferization/IR/BufferizableOpInterface.h (diff) |
 | mlir/lib/Dialect/SCF/Transforms/BufferizableOpInterfaceImpl.cpp (diff) |
 | mlir/lib/Dialect/Tensor/Transforms/BufferizableOpInterfaceImpl.cpp (diff) |
 | mlir/lib/Dialect/Linalg/Transforms/BufferizableOpInterfaceImpl.cpp (diff) |
 | mlir/include/mlir/Dialect/Bufferization/IR/DstBufferizableOpInterfaceImpl.h (diff) |
 | mlir/lib/Dialect/Bufferization/IR/BufferizableOpInterface.cpp (diff) |
 | mlir/lib/Dialect/Vector/Transforms/BufferizableOpInterfaceImpl.cpp (diff) |
Commit
d8153ae29959e8e27a1458fab4107e93b5861240
by tobias.gysi[mlir][llvm] Opaque pointer support for atomic and call ops.
This revision adapts the printers and parsers of the LLVM Dialect AtomicRMWOp, AtomicCmpXchgOp, CallOp, and InvokeOp to support both opaque and typed pointers by printing the pointer types explicitly. Previously, the printers and parser of these operations silently assumed typed pointers. This assumption is problematic if a lowering or the LLVM IR import produce LLVM Dialect with opaque pointers and the IR is then printed and parsed, for example, when running mlir-translate. In LLVM IR itself all tests with typed pointers are already gone. It is thus important to start switching to opaque pointers.
This revision can be seen as a preparation step for the switch of the LLVM Dialect to opaque pointers. Once printing and parsing works seamlessly, all lowerings to LLVM Dialect can be switched to produce opaque pointers. After a transition period, LLVM Dialect itself can by simplified to support opaque pointers only.
Reviewed By: ftynse, Dinistro
Differential Revision: https://reviews.llvm.org/D142884
|
 | mlir/lib/Target/LLVMIR/Dialect/LLVMIR/LLVMToLLVMIRTranslation.cpp (diff) |
 | mlir/include/mlir/Dialect/LLVMIR/LLVMOps.td (diff) |
 | mlir/test/Conversion/FuncToLLVM/convert-funcs.mlir (diff) |
 | mlir/test/Dialect/OpenMP/ops.mlir (diff) |
 | mlir/test/Target/LLVMIR/Import/constant.ll (diff) |
 | mlir/test/Target/LLVMIR/openmp-reduction.mlir (diff) |
 | mlir/test/Target/LLVMIR/llvmir.mlir (diff) |
 | mlir/test/Conversion/MemRefToLLVM/memref-to-llvm.mlir (diff) |
 | mlir/test/Target/LLVMIR/Import/instructions.ll (diff) |
 | mlir/test/Dialect/LLVMIR/invalid.mlir (diff) |
 | mlir/lib/Dialect/LLVMIR/IR/LLVMDialect.cpp (diff) |
 | mlir/test/Dialect/LLVMIR/roundtrip.mlir (diff) |
 | mlir/test/Dialect/OpenMP/invalid.mlir (diff) |
|
 | llvm/lib/AsmParser/LLParser.cpp (diff) |
|
 | llvm/test/CodeGen/Generic/available_externally_alias.ll (diff) |
Commit
f559e781b2bd918d8cac8a878639870a8f26196d
by david.green[AArch64] Handle negative architecture features
Currently negative architecture features passes to clang like -Xclang -target-feature -Xclang -v9.3a will end up _enabling_ dependant target features (like FEAT_MOPS). This patch fixes that by ensuring we don't enable dependant target features when !Enabled.
Fixes #60375
Differential Revision: https://reviews.llvm.org/D142963
|
 | clang/test/CodeGen/aarch64-targetattr.c (diff) |
 | clang/lib/Basic/Targets/AArch64.cpp (diff) |
 | clang/test/Preprocessor/aarch64-target-features.c (diff) |