Tom Stellard <[email protected]> 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 [email protected] http://lists.freedesktop.org/mailman/listinfo/mesa-dev
