similar to: Generating SPIR

Thanks a lot. On Mon, Sep 12, 2016 at 1:42 PM, Liu, Yaxun (Sam) <Yaxun.Liu at amd.com> wrote: > If you use the default header file under clang/lib/Headers/opencl-c.h, > get_global_id will be mangled. > > > > If you want to declare get_global_id in your own header, add > __attribute__((overloadable)), then it will be mangled. > > > > Sam > > > >

Hi all, According to the SPIR 2.0 spec[1], the name of OpenCL builtins are mangled. However, when I compile OpenCl code with Clang 3.9 with the "spir64-unknown-unknown" target, Clang generates IR without mangling the builtins, e.g. for: __kernel void input_zip_int(__global int *in0) { *in0 = get_global_id(0); } clang generates: define spir_kernel void @input_zip_int(i32

+ Alexey Anastasia According to SPIR spec v1.2 s2.10.3 2.10.3 The printf function The printf function is supported, and is mangled according to its prototype as follows: int printf(constant char * restrict fmt, ... ) Note that the ellipsis formal argument (...) is mangled to argument type specifier z It seems printf should be mangled. Alexey/Anastasia, What do you think? Thanks. Sam From:

Hello, Since 2015 Khronos has switched to the new portable intermediate format SPIR-V, which has replaced the original SPIR. The advantage is that it offers higher portability across different toolchains. There was a talk about it at a Dev Meeting: http://llvm.org/devmtg/2017-03//2017/02/20/accepted-sessions.html#17 LLVM currently only supports SPIR format for OpenCL in Clang. Several Khronos

On Mon, 10 Sep 2018 at 18:47, Nicholas Wilson via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I was going to wait until Neil Trevett got back to me about becoming a > SPIR-V TSG advisor but this seems like just as good an opportunity. Please > see the previous discussion [1] if you have not already, there were many > relevant points made. > > First, I’d like to note

I don't see any problem mangling it to be honest even though there seems to be only one prototype anyways. We could add restrict in as well. Cheers, Anastasia ________________________________ From: Hongbin Zheng <etherzhhb at gmail.com> Sent: 17 September 2016 05:32:54 To: Liu, Yaxun (Sam) Cc: cfe-dev at lists.llvm.org; llvm-dev; Bader, Alexey (alexey.bader at intel.com); Anastasia

On Tue, 11 Sep 2018 at 19:40, Tom Stellard via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On 09/11/2018 12:50 PM, Richard Smith via llvm-dev wrote: > > On Mon, 10 Sep 2018 at 18:47, Nicholas Wilson via llvm-dev < > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > > > I was going to wait until Neil Trevett got back to me

Hi all, Recently I do some jobs based on llvm-link tool. I wonder why link '@llvm.global_ctors' into dest file, even it's not used in dest file? And how can I remove it? Thank you all in advance! Fangqing Xilinx Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL:

> On Sep 11, 2018, at 7:39 PM, Tom Stellard via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On 09/11/2018 12:50 PM, Richard Smith via llvm-dev wrote: >> On Mon, 10 Sep 2018 at 18:47, Nicholas Wilson via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> I was going to wait until Neil Trevett got back to me

On Wed, 12 Sep 2018 at 16:52, Tom Stellard via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On 09/12/2018 02:32 PM, Matthias Braun wrote: > > > > > >> On Sep 11, 2018, at 7:39 PM, Tom Stellard via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> > >> On 09/11/2018 12:50 PM, Richard Smith via llvm-dev wrote: > >>> On Mon,

Hi all, I'm trying to get the llvm's IR from the source code of Polybench (OMP) https://github.com/cavazos-lab/PolyBench-ACC/tree/master/OpenMP. I noticed a considerable difference between the IR generated using clang -emit-llvm -fopenmp and clang -emit-llvm: * using the -fopenmp flag I get a simplified IR in which I read a single basic block where I can highlight a llvm.memcpy

Dear all, After a huge amount of time trying to install LLVM and Clang i could finally do it, so now im trying to use this tools for generating a bytecode, then apply it modular optimizations and then generate an executable to test the result. First, I only want to compile a project and execute it to see how it works, specifically this one:

Hi Alexey, Your reply has been a great help to me,your way of explain the different types of compilation is very detailed and easy to understand. Even so, I have a couple of questions. 1) What do yourefer by OpenCL RT? 2) Could you give me some examples of an open-source OpenCL implementation and update optimization pipeline? Thank you in advance. Regards El vie., 20 sept. 2019 a las 12:34,

> This is great to see. Is this code the basis of the forks that Anastasia talked about or did those come from somewhere else? Yes, indeed the base is https://github.com/KhronosGroup/SPIRV-LLVM/ and then there are multiple forks that include some rework as well (some of which were announced on the LLVM channels). I think the biggest problems we are trying to solve is: 1. Keeping up to date

On 2018-02-21 — 14:55, Tom Stellard via llvm-dev wrote: > On 02/21/2018 12:15 AM, Tomeu Vizoso via llvm-dev wrote: > > Hi, > > > > for a few months already I have been asking around for opinions on how > > people could best work together on Khronos' SPIR-V <-> LLVM-IR converter > > and some consensus seems to have formed. > > > > Most of the

I note that there was a talk recently at EuroLLVM SPIR-V and LLVM about and so I want to get this message out soon so as to avoid duplicated effort. I have an up to date backend for SPIR-V on an up to date fork (~2-3 weeks behind) of LLVM, transplanted and “modernised” from Khronos’ SPIRV-LLVM that I plan on integrating into LLVM trunk. While it is usable in it’s current form there are several

Yet another implementation of the backend, heh. I’d just started in earnest writing a tablegen based one, with the main goal of fixing the intrinsics to actually be intrinsics. I think it would be a good idea to join forces with the folk at KhronosGroup and consolidate the work done for inclusion into LLVM. Nic > On 17 Jul 2017, at 9:55 pm, Neil Henning via llvm-dev <llvm-dev at

On 5/3/2017 12:04 PM, Tom Stellard via llvm-dev wrote: > On 05/03/2017 11:19 AM, Nicholas Wilson wrote: >>> Right, what I was trying to say is that there are more benefits from >>> having this not be a target than there is from having it be a target. >> Please enumerate them, I have seen none posted so far . The implied “it is what all the the other backends do” w.r.t

> SPIR-V does not have to be a part of LLVM for you to do this. You can add > the SPIR-V target to clang and then define a SPIR-V toolchain (i.e. clang/Driver/Toolchains) > that uses the external tool to translate LLVM IR to SPIR-V. Ok. I guess if Clang community accepts this way, it would be better to set up the SPIRV converter as a tool of LLVM. So the question is are there any

On 02/26/2018 09:25 AM, Anastasia Stulova wrote: > >> This is great to see. Is this code the basis of the forks that Anastasia > talked about or did those come from somewhere else? > > > Yes, indeed the base is https://github.com/KhronosGroup/SPIRV-LLVM/ and then there are multiple forks that include some rework as well (some of which were announced on the LLVM channels).