search for: __builtin_

...t; > Looks like the DAG makes them into SDNodes. > > > On Thu, Jun 9, 2016 at 2:35 PM, Ahmed Bougacha <ahmed.bougacha at gmail.com> > wrote: > >> On Thu, Jun 9, 2016 at 11:28 AM, Ryan Taylor <ryta1203 at gmail.com> wrote: >> > I'm assuming that "__builtin_" is a keyword in LLVM. If I have code >> like: >> > >> > #define acos __builtin_acos >> > >> > extern double acos(double, double); >> > >> > double a; >> > void foo(float b) { >> > a = acos(b); >> > } >...

...ique abound (all SSE for example). My problem though as mentioned before is that the frontend support for intrinsics, is undocumented, and implemented in llvm-gcc which I prefer not to hack with (I use a binary precompiled one). As far as I could see it supports the intrinsics using gcc style __builtin_ function names. Currently what I think to do , is the following : 1. Define my intrinsics in a special (which would be preincluded in our build system) .h file (using whatever name convention I want) 2. Then I need to add a pass to llvm which will translate the names of those intrinsics to llvm...

...urce from svn. > > 2) Edit the file gcc/builtins.def > > The comments at the top are helpful, read them. > > a) Add a macro that looks something like > > #undef DEF_MY_BUILTIN > #define DEF_MY_BUILTIN(ENUM, NAME, TYPE, ATTRS) \ > DEF_BUILTIN (ENUM, "__builtin_" NAME, BUILT_IN_MD, TYPE, TYPE, \ > false, false, true, ATTRS, false, true) > > You can figure out what this means based on the comments in the > builtins.def file. Essentially the important magic is the > BUILT_IN_MD flag trickles thro...

On Tue, Jun 7, 2016 at 1:57 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > Tim, > > Currently, I have to do multiple things: > > 1) create some setLibcallNames in XXXISelLowering.cpp to generate correct > naming for RTLIBS. > 2) lower ISD down to an RTLIB for some calls (and then do solution 1 on > those to get correct names) These solve a related but different -

...in the high bits, and does not flag an error. The code generator knows that the high bits can be undef, and can emit the widened load to memory as appropriate. We can teach the optimizers to *try* to transform C code forming these patterns into such a load for canonicalization, and we can provide a __builtin_....(...) syntax for explicitly performing such a load. PS: The syntax might equally well be "load i64* %ptr as i8'; it all depends on what the most natural way to form this pattern in IR is -- produce an i8 value or an i64 with undef high bits? require the pointer to be the wide type or t...

On 2/18/2013 8:08 PM, Chris Lattner wrote: > > That code is presumably compiled by someone. If whoever compiles it specifies -fno-builtin, the attribute would be added to it. It doesn't affect its clients. I thought that no-builtin attached to foo means that foo should not be considered a builtin function. For example, if someone wrote their own printf, they may want to mark it as

...example). > My problem though as mentioned before is that the frontend support for > intrinsics, is undocumented, and implemented > in llvm-gcc which I prefer not to hack with (I use a binary > precompiled one). As far as I could see it supports the > intrinsics using gcc style __builtin_ function names. > > Currently what I think to do , is the following : > > 1. Define my intrinsics in a special (which would be preincluded in our > build system) .h file (using whatever name convention I want) > 2. Then I need to add a pass to llvm which will translate the names...

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

...insics, unless they require some special handling in the C++ code, which I do not see being the case here. When you define a new intrinsic, use the following template as a name: int_ptx_max. This will define the LLVM intrinsic as @llvm.ptx.max(). Please follow the same convention when naming the __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 llc crashes sa...

...ave the first > patch. > > > >>> > >>> When you define a new intrinsic, use the following template as a name: > >>> int_ptx_max. This will define the LLVM intrinsic as @llvm.ptx.max(). > >>> Please follow the same convention when naming the __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,...

