[C++] Refactor AddKernel to support other operations and types

[asfimport]

• Should avoid using builders (and/or NULLs) since the output shape is known a compute time.
• Should be refatored to support other operations, e.g. Substraction, Multiplication.
• Should have a overflow, underflow detection mode.

Reporter: Francois Saint-Jacques / @fsaintjacques

Related issues:

• [C++] Implement binary arithmetic kernels for numeric arrays (blocks)
• [C++] C++ array kernels framework and execution buildout (umbrella issue) (is a child of)
• [C++] Determine the feasibility and build a prototype to replace compute/kernels with gandiva kernels (is related to)

_{Note: This issue was originally created as ARROW-7017. Please see the migration documentation for further details.}

[asfimport]

Jacques Nadeau / @jacques-n:
What's the thinking of building these a second time here as opposed to just adding utility methods over Gandiva for specific patterns? My experience is that it is very rare that people only need to do a single expression.

[asfimport]

Wes McKinney / @wesm:
I think the jury is out (for example, I'm not totally convinced) on having LLVM compilation as a hard requirement for running simple expressions. I'm not sure what will end up being most desirable long term

[asfimport]

Micah Kornfield / @emkornfield:
I'd in particular like to be careful that if we do introduce a requirement on LLVM is isolated to compute code and doesn't leak into other modules.  For instance the Cast kernel is depended on by other modules.

[asfimport]

Jacques Nadeau / @jacques-n:
Isn't it possible to use the LLVM paths to generate objects at compile time for people who don't want runtime compilation (and want to avoid the LLVM dependency)? My thought is we have people working on a bunch of expressions in Gandiva already so why not make that useful elsewhere rather than having two implementations of things like add, cast, etc.

In other words, can we have a single development push even though there are two targets (compile time and runtime compilation)?

[asfimport]

Wes McKinney / @wesm:
We should see what is possible as far as generating a shared library from a bundle of LLVM IR. If Gandiva developed the functionality to

• pre-compile IR for all of its built-in functions (on a single-function basis)

• generate a shared library from this

• have a way to construct a callable kernel given input types using the generated shared library

  then that seems like a pretty good way forward. I see having multiple implementations of the same thing long term as being undesirable. In fairness I think in several places we may have extra logic in casting that is not present in Gandiva, but it would be worth investing the effort to try to have single implementations of things with suitable options to opt in to optional behaviors.

[asfimport]

Micah Kornfield / @emkornfield:
This seems plausible, but it still sounds like LLVM becomes a build-time dependency?  Is that ok for different platforms/toolchain  (e.g. windows)?

[asfimport]

Micah Kornfield / @emkornfield:
I created https://jira.apache.org/jira/browse/ARROW-7083 to track this instead of having the conversation on this JIRA.

[asfimport]

Wes McKinney / @wesm:
Thanks, yes let's discuss more there. It seems like some investigation is indeed required.

I think having LLVM as a build-time dependency is more palatable than as a runtime dependency in some applications.

[asfimport]

Wes McKinney / @wesm:
I'm working on this

[asfimport]

Wes McKinney / @wesm:
I think the path forward here is to refactor to utilize common implementations of inline single-value functions for both the LLVM IR and pre-compiled kernels. In other words, what is currently in the gandiva/precompiled directory would be moved to some place where we can arrange so that these implementations are translated to LLVM IR for use in Gandiva, while available as inline C/C++ functions for use in creating pre-compiled vectorized kernels. Having multiple implementations of the scalar "unit of work" does not seem desirable

Note that Gandiva-generated kernels should be able (with some glue) to be registered in the new general function registry in arrow/compute/registry.h