You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Extended graph_op IRGen to support calling C APIs directly.
In this PR, we call the TF C API TFE_RunConstOp() instead of the previous
compiler runtime entry point @_silgen_name("_swift_tfc_RunEagerConstTest"), and
then call compiler runtime entry point
@_silgen_name("_swift_tfc_CreateFloatTensorHandleFromCTensorHandle")to wrap it
into a TensorHandle<Float>.
The main changes are:
1. To create an llvm::Function object based on a function name such as
"_swift_tfc_GetGlobalEagerContext", we first call silModule.findFunction() to
get the SILFunction, and then call IGM.getAddrOfSILFunction() to get the
llvm::Function.
To make this work, we fixed a bug in SILDeserializer::readSILFunctionChecked(),
which pervious a function decl (not body) from being deserialized in the IRGen stage.
2. We obtain from llvm::Function objects the LLVM type objects for C data types
TFE_Context* and TFE_TensorHandle*, and then generate bitcast instructions to
put the function params into the right types, before issuing the relevant
function call.
Next steps:
1. Replace the TFE_RunConstOp() call with a sequence of TF eager C API calls.
2. Generalize the graph_op decoding logic to handle graph_op's other than
Const.
3. Support generic tf datatype T instead of the hard-coded Float.
4. Figure out a way to call do scalar promotion even in the case of -Onone,
since Tensor<Float>(1.0) becomes a pseudo graph_op "tfc.scalarToTensor", which
gets should be turn into a "Const" graph_op.
0 commit comments