[Mesa-dev] [PATCH 10/11] clover: Add function for building a clover::module for non-TGSI targets v3

Francisco Jerez currojerez at riseup.net
Thu May 24 19:27:22 PDT 2012


Tom Stellard <tstellar at 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?

>[...]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 229 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20120525/da5bc06c/attachment.pgp>


More information about the mesa-dev mailing list