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

[Tanya Lattner]

On Oct 16, 2012, at 2:20 PM, "Villmow, Micah" <Micah.Villmow at amd.com> wrote:

> 
> 
>> -----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.
> 

While I realize that SPIR is driving this patch, ultimately the right solution is what is best for the OpenCL implementation in Clang and not what SPIR has decided it should be. SPIR is an optional extension to OpenCL and not required. Mon Ping and I have brought up many points and issues in previous emails which have gone ignored and unanswered. Recognizing sampler just by the type is not a strong enough reason to make this a pointer, so I think you should go back to the pro/con list and address the concerns and issues that were brought up. 

Thanks,
Tanya



> Hope that clears things up, but feel free to let me know if you have any other
> concerns.
> 
> Micah
>> 
>> -Chris
> 
> 
> 
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev