[cfe-dev] memory annotation treatment in the compilation of OpenCL code

[Benyei, Guy]

Hi all,

The easiest way to make Clang add the address space information is to add the command line flag "-ffake-address-space-map", but it should be used for OpenCL testing purposes only.

The true intention was to let the TargetInfo specify a map for the address spaces to be used. The default of this map is all zeros, so all the variables are defined without an address space.

Currently only the PTX and the TCE TargetInfo classes specify address space maps different from the default.

When instantiating TargetInfo, Clang doesn't pass the language opotions, so the X86_32/X86_64 target info classes don't know that an address space map should be defined, or if the "long" variables should be 64 bit wide. A possible solution would be to pass the information about OpenCL being the current environment as part of the tripple, so the target info can change its behavior, or even to use a different target. Other solution would be to pass the language options, but it seems a bit messy to me.

Thanks
     Guy


-----Original Message-----
From: cfe-dev-bounces at cs.uiuc.edu [mailto:cfe-dev-bounces at cs.uiuc.edu] On Behalf Of Alberto Magni
Sent: Tuesday, January 10, 2012 21:39
To: Pekka Jääskeläinen
Cc: cfe-dev at cs.uiuc.edu
Subject: Re: [cfe-dev] memory annotation treatment in the compilation of OpenCL code

Hi Bo,

try the following:

clang -ccc-host-triple ptx32 \
      -Xclang -target-feature -Xclang +ptx23 \
      -Xclang -target-feature -Xclang +sm20 \
      -I$LIBCLC/generic/include -I$LIBCLC/ptx-nvidiacl/include \
      -include $LIBCLC/generic/include/clc/clc.h
-Dcl_clang_storage_class_specifiers \
      -O0 kernels/matrixMul.cl -S -emit-llvm -o matrixMul.ll

where $LIBCLC points to the libclc [1] installation directory.
(This command is a modification of the one by Justin Holewinski you
can find here [2])

I am wondering why the frontend does not lower this piece of
information to the IR-level
when compiling for x86. I think that should be backend's
responsibility to discard the
address space if the target supports only the default one.

Am I missing something ?

[1] http://www.pcc.me.uk/~peter/libclc/
[2] https://jholewinski.org/blog/llvm-3-0-ptx-backend


2012/1/10 Pekka Jääskeläinen <pekka.jaaskelainen at tut.fi>:
> Hello,
>
> On 01/09/2012 11:18 PM, Bo Wu wrote:
>> Then I changed "__global" to "__local" and generate the IR again, but
>> the generated IR is the same as the first one.
>
> When compiling for x86(_64) the address spaces to global and local
> probably point to the same target address space (0) so there's no
> difference in the final IR.
>
>> I am confused because if the "__local" information is lost when
>> generating LLVM IR, how can local memory be used anyway?
>
> Please check this thread from the last March where the local
> memory implementation is discussed:
>
> http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-March/013737.html
>
> Best regards,
> --
> Pekka Jääskeläinen,
> a contributor to the Portable OpenCL (http://launchpad.net/pocl)
> project which uses the Clang's OpenCL C support
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
cfe-dev at cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.