Revert "[MLIR] Generic 'malloc', 'aligned_alloc' and 'free' functions"This reverts commit 3e21fb616d9a1b29bf9d1a1ba484add633d6d5b3.A lot of integration tests are failing on the bot.
[MLIR] Generic 'malloc', 'aligned_alloc' and 'free' functionsWhen converted to the LLVM dialect, the memref.alloc and memref.free operations were generating calls to hardcoded 'malloc' and 'free' f
[MLIR] Generic 'malloc', 'aligned_alloc' and 'free' functionsWhen converted to the LLVM dialect, the memref.alloc and memref.free operations were generating calls to hardcoded 'malloc' and 'free' functions. This didn't leave any freedom to users to provide their custom implementation. Those operations now convert into calls to '_mlir_alloc' and '_mlir_free' functions, which have also been implemented into the runtime support library as wrappers to 'malloc' and 'free'. The same has been done for the 'aligned_alloc' function.Reviewed By: ftynseDifferential Revision: https://reviews.llvm.org/D128791
show more ...
[mlir][LLVMIR] Add support for va_start/copy/end intrinsicsThis patch adds three new LLVM intrinsic operations: llvm.intr.vastart/copy/end.And its translation from LLVM IR.This effectively remov
[mlir][LLVMIR] Add support for va_start/copy/end intrinsicsThis patch adds three new LLVM intrinsic operations: llvm.intr.vastart/copy/end.And its translation from LLVM IR.This effectively removes a restriction, imposed by 0126dcf1f0a1, wherenon-external functions in LLVM dialect cannot be variadic. At that timeit was not clear how LLVM intrinsics are going to be modeled, whichindirectly affects va_start/copy/end, the core intrinsics used invariadic functions. But since we have LLVM intrinsics as normalMLIR operations, it's not a problem anymore.Differential Revision: https://reviews.llvm.org/D127540
[mlir] replace 'emit_c_wrappers' func->llvm conversion option with a passThe 'emit_c_wrappers' option in the FuncToLLVM conversion requests C interfacewrappers to be emitted for every builtin func
[mlir] replace 'emit_c_wrappers' func->llvm conversion option with a passThe 'emit_c_wrappers' option in the FuncToLLVM conversion requests C interfacewrappers to be emitted for every builtin function in the module. While this hasbeen useful to bootstrap the interface, it is problematic in the longer term asit may unintentionally affect the functions that should retain their existinginterface, e.g., libm functions obtained by lowering math operations (seeD126964 for an example). Since D77314, we have a finer-grain control overinterface generation via an attribute that avoids the problem entirely. Removethe 'emit_c_wrappers' option. Introduce the '-llvm-request-c-wrappers' passthat can be run in any pipeline that needs blanket emission of functions toannotate all builtin functions with the attribute before performing the usuallowering that accounts for the attribute.Reviewed By: cheliniDifferential Revision: https://reviews.llvm.org/D127952
[mlir] Remove the `type` keyword from type alias definitionsThis was carry over from LLVM IR where the alias definition canbe ambiguous, but MLIR type aliases have no such problems.Having the `ty
[mlir] Remove the `type` keyword from type alias definitionsThis was carry over from LLVM IR where the alias definition canbe ambiguous, but MLIR type aliases have no such problems.Having the `type` keyword is superfluous and doesn't add anything.This commit drops it, which also nicely aligns with the syntax forattribute aliases (which doesn't have a keyword).Differential Revision: https://reviews.llvm.org/D125501
[mlir][LLVM] Fix crash when using opaque pointers in function signaturesUsing opaque pointers in function signatures leads to an attempt to recursively convert all types, including sub types in LLV
[mlir][LLVM] Fix crash when using opaque pointers in function signaturesUsing opaque pointers in function signatures leads to an attempt to recursively convert all types, including sub types in LLVM types. In the case of LLVM pointers, it may not have a subtype aka element type if it is opaque which would then lead to a null pointer dereference.Differential Revision: https://reviews.llvm.org/D124291
[mlir][NFC] Update textual references of `func` to `func.func` in Conversion/ testsThe special case parsing of `func` operations is being removed.
[MLIR] Check for static shape before bare pointer conversionOriginally in the returnOp conversion, the result type was changing to barepointer if the type was a memref. This is incorrect as conver
[MLIR] Check for static shape before bare pointer conversionOriginally in the returnOp conversion, the result type was changing to barepointer if the type was a memref. This is incorrect as conversion to barepointer can only be done if the memref has static shape, strides and offset.Reviewed By: ftynseDifferential Revision: https://reviews.llvm.org/D123121
[mlir] Move the Builtin FuncOp to the Func dialectThis commit moves FuncOp out of the builtin dialect, and into the Funcdialect. This move has been planned in some capacity from the momentwe made
[mlir] Move the Builtin FuncOp to the Func dialectThis commit moves FuncOp out of the builtin dialect, and into the Funcdialect. This move has been planned in some capacity from the momentwe made FuncOp an operation (years ago). This commit handles thefunctional aspects of the move, but various aspects are left untouchedto ease migration: func::FuncOp is re-exported into mlir to reducethe actual API churn, the assembly format still accepts the unqualified`func`. These temporary measures will remain for a little while tosimplify migration before being removed.Differential Revision: https://reviews.llvm.org/D121266
[mlir] Update FuncOp conversion passes to Pass/InterfacePass<FunctionOpInterface>These passes generally don't rely on any special aspects of FuncOp, and moving allowsfor these passes to be used in
[mlir] Update FuncOp conversion passes to Pass/InterfacePass<FunctionOpInterface>These passes generally don't rely on any special aspects of FuncOp, and moving allowsfor these passes to be used in many more situations. The passes that obviously weren'trelying on invariants guaranteed by a "function" were updated to be generic pass, therest were updated to be FunctionOpinterface InterfacePasses.The test updates are NFC switching from implicit nesting (-pass -pass2) form tothe -pass-pipeline form (generic passes do not implicitly nest as op-specific passes do).Differential Revision: https://reviews.llvm.org/D121190
[mlir][NFC] Rename StandardToLLVM to FuncToLLVMThe current StandardToLLVM conversion patterns only really handlethe Func dialect. The pass itself adds patterns for Arithmetic/CFToLLVM, butthose s
[mlir][NFC] Rename StandardToLLVM to FuncToLLVMThe current StandardToLLVM conversion patterns only really handlethe Func dialect. The pass itself adds patterns for Arithmetic/CFToLLVM, butthose should be/will be split out in a followup. This commit focuses solelyon being an NFC rename.Aside from the directory change, the pattern and pass creation API have been renamed: * populateStdToLLVMFuncOpConversionPattern -> populateFuncToLLVMFuncOpConversionPattern * populateStdToLLVMConversionPatterns -> populateFuncToLLVMConversionPatterns * createLowerToLLVMPass -> createConvertFuncToLLVMPassDifferential Revision: https://reviews.llvm.org/D120778