[cfe-dev] OpenCL & SPIR specific types - proposal and patch

[Villmow, Micah]

> -----Original Message-----
> From: Chris Lattner [mailto:clattner at apple.com]
> Sent: Tuesday, October 16, 2012 2:09 PM
> To: Villmow, Micah
> Cc: Mon Ping Wang; Anton.Lokhmotov at arm.com; cfe-dev at cs.uiuc.edu
> Subject: Re: [cfe-dev] OpenCL & SPIR specific types - proposal and patch
> 
> 
> On Oct 16, 2012, at 8:17 AM, "Villmow, Micah" <Micah.Villmow at amd.com>
> wrote:
> 
> > Mon Ping,
> > I think you are misunderstanding the point of SPIR. Backends
> themselves should not be handling SPIR. SPIR should be lowered to valid
> LLVMIR for your platform, and then optimizations can be applied to the
> resulting LLVMIR. It is in this loading that you can convert from
> spir.sampler_t into an i32 and then constant propagation will work just
> like normal. One reason why sampler_t is an opaque type is that
> different vendors have different implementations and some do not want
> their implementations to be a i32, but want to represent it closer to
> their hardware.
> 
> Hi Micah,
> 
> I don't care or have any opinion about samplers, but we're not going to
> start disabling specific optimizations in LLVM based on type names.
> 
> If SPIR builds on top of LLVM, it will need to follow the design and
> approach of LLVM.  Also, expecting a "loader" to swizzle types on
> something is just plain weird, because it will throw off all sorts of
> things in the optimizer.  You can't expect to change a pointer to some
> other type after optimizations have run.
> 
> If your notion is that SPIR is not intended to be "valid IR" but that it
> is "lowered to" valid IR, then there is a bigger problem.
[Villmow, Micah] I think there is a misunderstanding here, probably because of
my explanation, but a misunderstanding none the less. SPIR itself is
valid IR and optimizations can be run on it. There is no problem here,
what is the issue is whether an opaque type in OpenCL should be represented
as an opaque type in SPIR or not. One way to implement it is as an i32 type,
but there are other ways to implement it and in my view, SPIR should not
restrict its representation to a single implementation but try to map it
in a way that an implementation can choose how to implement it. You can write
optimizations that write directly on SPIR types, but I wouldn't expect
the current crop of optimizations to work on them without modification,
which is the case for any opaque type.

Hope that clears things up, but feel free to let me know if you have any other
concerns.

Micah
> 
> -Chris