[PATCH] D74226: [mlir][spirv] Introduce spv.function
    Lei Zhang via Phabricator via llvm-commits 
    llvm-commits at lists.llvm.org
       
    Tue Feb 11 14:50:23 PST 2020
    
    
  
antiagainst marked an inline comment as done.
antiagainst added inline comments.
================
Comment at: mlir/include/mlir/IR/FunctionSupport.h:141
+  /// Adds an entry block to an empty function, and set up the block arguments
+  /// to match the signature of the function. The newly inserted entry block
+  /// is returned.
----------------
antiagainst wrote:
> rriddle wrote:
> > rriddle wrote:
> > > rriddle wrote:
> > > > None of these are valid if the type of the function isn't the builtin `FunctionType`, i.e. LLVMFuncOp doesn't work with any of these methods.
> > > If you want to add these, the things that rely on FunctionType should be moved to a separate section and there should be disclaimers/comments on the top-level comment of FunctionLike denoting that these methods need to be hidden/overridden if the underlying type isn't FunctionType. You should also make sure that these are all hidden for LLVMFuncOp.
> > An alternative that may work is to static assert that the type returned by `std::declval<ConcreteType>().getType()` is equal to `FunctionType` inside of each of those methods.
> Yup. But won't this still be good defaults for other func ops (std, gpu, spv)? llvm side one can hide these methods. (And that's what happening per the current impl.) Let me know if this is okay, I can always put these back and copy on the SPIR-V side. 
Oh, replied before seeing your new comments. Sure, I'll address these. :) 
Repository:
  rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D74226/new/
https://reviews.llvm.org/D74226
    
    
More information about the llvm-commits
mailing list