Tom Stellard <tstel...@gmail.com> writes:
> v2:
> -Separate IR type and LLVM triple
> -Do the OpenCL C->LLVM IR and linking steps for all PIPE_SHADER_IR
> types.
>
> v3:
> - Coding style fixes
> - Removed compatibility code for LLVM < 3.1
> - Split build_module_llvm() into three functions:
> compile(), link(), and build_module_llvm()
> ---
> .../state_trackers/clover/core/compiler.hpp | 2 +
> src/gallium/state_trackers/clover/core/program.cpp | 13 +-
> .../state_trackers/clover/llvm/invocation.cpp | 174
> ++++++++++++++++++--
> 3 files changed, 174 insertions(+), 15 deletions(-)
>
>[...]
> diff --git a/src/gallium/state_trackers/clover/core/program.cpp
> b/src/gallium/state_trackers/clover/core/program.cpp
> index 5ac9f93..a8b7775 100644
> --- a/src/gallium/state_trackers/clover/core/program.cpp
> +++ b/src/gallium/state_trackers/clover/core/program.cpp
> @@ -47,9 +47,16 @@ _cl_program::build(const std::vector<clover::device *>
> &devs) {
>
> for (auto dev : devs) {
> try {
> - auto module = (dev->ir_target() == "tgsi" ?
> - compile_program_tgsi(__source, dev->ir_target()) :
> - compile_program_llvm(__source, dev->ir_target()));
> + // XXX: We need to check the input source to determine which
> + // compile_program() call to use. If the input is TGSI we
> + // should use compile_program_tgsi, otherwise we should use
> + // compile_program_llvm
> + auto module = (dev->ir_format() == PIPE_SHADER_IR_TGSI ?
> + compile_program_tgsi(__source, "") : // XXX Not sure
> + // what value to
> + // use for target.
Just pass dev->ir_target() to compile_program_tgsi() as it was done
before, or remove the argument if you want, it's useless anyway.
> + compile_program_llvm(__source, dev->ir_format(),
> + dev->ir_target()));
> __binaries.insert({ dev, module });
>
> } catch (build_error &e) {
> diff --git a/src/gallium/state_trackers/clover/llvm/invocation.cpp
> b/src/gallium/state_trackers/clover/llvm/invocation.cpp
> index 89e21bf..f862d06 100644
> --- a/src/gallium/state_trackers/clover/llvm/invocation.cpp
> +++ b/src/gallium/state_trackers/clover/llvm/invocation.cpp
>[...]
> + module
> + build_module_llvm(llvm::Module *mod) {
> +
> + module m;
> + struct bitcode_program {
> + // Number of bytes pointed to by code
> + uint32_t num_bytes;
> + // LLVM bitcode
> + unsigned char *code;
> + } *program;
> +
> + unsigned program_bytes;
> +
> + llvm::SmallVector<char, 1024> llvm_bitcode;
> + llvm::raw_svector_ostream bitcode_ostream(llvm_bitcode);
> + llvm::BitstreamWriter writer(llvm_bitcode);
> + llvm::WriteBitcodeToFile(mod, bitcode_ostream);
> + bitcode_ostream.flush();
> +
> + // + 4 bytes for the num_bytes member
> + program_bytes = llvm_bitcode.size() + 4;
> + program = (struct bitcode_program *) MALLOC(program_bytes);
> +
> + program->num_bytes = llvm_bitcode.size() * sizeof(unsigned char);
> + program->code = (unsigned char *)program + 4;
> + memcpy(program->code, &llvm_bitcode[0], program->num_bytes);
> +
OK, I think I didn't explain myself correctly when I suggested you to
use a "struct"... What I meant is, if this convention of storing the
bitcode size at the beginning of an LLVM program is part of the state
tracker/driver interface, wouldn't it make sense to define it as a
struct in some public header file?
>[...]
pgpBumpbz8fcF.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
