search for: __always_inline__

...i there, I've recently encountered a piece of code that uses some SSE2 intrinsics and builds with gcc46, but not clang: clang can't find _mm_movpi64_epi64(), while gcc46 defines it in its lib/gcc46/gcc/.../4.6.3/include/emmintrin.h: extern __inline __m128i __attribute__((__gnu_inline__, __always_inline__, __artificial__)) _mm_movpi64_epi64 (__m64 __A) { return _mm_set_epi64 ((__m64)0LL, __A); } extern __inline __m128i __attribute__((__gnu_inline__, __always_inline__, __artificial__)) _mm_set_epi64x (long long __q1, long long __q0) { return __extension__ (__m128i)(__v2di){ __q0,...

....Ltmp0 I'm not sure where the problem lies. Should the inline asm promote the "i1" to "i32" during ISEL? Should it be promoted during inlining? Is there a situation where we require the value to be "i1"? -bw typedef _Bool bool; static inline __attribute__((__always_inline__)) bool bar(bool loc) { asm(".quad 42 + %c0 - .\n\t" : : "i" (loc)); return 1; } int foo(void) { return bar(1); } -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachmen...

...ched all functions, but this should be tested first (the klibc/compiler.h and ctype.h ones, at least), as I was not 100% clear on which behaviour exactly was *intended* in the first place. The general idea is: if __GNUC_STDC_INLINE__ use ?static inline? else ?extern inline?, and add __attribute__((__always_inline__)) if the compiler is new enough ? which means to inline and not add a function version of the code. bye, //mirabilos -- I believe no one can invent an algorithm. One just happens to hit upon it when God enlightens him. Or only God invents algorithms, we merely copy them. If you don't believe...

...ctype.h */ #ifdef __GNUC__ # if __GNUC__ >= 3 -# define __must_inline extern __inline__ __attribute__((always_inline)) +# ifdef __GNUC_STDC_INLINE__ +# define __must_inline extern __inline__ __attribute__((__gnu_inline__)) +# else +# define __must_inline extern __inline__ __attribute__((__always_inline__)) +# endif # else # define __must_inline extern __inline__ # endif

The GCC DejaGNU testsuite has discovered some regressions. Here's one; this was reduced from testsuite/gcc.apple/4656532.c: typedef long long __m64 __attribute__ ((__vector_size__ (8), __may_alias__)); static __inline __m64 __attribute__((__always_inline__, __nodebug__)) _mm_slli_si64 (__m64 __m, int __count) { } __m64 x, y; void t1(int n) { y = _mm_slli_si64(x, n); } Compiled with LLVM-GCC (v76963) on Darwin/x86, this generates an ICE in the GCC/LLVM conversion layer. Here's another test that want's to provoke lots of null pointer...

Hi, While investigating the situation of visibility annotations and linkage in libc++ with the goal of removing uses of `__always_inline__`, Eric Fiselier and I stumbled upon the attached test case, which I don't think Clang compiles properly. Here's the gist of the test case, reduced to the important parts (see the attachment if you want to repro): // RUN: %cxx -shared -o %T/libtest.so %flags %compile_flags -fPIC %s...

...orker function. */ +struct quot_rem + { + long quot; + long rem; + }; + +/* This is the worker function for div and mod. It is inlined into the + respective library function. */ +static __inline__ struct quot_rem +do_31div (unsigned long a, unsigned long b) + __attribute__ ((__const__, __always_inline__)); + +static __inline__ struct quot_rem +do_31div (unsigned long a, unsigned long b) +{ + /* Adjust operands and result if a is 31 bits. */ + long extra = 0; + int quot_digits = 0; + + if (b == 0) + { + struct quot_rem ret; + ret.quot = 0xffffffff; + ret.rem = 0xffffffff; +...

...get brought up at the LLVM devmtg in the context of improving > the stack size of libc++ frames. > > Have you guys considered a different approach to solving this problem? In > the case of libc++, the _LIBCPP_INLINE_VISIBILITY macro currently expands > out to "__attribute__ ((__always_inline__))”. It seems reasonable to me > to have it also add the “nodebug” attribute as well. This should allow > the allocas generated by inlining lots of frames to be promoted to > registers (because there is no debug info to pessimize). Are you suggesting that 'nodebug' should affect...

...void (*zz_siglongjmp)(struct ZZ_SIGJMP_BUF *self, int value) __attribute__((__noreturn__)); sigjmp_buf jmpbuf; } ZZ_SIGJMP_BUF; static void zz_siglongjmp(struct ZZ_SIGJMP_BUF *self, int value) __attribute__((__noreturn__)) __attribute__((__always_inline__)); void zz_siglongjmp(struct ZZ_SIGJMP_BUF *self, int value) { siglongjmp(self->jmpbuf, value); } #define ZZ_SIGSETJMP(zz_sigjmp_buf, savesigs) \ ( (zz_sigjmp_buf).zz_siglongjmp = zz_siglongjmp, \ sigsetjmp((zz_sigjmp_buf).jmpbuf, (savesigs)) ) #define ZZ_SIGLONGJMP(zz_sigjmp...

I haven't been able to figure out from this thread why this attribute is necessary at all. Anonymous or unnamed namespaces were added to C++ for this very purpose, but the ISO C++ Standard does not discuss "linkage" per-se because it is outside the scope of the language specification. But it does describes it in terms of having a hidden name which is "unique" to the

...LLVM devmtg in the context of >> improving the stack size of libc++ frames. >> >> Have you guys considered a different approach to solving this >> problem? In the case of libc++, the _LIBCPP_INLINE_VISIBILITY macro >> currently expands out to "__attribute__ ((__always_inline__))”. It >> seems reasonable to me to have it also add the “nodebug” attribute as >> well. This should allow the allocas generated by inlining lots of >> frames to be promoted to registers (because there is no debug info to pessimize). > > Are you suggesting that 'nod...

...on/trace/tracepoint-analysis.rst @@ -315,7 +315,7 @@ To see where within the function pixmanFillsse2 things are going wrong: 0.00 : 34eeb: 0f 18 08 prefetcht0 (%eax) : } : - : extern __inline void __attribute__((__gnu_inline__, __always_inline__, _ + : extern inline void __attribute__((__gnu_inline__, __always_inline__, _ : _mm_store_si128 (__m128i *__P, __m128i __B) : { : *__P = __B; 12.40 : 34eee: 66 0f 7f 80 40 ff ff movdqa %xmm0,-0xc0(%eax) diff --git a/drivers/stag...

...ort n, void *base, int stride, _tile_data tile); 3. User interfaces. The tile shape and tile data are combined into a struct in C language. The shape of the tile is only allowed to be initialized once. The user interface looks as this. 3 #define __DEFAULT_FN_AMX \ 4 __attribute__((__always_inline__, __nodebug__, __target__("amx-int8"))) 9 typedef struct __tile_str { 10 const char row; 11 const short col; 12 _tile_data tile; 13 }__tile; 14 15 __DEFAULT_FN_AMX 16 void __tile_loadd(__tile *dst, const void *base, long stride) { 17 dst->tile = _tile_loadd_internal(dst->r...

...eating a header file that implements the NEON intrinsics in terms of generic functionality and the Altivec ones. The header file would need to look kind of like this: #if defined(__powerpc__) || defined(__ppc__) #define neon_intrinsic1 ppc_neon_intrinsic1 static __inline__ vec_type __attribute__((__always_inline__, __nodebug__)) ppc_neon_intrinsic1(vec_type a1, vec_type a2) { ... } ... #endif If you look in tools/clang/lib/Headers you'll see lots of example intrinsics header files, and if you look in your build directory in tools/clang/lib/Headers you'll find the arm_neon.h.inc file. You can ce...

...t;> improving the stack size of libc++ frames. > >>> > >>> Have you guys considered a different approach to solving this > >>> problem? In the case of libc++, the _LIBCPP_INLINE_VISIBILITY macro > >>> currently expands out to "__attribute__ ((__always_inline__))”. It > >>> seems reasonable to me to have it also add the “nodebug” attribute as > >>> well. This should allow the allocas generated by inlining lots of > >>> frames to be promoted to registers (because there is no debug info to > pessimize). > >>...

...ze of libc++ frames. >>>>>> >>>>>> Have you guys considered a different approach to solving this >>>>>> problem? In the case of libc++, the _LIBCPP_INLINE_VISIBILITY macro >>>>>> currently expands out to "__attribute__ ((__always_inline__))”. It >>>>>> seems reasonable to me to have it also add the “nodebug” attribute as >>>>>> well. This should allow the allocas generated by inlining lots of >>>>>> frames to be promoted to registers (because there is no debug info to >>&...

On 2 October 2013 12:17, Renato Golin <renato.golin at linaro.org> wrote: > On 2 October 2013 10:12, Steven Newbury <steve at snewbury.org.uk> wrote: > >> How does this make any sense? >> > > I have to agree with you that this doesn't make much sense, but there is a > case where you would want something like that: when the original source > uses NEON

On Tue, 2018-06-05 at 10:05 -0700, Nick Desaulniers wrote: > Functions marked extern inline do not emit an externally visible > function when the gnu89 C standard is used. Some KBUILD Makefiles > overwrite KBUILD_CFLAGS. This is an issue for GCC 5.1+ users as without > an explicit C standard specified, the default is gnu11. Since c99, the > semantics of extern inline have changed

On Tue, 2018-06-05 at 10:05 -0700, Nick Desaulniers wrote: > Functions marked extern inline do not emit an externally visible > function when the gnu89 C standard is used. Some KBUILD Makefiles > overwrite KBUILD_CFLAGS. This is an issue for GCC 5.1+ users as without > an explicit C standard specified, the default is gnu11. Since c99, the > semantics of extern inline have changed

...ort n, void *base, int stride, _tile_data tile); 3. User interfaces. The tile shape and tile data are combined into a struct in C language. The shape of the tile is only allowed to be initialized once. The user interface looks as this. 3 #define __DEFAULT_FN_AMX \ 4 __attribute__((__always_inline__, __nodebug__, __target__("amx-int8"))) 9 typedef struct __tile_str { 10 const char row; 11 const short col; 12 _tile_data tile; 13 }__tile; 14 15 __DEFAULT_FN_AMX 16 void __tile_loadd(__tile *dst, const void *base, long stride) { 17 dst->tile = _tile_loadd_internal(dst->r...