...atch. >> > >> >>> >> >>> When you define a new intrinsic, use the following template as a name: >> >>> int_ptx_max.  This will define the LLVM intrinsic as @llvm.ptx.max(). >> >>>  Please follow the same convention when naming the __builtin_* >> >>> function. >> >>> >> >>>> >> >>>> The test case I am trying is the following: >> >>>> >> >>>> define ptx_device float @f(float %x, float %y) { >> >>>> entry: >> >&...

...gt; >>> > >> >>> When you define a new intrinsic, use the following template as a > name: > >> >>> int_ptx_max. This will define the LLVM intrinsic as > @llvm.ptx.max(). > >> >>> Please follow the same convention when naming the __builtin_* > >> >>> function. > >> >>> > >> >>>> > >> >>>> The test case I am trying is the following: > >> >>>> > >> >>>> define ptx_device float @f(float %x, float %y) { > >> &gt...

On Tue, Jan 24, 2012 at 1:08 PM, John Criswell <criswell at illinois.edu>wrote: > On 1/24/12 2:31 PM, Duncan Sands wrote: > >> Hi Kostya, >> >> As far as I can see the C and C++ standards are not relevant. ASAN >>> works on >>> LLVM IR, not on C or C++. Lots of different languages have LLVM >>> frontends. I >>>

Folks, I just had a discussion about __builtin_stack_pointer in the GCC list, and there were a number of arguments against it, and it got me thinking I didn't have strong arguments against GNU's named register extension. Does anyone remember the arguments for not implementing that extension? My view is that making it an intrinsic (say @...

...a new intrinsic, use the following template as a >> >> >>> name: >> >> >>> int_ptx_max.  This will define the LLVM intrinsic as >> >> >>> @llvm.ptx.max(). >> >> >>>  Please follow the same convention when naming the __builtin_* >> >> >>> function. >> >> >>> >> >> >>>> >> >> >>>> The test case I am trying is the following: >> >> >>>> >> >> >>>> define ptx_device float @f(float %x, float...

...s, and does not flag an error. The code generator knows that the high bits > can be undef, and can emit the widened load to memory as appropriate. We can > teach the optimizers to *try* to transform C code forming these patterns into > such a load for canonicalization, and we can provide a __builtin_....(...) > syntax for explicitly performing such a load. > > PS: The syntax might equally well be "load i64* %ptr as i8'; it all depends on > what the most natural way to form this pattern in IR is -- produce an i8 value > or an i64 with undef high bits? require the pointer...

...wing template > as a > >> >> >>> name: > >> >> >>> int_ptx_max.  This will define the LLVM intrinsic as > >> >> >>> @llvm.ptx.max(). > >> >> >>>  Please follow the same convention when naming the > __builtin_* > >> >> >>> function. > >> >> >>> > >> >> >>>> > >> >> >>>> The test case I am trying is the following: > >> >> >>>> > >> >> >>>> define ptx_d...

...; >> >>> name: > >> >> >> >>> int_ptx_max. This will define the LLVM intrinsic as > >> >> >> >>> @llvm.ptx.max(). > >> >> >> >>> Please follow the same convention when naming the > >> __builtin_* > >> >> >> >>> function. > >> >> >> >>> > >> >> >> >>>> > >> >> >> >>>> The test case I am trying is the following: > >> >> >> >>>> > &g...

...s a >> >> >> >>> name: >> >> >> >>> int_ptx_max.  This will define the LLVM intrinsic as >> >> >> >>> @llvm.ptx.max(). >> >> >> >>>  Please follow the same convention when naming the >> __builtin_* >> >> >> >>> function. >> >> >> >>> >> >> >> >>>> >> >> >> >>>> The test case I am trying is the following: >> >> >> >>>> >> >> >> >&...

...gt; name: > > >> >> >> >>> int_ptx_max. This will define the LLVM intrinsic as > > >> >> >> >>> @llvm.ptx.max(). > > >> >> >> >>> Please follow the same convention when naming the > > >> __builtin_* > > >> >> >> >>> function. > > >> >> >> >>> > > >> >> >> >>>> > > >> >> >> >>>> The test case I am trying is the following: > > >> >> >>...