jhuber6 wrote: > There is no better place to do this than with the LLVM compiler when all > necessary information is available via llvm and clang class libraries.
This is only really an advantage for variadic functions, which are very rare all things considered. The `printf` family functions are the only ones that I can think of, and because I've already written robust handling for those we shouldn't need special support in Clang for them. Any other function signature could be calculated up-front in a script for example. The argument passing here would then not require any device allocations, we just send it in 64-byte packets and use a `send_n` if there's an array type argument. > Target emissary APIs like MPI already have commercial-grade host > libraries(including fortran IO runtime). We don't need a heterogeneous > library to manage linking of the device code. In fact, both device and server > code may be contained in a "header" library compiled by the user. The issue is that the host calls must link to the host library. We do not want these function calls to live in the core runtime because it bloats the dependency tree. If we provided a hook to register foreign RPC handlers then this could just be moved elsewhere. For example, I would argue that the Fortran IO handling should live in `flang-rt`. The `libc` handling I argue is exempt from this because linking `libc` is a pretty reasonable expectation, `flang-rt` is not. Also I do not think we should be hacking around the variadic function call ABI here, variadic functions are supposed to go through `va_arg`, everything else is against the C++ standard. https://github.com/llvm/llvm-project/pull/175265 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
