[cfe-dev] [RFC][OpenCL] New representation for sampler_t and its literal initializer

[Anastasia Stulova via cfe-dev]

Hi Sam,

I am just not sure whether having a struct solution is generic enough, certainly less generic than just having __initialize_sampler call.

On the other hand,  having this struct offers more functionality (avoid splitting sampler fields later on).

Cheers,
Anastasia

From: Liu, Yaxun (Sam) [mailto:Yaxun.Liu at amd.com]
Sent: 10 June 2016 16:14
To: Anastasia Stulova; cfe-dev (cfe-dev at lists.llvm.org); Bader, Alexey (alexey.bader at intel.com); Pan, Xiuli
Cc: Tom Stellard; Sumner, Brian; Tye, Tony; nd
Subject: RE: [RFC][OpenCL] New representation for sampler_t and its literal initializer

Anastasia,

Thanks for the feedback.

Right all the sampler variables will become local (function scope).

I have some updates to the proposal by Brian's suggestions to accommodate OpenCL C++'s needs since they represent the sampler initializer by struct.

Basically,

1.       Change the builtin function name from __initialize_sampler to  __translate_sampler_initializer.

2.       Keep the concrete struct type for sampler initializer in Khronos Clang.

3.       Change the argument of __translate_sampler_initializer from int to the sampler initializer struct. Clang will translate the OpenCL sampler literal to the sampler initializer struct first, then pass it to __translate_sampler_initializer.


Here is the updated example:

sampler_t s = ADDR | NORM | FILT;

void f() {
  g(s);
}


=>  Llvm bitcode equivalent to (assuming __sampler is the opaque struct type to represent sampler_t):

// opaque struct type for sampler
struct __sampler;
// concrete sampler initializer struct type
struct __sampler_initializer {
  int addr;
  int normalization;
  int filter;
};

constant __sampler *__attribute__((always_inline)) __translate_sampler_initializer(struct __sampler_initializer); // a builtin function for translating sampler initializer

constant struct __sampler_initializer _SI = {ADDR, NORM, FILT};
void f() {
  constant __sampler *_s = __translate_sampler_initializer(_SI);
  g(_s);
}

Thanks.

Sam

From: Anastasia Stulova [mailto:Anastasia.Stulova at arm.com]
Sent: Friday, June 10, 2016 10:16 AM
To: Liu, Yaxun (Sam) <Yaxun.Liu at amd.com<mailto:Yaxun.Liu at amd.com>>; cfe-dev (cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>) <cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>>; Bader, Alexey (alexey.bader at intel.com<mailto:alexey.bader at intel.com>) <alexey.bader at intel.com<mailto:alexey.bader at intel.com>>; Pan, Xiuli <xiuli.pan at intel.com<mailto:xiuli.pan at intel.com>>
Cc: Tom Stellard <tom at stellard.net<mailto:tom at stellard.net>>; Sumner, Brian <Brian.Sumner at amd.com<mailto:Brian.Sumner at amd.com>>; Tye, Tony <Tony.Tye at amd.com<mailto:Tony.Tye at amd.com>>; nd <nd at arm.com<mailto:nd at arm.com>>
Subject: RE: [RFC][OpenCL] New representation for sampler_t and its literal initializer

Hi Sam,

I agree the original implementation of sampler type in LLVM isn't ideal.

Your approach seems sensible to me. Would this mean that all sampler variables will be transformed to local by Clang?

Thanks,
Anastasia

From: Liu, Yaxun (Sam) [mailto:Yaxun.Liu at amd.com]
Sent: 09 June 2016 21:18
To: cfe-dev (cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>); Anastasia Stulova; Bader, Alexey (alexey.bader at intel.com<mailto:alexey.bader at intel.com>); Pan, Xiuli
Cc: Tom Stellard; Sumner, Brian; Tye, Tony
Subject: [RFC][OpenCL] New representation for sampler_t and its literal initializer

Hi,

Currently Clang use int32 to represent sampler_t, which have been a source of issue for some backends, because in some backends sampler_t cannot be represented by int32. They have to depend on kernel argument metadata and use IPA to find the sampler arguments and global variables and transform them to target specific sampler type.

Khronos Clang spirv-1.0 branch (https://github.com/KhronosGroup/SPIR/tree/spirv-1.0 ) represents sampler_t as an opaque struct pointer. Also it represents sampler literal as a concrete struct type, and cast its pointer to a pointer to the opaque struct type for sampler_t. However there are two issues with the way how sampler literal is represented:


1.       Backends still need to translate the sampler initializer struct to target specific sampler initializer, and this transformation cannot be implemented by library functions. Instead, it needs to be done by passes.

2.       Optimizer may try to optimize the sampler global variable initialized with a sampler initializer struct. The optimizer will assume the sampler contains the bits of the initializer struct and may do memory optimizations on it, which will cause difficulty for backends to transform the samplers.

We think representing sampler as an opaque type is a good idea, which we suggest Clang trunk to adopt. And we propose a another way to represent sampler literal. Basically in Clang codegen we generate a function call for each reference of a sampler global variable initialized with a sampler literal, e.g.

sampler_t s = 0;

void f() {
  g(s);
}


=>  Llvm bitcode equivalent to (assuming __sampler is the opaque struct type to represent sampler_t):

constant __sampler *__attribute__((always_inline)) __initialize_sampler(int); // a builtin function for initialize a sampler

void f() {
  constant __sampler *_s = __initialize_sampler(0);
  g(_s);
}

Each builtin library can implement its own __initialize_sampler(). Since the real sampler type tends to be architecture dependent, allowing it to be initialized by a library function simplifies backend design. A typical implementation of __initialize_sampler could be a table lookup of real sampler literal values. Since its argument is always a literal, the returned pointer is known at compile time and easily optimized to finally become some literal values directly put into image read instructions.

The advantage of this representation is:


1.       Robust - can be optimized without losing information

2.       Easy to implement - can be implemented by library instead of pass

Your feedbacks are welcome. Thanks.

Sam






-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160613/2d4a3e8e/attachment.html>