Re: plugin hooks for plugin-provided builtins?
On 9/14/10 8:46 AM, Basile Starynkevitch wrote: My current work aims to translate some Gimple into OpenCL source code, thus providing GCC with the ability to take advantage of GPU running their proprietary OpenCL compilers without asking the user to learn OpenCL. My understanding is that Gimple does not have the notion of data parallel operations. For example, in Fortran, array operators are lowered to scalarized form. OpenCL does have these semantics. kernels enqueued as an NDRanges are item-by-item data parallel and there are often not any loops expressed in the kernel itself. And kernels that do have lots of control logic, and use lots of registers, global memory, etc. will tend not to work well on GPUs. Remember that for geographical political reasons all my GCC work is more source to source that source to machine oriented. I don't have the expertise, and I am not legitimate (internally in my CEA LIST organization at least, and also w.r.t. of funding French government agencies) to work on anything close to the target processor or silicon in GCC. It seems to me a source to source compiler should definitely retain high level constructs like array operators, DO ALL, OpenMP directives, etc. Marcus
Re: plugin hooks for plugin-provided builtins?
On 9/14/10 10:58 AM, Basile Starynkevitch wrote: It seems to me a source to source compiler should definitely retain high level constructs like array operators, DO ALL, OpenMP directives, etc One can use #pragma-s builtin-s attributes for these. This is why I was trying to push the idea of plugin hooks for builtins. In this use case, what is the GCC middle-end *for* if it does not understand data parallel operations? Even GENERIC lacks the notion, right? (We've been working directly from the Fortran parse tree.) Marcus
Re: Merging Apple's Objective-C 2.0 compiler changes
On 9/13/10 2:04 PM, Ian Lance Taylor wrote: Therefore, I see a clear benefit to clang-gcc, but I do not see a clear benefit to gcc-llvm. Suppose you have large Fortran applications, and want to accelerate parts of them on graphics processors. Several of the OpenCL implementations use LLVM for runtime code generation, so one could compile the application to LTO, and let it go through some expensive stages of the GCC optimizer, and have LLVM bitcode staged for final translation to the GPU ISA. In general, make the distinction between heavy ahead-of-time compilation and light just-in-time compilation along the lines of GCC and LLVM.
