Compile a PJRTProgram program into a PJRTExecutable.
Usage
pjrt_compile(
program,
compile_options = new_compile_options(),
device = NULL,
xla_options = list()
)Arguments
- program
(
character(1))
A program to compile.- compile_options
(
PJRTCompileOptions)
Compile options.- device
(
NULL|PJRTDevice|character(1))
APJRTDeviceobject or the name of the platform to use ("cpu", "cuda", ...), in which case the first device for that platform is used. The default is to use the CPU platform, but this can be configured via thePJRT_PLATFORMenvironment variable.- xla_options
(named
list())
XLA compiler options for this compilation only. Each is named after a field of XLA'sDebugOptionsmessage (xla.proto), the namesXLA_FLAGStakes without the leading--, and XLA applies it on top of its defaults and ofXLA_FLAGS. The type of a value decides how XLA reads it: alogical(1)sets a boolean option, aninteger(1)an integer option (or an enum by number), adouble(1)a floating-point option, and acharacter(1)is parsed by the option's type –"True"or"False", a number, the name of an enum value, or a comma-separated list for a repeated option, which replaces its whole value. So an integer option takes3Lor"3", but not3, and a single-precision option takes adouble(1)only if it is positive, so0or a negative value has to be given as a string, e.g."0". XLA reports an unknown name or a value of the wrong type when compiling.An option of map type, such as
xla_backend_extra_options, takes acharacter(1)inXLA_FLAGSsyntax: comma-separated entrieskey=value, orkeyfor an empty value, e.g."xla_cpu_use_multi_output_fusion". Its entries are added to those the plugin applies by default, so entries set throughXLA_FLAGSare kept. XLA does not check the entries: it ignores a key it does not know, and some keys count by their presence alone, so"xla_cpu_use_multi_output_fusion=false"turns that option on as well. On the CPU, XLA hands a key that does not start withxla_to LLVM, which ends the R process if it does not know the key.XLA's overrides cannot set a map, so pjrt reads the plugin's
DebugOptions, withXLA_FLAGSapplied, back from a small program it compiles once per client, adds the entries and sends the whole set. That differs from a compilation without map options in a few ways: XLA reads some options only when a compilation sends such a set (withxla_dump_to, it then also writes the compilation's inputs, and it dumps the small program too), and with--xla_flags_reset=truea later change toXLA_FLAGSdoes not reach compilations with map options. Reading the set back needs a plugin that reports the compile options it applies, which the CPU plugin does and the CUDA plugin does not; there, set the option throughXLA_FLAGSbefore the plugin is loaded.
Examples
# Create a simple program
src <- r"(
func.func @main(\%arg0: tensor<2xf32>) -> tensor<2xf32> {
return \%arg0 : tensor<2xf32>
}
)"
prog <- pjrt_program(src = src)
exec <- pjrt_compile(prog)
#> Error: -:2:17: error: unexpected character
#> <unknown>:0: error: Failed to parse using StableHLO v1.23.0, this could indicate forward incompatibility, >12w old unsupported plugin, or a portable artifact that needs to be further downgraded.
# Write the optimized HLO of this compilation to a directory
dir <- tempfile()
exec <- pjrt_compile(prog, xla_options = list(xla_dump_to = dir))
#> Error: -:2:17: error: unexpected character
#> <unknown>:0: error: Failed to parse using StableHLO v1.23.0, this could indicate forward incompatibility, >12w old unsupported plugin, or a portable artifact that needs to be further downgraded.
list.files(dir)
#> character(0)
# Keep XLA:CPU from duplicating cheap operations into the fusions that use them
exec <- pjrt_compile(
prog,
device = "cpu",
xla_options = list(xla_backend_extra_options = "xla_cpu_use_multi_output_fusion")
)
#> Error: -:2:17: error: unexpected character
#> <unknown>:0: error: Failed to parse using StableHLO v1.23.0, this could indicate forward incompatibility, >12w old unsupported plugin, or a portable artifact that needs to be further downgraded.