niyue commented on PR #38116: URL: https://github.com/apache/arrow/pull/38116#issuecomment-1763638136
> as you mentioned there is also the dynamic library approach which also doesn't require IRs, but IMO it won't be as convenient as using function stubs I see. I am aware of the function stubs approach, but previously I didn't realize this could be the direct API for addressing the non pre-compiled function registration issue. Since I've already spotted some performance issue for large IR functions (when constructing LLVM modules), I am interested in making this approach a public and an official approach for extending gandiva's non pre-compiled functions later. Instead of rushing to merge this PR, I would like to spend more time to make the registration APIs of IR based function and non IR based function (which is not in the scope of this PR) consistent. Internally, I think we could still keep the function metadata registration as a separated API, but what could be the most meaningful external registration APIs for users? Considering users typically need to provide function metadata as well as function implementation, do we think this set of APIs okay for such purpose? (We may not have to put these API in `FunctionRegistry` class if we think this put too much responsibility to it) 1) for pre-compiled IR functions, `FunctionRegistry::Add(std::vector<NativeFunction> funcs, const std::string& bitcode_path)` 2) for non pre-compiled functions, `FunctionRegistry::Add(std::vector<NativeFunction> funcs, FunctionHolderMaker maker)` cc @kou @js8544 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: github-unsubscr...@arrow.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
