[LLVMdev] [PATCH] OpenCL support - update on keywords

Anton Lokhmotov Anton.Lokhmotov at arm.com
Wed Feb 23 03:47:48 PST 2011


Hi Micah,

> The problem is that we use the ordering private, global, constant and
> local, and this is the same ordering that is used on Apple as well. As
> we already have OpenCL binaries out in public, making the change is
> problematic as we want to keep backward compatibility at all costs.
When you say 'binaries', I assume you mean 'LLVM bitcode'? (The ordering of
enums in intermediate code wouldn't matter if the binaries were native x86
code.)  I believe the OpenCL specification provides no guarantees whatsoever
regarding compatibility of binaries: neither between binaries from different
vendors, nor between binaries from the same vendor.  So IMO users who try to
avoid runtime compilation and port binaries between different versions of
AMD SDK actually ask for trouble.  (This doesn't mean I don't appreciate
your concern, however.)

> We have discussed this internally a little bit. What about encoding 
> the address space definition into the data layout string? That way 
> various vendors can be compatible with each other.
This encoding would clearly not be enough for full binary compatibility, and
it would quite solve the problem with binaries that are already out in
public. (Of course, you can assume that if a binary doesn't include the
address space related string, it's an old one using the
private-global-constant-local ordering.)  I think that instead of allowing
this customisation (which will allow an unbounded number of mappings of the
address spaces to integers) we should declare the most sensible order
"standard" or "canonical", and allow the backends to query the binary to see
if it is in the standard form.  Does it make sense?

Thus, we are getting back to the problem of defining the standard form of
representing OpenCL C programs in LLVM-IR.  Soon I'll start sending
proposals for representing different features and solicit feedback from the
list.

Best regards,
Anton.







More information about the llvm-dev mailing list