search for: languageextensions

..., not something intended for > users to manually edit themselves. You can do it, but it’s tedious and > error prone. If you need more control over the vectorisation than the > pragmas allow, then the C intrinsics are the best choice. > > Amara > > [1] http://clang.llvm.org/docs/LanguageExtensions.html# > extensions-for-loop-hint-optimizations > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > -- Sincerely, Linchuan -------------- next par...

...s designed to be machine friendly, not something intended for users to manually edit themselves. You can do it, but it’s tedious and error prone. If you need more control over the vectorisation than the pragmas allow, then the C intrinsics are the best choice. Amara [1] http://clang.llvm.org/docs/LanguageExtensions.html#extensions-for-loop-hint-optimizations <http://clang.llvm.org/docs/LanguageExtensions.html#extensions-for-loop-hint-optimizations> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180108/3b63bd7a/a...

...ed for > users to manually edit themselves. You can do it, but it’s tedious and > error prone. If you need more control over the vectorisation than the > pragmas allow, then the C intrinsics are the best choice. > > Amara > > [1] http://clang.llvm.org/docs/LanguageExtensions.html# > extensions-for-loop-hint-optimizations A large portion of user still use intrinsics too, as provided in avxintrin.h and the likes. They are then lowered to a single/few llvm instructions with vector operands.

...it right but is there one that is faster? Is the same approach always the best or it depends on the CPU? I believe that those questions are best answered by the compiler. Then some side-notes regarding clang documentation __builtin_shufflevector is not referenced there https://clang.llvm.org/docs/LanguageExtensions.html#vectors-and-extended-vectors Best regards, Alexandre Bique On Wed, Aug 19, 2020 at 8:34 PM Craig Topper <craig.topper at gmail.com> wrote: > I'm not sure everyone would agree that the behavior of a > __builtin_vector_hadd should do what the X86 instruction does. It takes tw...

Hi LLVM, clang, I'm trying to write a portable version of __builtin_add_overflow() it a way that the compiler would recognize the pattern and use the add_overflow intrinsic / the best possible machine instruction. Here are docs about these builtins: https://clang.llvm.org/docs/LanguageExtensions.html#checked-arithmetic-builtins . With unsigned types this is easy: int uaddo_native(unsigned a, unsigned b, unsigned* s) { return __builtin_add_overflow(a, b, s); } int uaddo_portable(unsigned a, unsigned b, unsigned* s) { *s = a + b; return *s < a; } We get exactly the same assembly: uadd...

...foo __attribute__((address_space(256))) #define bar __attribute__((address_space(257))) in some header? (Or on the command line, or in clang's default #defines, ...) Though maybe they'd need to be in a slightly different place; the example in the documentation (http://clang.llvm.org/docs/LanguageExtensions.html) is #define GS_RELATIVE __attribute__((address_space(256))) int foo(int GS_RELATIVE *P) { return *P; } so maybe it won't work if they're in front of the declaration. And of course, they're not technically keywords... > Furthermore, if I wanted this keyword to be ad...

Thanks Amara so much for the info! One more question: what do people usually do if they want to generate vectorized code for some existing c/c++ code? Do they usually do C/C++ source level transformation, or do at LLVM's IR level? I know clang supports auto vectorizations, such as loop vectorization and SLP, but they are not flexible enough if we want to do more custom vectorizations or

