[LLVMdev] [cfe-dev] Function-level metadata for OpenCL (was Re:OpenCL support)

[Mike Gist]

-----Original Message-----
From: cfe-dev-bounces at cs.uiuc.edu [mailto:cfe-dev-bounces at cs.uiuc.edu]
On Behalf Of Anton Lokhmotov
Sent: 21 December 2010 19:18
To: 'Peter Collingbourne'; David Neto; nlewycky at google.com
Cc: cfe-dev at cs.uiuc.edu; llvmdev at cs.uiuc.edu
Subject: Re: [cfe-dev] [LLVMdev] Function-level metadata for OpenCL (was
Re:OpenCL support)

> I don't think we want LLVM-IR coming from an OpenCL C frontend to be
> different for GPU and CPU targets.  In my view, the frontend should be
> parameterised by only two (more or less) parameters: bitness (32/64)
and
> endianness (little/big).  How one can even guarantee e.g. that a
calling
> convention for NVIDIA GPUs is appropriate for ATI GPUs?  So using
calling
> conventions too early on (e.g. between invoking the clBuildProgram()
and
> clCreateKernel() API functions) is a path to implementation
divergence,
> rather than standardisation.

Agreed, there should only be one IR representation.

> This is exactly what we would like to do if metadata
"non-discardability"
> could be guaranteed at least until the clCreateKernel() API function
is
> called.

LLVM doesn't know (and shouldn't know imo) anything about CL API calls
(unless you didn't mean that in which case nevermind :) ). I still don't
think that metadata is the right approach for recording certain CL
specific function attributes. The blog entry that Chris and Devang wrote
back in March detailing metadata makes it quite clear that metadata
shouldn't be used for anything that can't be discarded at whim. So I'm
nervous about adding anything that 'breaks' this design decision,
without actually making the decision to change that design (which
probably needs input from the original authors).

Mike