similar to: [LLVMdev] adding new builtin functions in llvm

Hi, For now no. But I will add this three builtins to CGBuiltin.cpp. If you want, you can be a reviewer of this change. Regards Michael Zuckerman From: Craig Topper [mailto:craig.topper at gmail.com] Sent: Thursday, April 28, 2016 04:53 To: Zuckerman, Michael <michael.zuckerman at intel.com> Subject: Re: r267690 - [Clang][BuiltIn][AVX512]Adding intrinsics for vmovntdqa vmovntpd vmovntps

Hi , In the future, we will address this issue. Regards Michael Zuckerman From: Eric Christopher [mailto:echristo at gmail.com] Sent: Sunday, May 01, 2016 19:54 To: Zuckerman, Michael <michael.zuckerman at intel.com>; Craig Topper <craig.topper at gmail.com> Cc: llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] r267690 - [Clang][BuiltIn][AVX512]Adding intrinsics for vmovntdqa

Hi, I'm building compiler-rt in a ppc64le machine and it is generating the sanitizers fine but it is not generating the builtin library. I tried to compile it in a x86_64 machine and I got the builtin library generated (libclang_rt.builtins-x86_64.a). Taking a look in a cmake config file from compiler-rt, I saw that ppc64 is not in the supported architecture list to generate the builtin

Hello, clang/llvm 4.0.0 generates invalid calls for builtin functions with -mfloat-abi=hard -ffast-math. Small example fail.c: // clang -O2 -target armv7a-none-none-eabi -mfloat-abi=hard -ffast-math -S fail.c -o - extern float sinf (float x); float sin1 (float x) {return (sinf (x));} generates code to pass the parameter in r0 and expect the result in r0. The same code without

GCCBuiltin just gives it a name for clang to lookup. Generally they match up with builtins that gcc also implements, but that's not a requirement. If you add a builtin with the same name to the builtin file in clang's include/clang/Basic/Builtins*.def then they will find each other. You can also just add a builtin to clang's builtin file and catch it in clang's

On Wed, Nov 16, 2011 at 8:05 AM, Alberto Magni <alberto.magni86 at gmail.com>wrote: > Dear Justin, > > I am trying to add the support for some OpenCL builtin functions to > the PTX backend. > The attached file represent the first stub of a patch for the fmax > builtin function. > First off, thanks for helping to improve the PTX back-end! There are really two main

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 > > > >

+ 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:

Hi Sorry ...I know I should be mailing to the clang list but I am waiting for my subscription. My question is on how to name my builtin in source if i have a intrinsic definition like def int_mytarget_get_id : : Intrinsic<[llvm_i32_ty], [llvm_i32_ty]>; I tried __builtin_mytarget_get_id and clang still didnt generate my intrinsic. thanks shrey

All, We have a samba3 domain which provides logon services for Windows clients, and several cifs shares, some for Windows clients and some for linux servers to mount. I am testing samba 4.5.4 in a lab to understand all that needs to happen for a migration to AD on samba4. During testing we bumped up against winbind config for linux member servers. Since we want users to authenticate against AD,

Mon Ping Wang wrote: > Thanks for the info. My impression is that __sync_synchronize takes > no arguments and is the memory barrier, i.e., > "llvm.memory.barrier(i1 true,i1 true,i1 true,i1 true,i1 true)". Is > that right? That's my understanding as well. > I would like a little finer control to express just a > write barrier (st-st) or a read barrier.

Hi, I have an issue with some builtins that are reordered (during instructions selection it seems) with others instructions and/or others builtins. Is it normal? How could I prevent it from happening? Thanks, Romaric

One of the issues the LLVMLinux project is having is with the use of named registers in the Linux kernel code. The kernel uses something like this in order to assign a C variable name to a register (one for each kernel arch). register unsigned long current_stack_pointer asm("esp"); clang doesn't allow this kind of thing which required a patch which less efficient: #define

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

Hi all, A question about statically linking a pass to clang instead of dynamically loading it at runtime. I am stumped on this bug for a while. I inserted a pass under lib/Transforms/mypass directory, registered it with INITIALIZE_PASS and defined createMyPass in the pass. Also I added file mypass.h in include/llvm/Transforms/ to expose the accessor functions that expose my passes. Entries are

Dear Justin, I am trying to add the support for some OpenCL builtin functions to the PTX backend. The attached file represent the first stub of a patch for the fmax builtin function. The test case I am trying is the following: define ptx_device float @f(float %x, float %y) { entry: %z = call float @fmax(float %x, float %y) ret float %z } declare float @fmax(float, float) But at the moment

Hi Luke, What you say makes sense but I'm not sure it is a good way to go. If we are using a gcc function name __sync_synchronize, I generally feel like we should support it with exactly the same signature and not try to extend it. Otherwise, it might lead to some confusion in the future unless they also plan to extend it the same way. -- Mon Ping On Sep 17, 2008, at 1:14 PM,

On 11/05/13 09:26, Konstantin Tokarev wrote: > > 11.10.2013, 01:39, "Jakob Stoklund Olesen" <stoklund at 2pi.dk>: >> On Oct 10, 2013, at 12:32 PM, Behan Webster <behanw at converseincode.com> wrote: >> >>> One of the issues the LLVMLinux project is having is with the use of >>> named registers in the Linux kernel code. The kernel uses

On Mon, Nov 21, 2011 at 3:36 PM, Justin Holewinski <justin.holewinski at gmail.com> wrote: > On Mon, Nov 21, 2011 at 7:01 AM, Alberto Magni <alberto.magni86 at gmail.com> > wrote: >> >> Hi Justin, >> >> attached you find the patch for the integer max instruction. >> The multiclass PTX_INTRINSIC_INT3 in file PTXIntrinsicInstrInfo.td >> is almost

On Mon, Nov 21, 2011 at 7:01 AM, Alberto Magni <alberto.magni86 at gmail.com>wrote: > Hi Justin, > > attached you find the patch for the integer max instruction. > The multiclass PTX_INTRINSIC_INT3 in file PTXIntrinsicInstrInfo.td > is almost an exact copy of PTX_INT3 in PTXInstrInfo.td, maybe > a modification of this class can be defined in a separate file. > I'm