...e whether a branch is non-divergent. For example, if a condition is not derived from blockIdx or threadIdx, it is guaranteed to hold the same value for all threads in a warp. How the compiler can leverage these annotationsSimilar to the annotations for loop optimizations (http://clang.llvm.org/docs/LanguageExtensions.html#extensions-for-loop-hint-optimizations <http://clang.llvm.org/docs/LanguageExtensions.html#extensions-for-loop-hint-optimizations>), clang can attach metadata to the branch instructions following "#pragma clang non_divergent". For example, the source code snippet in the previou...

...; non-divergent. For example, if a condition is not derived from blockIdx or > threadIdx, it is guaranteed to hold the same value for all threads in a > warp. How the compiler can leverage these annotationsSimilar to the > annotations for loop optimizations > (http://clang.llvm.org/docs/LanguageExtensions.html#extensions-for-loop-hint-optimizations > <http://clang.llvm.org/docs/LanguageExtensions.html#extensions-for-loop-hint-optimizations>), > clang can attach metadata to the branch instructions following "#pragma > clang non_divergent". For example, the source code snippet...

How can I tell at compile time through predefined macros whether libc++ includes/supports the C++14 header file shared_mutex ? Given that I have identified that libc++ is being used, will this work ? : #if __cplusplus >= 201402 // Header file shared_mutex supported #endif or do I need to check something else ?

Hi all, Hypothetically, suppose I have a generic system with multiple address spaces such that each address space is accessed using different instructions. Now suppose, I wanted to add a new keywords 'foo' and 'bar' to the front of c variables and function return types such that the following would be valid: foo void* a; foo void* somefunc(){...} bar int b; int somefunc2(bar

...ibrary, by relying on LLVM for generating tiled & fused loops for matrix operations. We propose adding a new matrix value type, that can be declared via a `matrix_type` attribute. Alternatively we could also generalise the existing ext_vector_type attribute ([6] <https://clang.llvm.org/docs/LanguageExtensions.html#vectors-and-extended-vectors>), if that is preferred. Initially, the matrix type supports 2 dimensions (rows & columns). For example, a 4x4 float matrix would be declared as `typedef float m4x4_t __attribute__((matrix_type(4, 4)));`. Initially we want to focus on 2D matrixes without p...

Hi, I'm trying to implement an overloading behavior to some of our builtin functions, and came across the following comment in SemaExpr.cpp // Check for overloaded calls. This can happen even in C due to extensions. If (Fn->getType() == Context.OverloadTy) { .... I was wondering which C extensions is this referring to? Thanks Ali -------------- next part -------------- An HTML attachment

...^ foo.cpp:18:36: note: candidate function __attribute__((overloadable)) void foo(enum Three); ^ 1 error generated. While with "-x c++" both versions of Clang compiled it successfully (failed to link though). According to http://clang.llvm.org/docs/LanguageExtensions.html#function-overloading-in-c overloadable attribute is an analogue for C++ function overloading in C. So, is it a bug in the Clang or I didn't understand/consider something? BR, Andrey Lizunov -------------------------------------------------------------------- Closed Joint Stock Company I...

...er 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 )

...edit themselves. You can do it, but it’s tedious > and > > error prone. If you need more control over the vectorisation than the > > pragmas allow, then the C intrinsics are the best choice. > > > > Amara > > > > [1] http://clang.llvm.org/docs/LanguageExtensions.html# > > extensions-for-loop-hint-optimizations > > A large portion of user still use intrinsics too, as provided in > avxintrin.h and the likes. They are then lowered to a single/few > llvm instructions with vector operands. > _____________________________________________...

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__) //

...For example, if a condition is not derived from blockIdx or >> threadIdx, it is guaranteed to hold the same value for all threads in a >> warp. How the compiler can leverage these annotationsSimilar to the >> annotations for loop optimizations >> (http://clang.llvm.org/docs/LanguageExtensions.html#extensions-for-loop-hint-optimizations >> <http://clang.llvm.org/docs/LanguageExtensions.html#extensions-for-loop-hint-optimizations>), >> clang can attach metadata to the branch instructions following "#pragma >> clang non_divergent". For example, the source...

...rogram with both floating point arithmetic and loop pragmas was; Is the loop vectorizer really allowed to vectorize a loop when it can't prove that it is safe to reorder fp math, even if there is a loop pragma that hints about a preferred width. When reading here http://clang.llvm.org/docs/LanguageExtensions.html#extensions-for-loop-hint-optimizations it says " Loop hints can be specified before any loop and will be ignored if the optimization is not safe to apply.". But given this example (see also https://godbolt.org/z/fzRHsp ) //---------------------------------------------------------...

...nt NEON (instructions and > intrinsics) on the 64-bit ARM architecture (AArch64). > Great! It seemed quite confusing that this is the main official information one gets when searching for "arm neon clang llvm", especially when parts of the documentation ( http://clang.llvm.org/docs/LanguageExtensions.html#langext-vectors) claim that clang supports NEON. I am happy that it actually does. > > I also tried compiling LLVM 2.9 + llvm-gcc but that failed too many times > > and I gave up. > > Yep. llvm-gcc is long dead, and LLVM 2.9 isn't much healthier. > I was thinking it...