search for: __has_builtin

...} > > compiling with > clang --target=armv7l -mfloat-abi=hard hello.c -S > > This generates the call to __mulodi4 > > same code with gcc does not. > > I see that sqlite3 as well as m4 package pokes the compiler for these > builtins before using them. For clang it uses __has_builtin() to > determine if a given builtin is supported before using it. > > see > http://git.savannah.gnu.org/cgit/gnulib.git/tree/lib/xalloc-oversized.h > > That is the source of trouble, since its in gnulib that explains why its > showing up in lot of packages. > > perhaps th...

...r. MSVC 2015 doesn't support C++14 extended constexpr. I don't know how well it optimises a recursive strlen. This works as an optimisation for GCC and Clang, and doesn't make things worse for MSVC: /// Construct a string ref from a cstring. LLVM_ATTRIBUTE_ALWAYS_INLINE +#if __has_builtin(__builtin_strlen) + /*implicit*/ constexpr StringRef(const char *Str) + : Data(Str), Length(Str ? __builtin_strlen(Str) : 0) {} +#else /*implicit*/ StringRef(const char *Str) : Data(Str), Length(Str ? ::strlen(Str) : 0) {} +#endif -- Malcolm Parsons

...mp; __clang_minor__ >= 6)) /* clang */ > > which I have tested with clang 3.6. If someone has an earlier version > of clang and can verify that it work, I'll drop the version number. Maybe it's simpler to add #ifndef __has_attribute #define __has_attribute(x) 0 #endif #ifndef __has_builtin #define __has_builtin(x) 0 #endif somewhere before their use? (see http://clang.llvm.org/docs/LanguageExtensions.html )

After this patch, all FLAC__SSEN_SUPPORTED variables are undefined for GCC, so intrinsic versions of functions are not compiled into libFLAC. Previously, the code was: #if defined __INTEL_COMPILER // definitions for ICC #elif defined _MSC_VER // definitions for MSVC #elif defined __GNUC__ || defined __clang__ #if defined __clang__ && __has_attribute(__target__) //

Hi Khem, On Fri, Mar 10, 2017 at 1:03 PM, Khem Raj via llvm-dev <llvm-dev at lists.llvm.org> wrote: > On Fri, Mar 10, 2017 at 7:01 AM, Renato Golin via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> ARM and AArch64 looking good, uploaded. >> > > This is not particularly related to this RC but in general with 4.0.0 > I am seeing a failure quite common

On 29 November 2016 at 17:38, Zachary Turner <zturner at google.com> wrote: > I see, but I looked over your proposed implementation from earlier in the > thread, and if I'm not mistaken I see this: That's a different suggestion. > That said, what did you think about my other proposal of the complicated UDL > with macro? > > #define LIT(x) x_string_ref_literal >

...extended constexpr. I don't know how well > it optimises a recursive strlen. > > This works as an optimisation for GCC and Clang, and doesn't make things > worse for MSVC: > > /// Construct a string ref from a cstring. > LLVM_ATTRIBUTE_ALWAYS_INLINE > +#if __has_builtin(__builtin_strlen) > + /*implicit*/ constexpr StringRef(const char *Str) > + : Data(Str), Length(Str ? __builtin_strlen(Str) : 0) {} #else > /*implicit*/ StringRef(const char *Str) > : Data(Str), Length(Str ? ::strlen(Str) : 0) {} > +#endif > > -- > Ma...

...extended constexpr. I don't know how well > it optimises a recursive strlen. > > This works as an optimisation for GCC and Clang, and doesn't make things > worse for MSVC: > > /// Construct a string ref from a cstring. > LLVM_ATTRIBUTE_ALWAYS_INLINE > +#if __has_builtin(__builtin_strlen) > + /*implicit*/ constexpr StringRef(const char *Str) > + : Data(Str), Length(Str ? __builtin_strlen(Str) : 0) {} #else > /*implicit*/ StringRef(const char *Str) > : Data(Str), Length(Str ? ::strlen(Str) : 0) {} > +#endif > > -- > Ma...

...extended constexpr. I don't know how well > it optimises a recursive strlen. > > This works as an optimisation for GCC and Clang, and doesn't make things > worse for MSVC: > > /// Construct a string ref from a cstring. > LLVM_ATTRIBUTE_ALWAYS_INLINE > +#if __has_builtin(__builtin_strlen) > + /*implicit*/ constexpr StringRef(const char *Str) > + : Data(Str), Length(Str ? __builtin_strlen(Str) : 0) {} #else > /*implicit*/ StringRef(const char *Str) > : Data(Str), Length(Str ? ::strlen(Str) : 0) {} > +#endif > > -- > Ma...

On 29 November 2016 at 16:18, Zachary Turner <zturner at google.com> wrote: > I don't like the llvm_strlen approach as it is incompatible with > std::string_view which we may eventually move to. In what way is it incompatible? constexpr StringRef(const char* s) : Data(s), Length(llvm_strlen(s)) {} is equivalent to constexpr string_view(const char* s) : Data(s),

...extended constexpr. I don't know how well > it optimises a recursive strlen. > > This works as an optimisation for GCC and Clang, and doesn't make things > worse for MSVC: > > /// Construct a string ref from a cstring. > LLVM_ATTRIBUTE_ALWAYS_INLINE > +#if __has_builtin(__builtin_strlen) > + /*implicit*/ constexpr StringRef(const char *Str) > + : Data(Str), Length(Str ? __builtin_strlen(Str) : 0) {} #else > /*implicit*/ StringRef(const char *Str) > : Data(Str), Length(Str ? ::strlen(Str) : 0) {} > +#endif > > -- > Ma...

Hi all, There is a desire to be able to create constexpr StringRefs to avoid static initializers for global tables of/containing StringRefs. Creating constexpr StringRefs isn't trivial as strlen isn't portably constexpr and std::char_traits<char>::length is only constexpr in C++17. Alp Toker tried to create constexpr StringRefs for strings literals by subclassing StringRef:

...xtended to support conditional operators as well. The builtin might not be useful for C arrays, where access is defined as row-major and always linearized. But libraries could make use of the builtin, for instance a Matrix class with overloaded operator: double &operator()(int x, int y) { #if __has_builtin(__builtin_subscript) return __builtin_subscript(data, x, y); #else return data[x*n+y]; #endif } A special case are jagged arrays/pointers to pointers of arrays which are very common in preexisting code bases. To ensure non-aliasing, we would need a pairwise check for aliasing of every subarray...

** *Hi everyone,As you may know, stock LLVM does not provide the kind of advanced loop transformations necessary to provide good performance on many applications. LLVM's Polly project provides many of the required capabilities, including loop transformations such as fission, fusion, skewing, blocking/tiling, and interchange, all powered by state-of-the-art dependence analysis. Polly also