search for: always_inline

Hi everyone, clang currently implements the 'flatten' function attribute by marking all calls to not 'noinline' functions with 'always_inline'. In effect, only the first level of calls is inlined, not all calls recursively (like gcc does). We briefly discussed possible solutions on IRC: We could add an equivalent LLVM attribute for functions (e.g. 'flatten'). The main problem with this approach occurs when we're inlinin...

Using GCC 3.4.6 20060404 (Red Hat 3.4.6-11) I've had this problem with the ALWAYS_INLINE directive in SelectionDAGISel.cpp: /arm/scratch/egrimley/llvm.svn/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp: In function `bool CheckChildType(const unsigned char*, unsigned int&, llvm::SDValue, const llvm::TargetLowering&, unsigned int)': /arm/scratch/egrimley/llvm.svn/lib/CodeGen/...

...aise the >>> issue on the >>> llvmdev list. We will need IR extensions to support this among >>> other things. >> >> Well, I don't expect __builtin_constant_p to works always. That's not >> precisely the issue. I expect though __attribute__((always_inline)) >> functions to be expanded prior to any optimization pass, because it's >> what it means. Those functions are basically type-safe macros. >> >> If you do that, then my problem go away at once. > > No, that's not the problem. I disagree; I think incomplete s...

...> Barring that, if this is really important to you, please raise the issue on the > llvmdev list. We will need IR extensions to support this among other things. Well, I don't expect __builtin_constant_p to works always. That's not precisely the issue. I expect though __attribute__((always_inline)) functions to be expanded prior to any optimization pass, because it's what it means. Those functions are basically type-safe macros. If you do that, then my problem go away at once. For what it's worth, my always_inline functions are always functions that allow constant-folding of its re...

...if this is really important to you, please raise the issue on the >> llvmdev list. We will need IR extensions to support this among other things. > > Well, I don't expect __builtin_constant_p to works always. That's not > precisely the issue. I expect though __attribute__((always_inline)) > functions to be expanded prior to any optimization pass, because it's > what it means. Those functions are basically type-safe macros. > > If you do that, then my problem go away at once. No, that's not the problem. Before any optimizations can be applied the function mus...

...>>>> issue on the >>>> llvmdev list. We will need IR extensions to support this among >>>> other things. >>> Well, I don't expect __builtin_constant_p to works always. That's not >>> precisely the issue. I expect though __attribute__((always_inline)) >>> functions to be expanded prior to any optimization pass, because it's >>> what it means. Those functions are basically type-safe macros. >>> >>> If you do that, then my problem go away at once. >> No, that's not the problem. > > I disag...

...re not always inlined. AFAIK, this may only happen when > > the caller is in the dead code, but then we don't always successfully > > remove all dead code. > > > > Because of this, we may end up emitting an undefined reference for an > > "inline __attribute__((always_inline))" function. Libc++ relies on the > > compiler never doing that - it has lots of functions in the headers > > marked this way and does _not_ export them from libc++.so. > > > > Current implementation in clang emits alwaysinline+inline functions as > > available_ex...

...ndling of alwaysinline functions in Clang: they are not always inlined. AFAIK, this may only happen when the caller is in the dead code, but then we don't always successfully remove all dead code. Because of this, we may end up emitting an undefined reference for an "inline __attribute__((always_inline))" function. Libc++ relies on the compiler never doing that - it has lots of functions in the headers marked this way and does _not_ export them from libc++.so. Current implementation in clang emits alwaysinline+inline functions as available_externally definitions. The inliner is an SCC pass,...

On Mon, Dec 21, 2015 at 12:08 AM, Aaron Ballman <aaron at aaronballman.com> wrote: > On Sun, Dec 20, 2015 at 5:57 PM, Johan Engelen <jbc.engelen at gmail.com> > wrote: > > > > Perhaps LLVM_ATTRIBUTE_ALWAYS_INLINE could be defined to "inline" if the > > compiler has no support for always_inline (currently it is set to > nothing in > > that case) ? > > I think this would allow removal of the "inline" after > > LLVM_ATTRIBUTE_ALWAYS_INLINE. > > Wouldn't...

...ather than c99. This prevents multiple symbol definition errors > + * of extern inline functions at link time. > */ > #if !defined(CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING) || \ > !defined(CONFIG_OPTIMIZE_INLINING) || (__GNUC__ < 4) > -#define inline inline __attribute__((always_inline,unused)) notrace > -#define __inline__ __inline__ __attribute__((always_inline,unused)) notrace > -#define __inline __inline __attribute__((always_inline,unused)) notrace > +#define inline \ > + inline __attribute__((always_inline, unused, gnu_inline)) notrace > +#define __inline__ i...

Hello all! I find that using lldb to debug LLVM libraries can be super frustrating, because a lot of LLVM classes, like the constructor for StringRef, are marked LLVM_ATTRIBUTE_ALWAYS_INLINE. So when I attempt to have lldb evaluate an expression that implicitly instantiates a StringRef, I get 'error: Couldn't lookup symbols: __ZN4llvm9StringRefC1EPKc'. As an example, most recently this happened to me when playing around with llvm::AttributeSet, having attached lldb to an o...

...e xsave_cntxt_size with ebx. Signed-off-by: Wei Gang <gang.wei@intel.com> diff -r dc902ffeed73 xen/include/asm-x86/processor.h --- a/xen/include/asm-x86/processor.h Thu Mar 10 18:37:40 2011 +0000 +++ b/xen/include/asm-x86/processor.h Wed Mar 16 02:30:49 2011 +0800 @@ -223,7 +223,7 @@ static always_inline void detect_ht(stru * resulting in stale register contents being returned. */ #define cpuid(_op,_eax,_ebx,_ecx,_edx) \ - asm ( "cpuid" \ + asm volatile ( "cpuid" \ : "=a" (*(int *)(_eax))...

Hello again! I took a stab at PR4898[1]. The attached patch improves Clang's __builtin_constant_p support so that the Linux kernel is happy. With this improvement, Clang can determine if __builtin_constant_p is true or false after inlining. As an example: static __attribute__((always_inline)) int foo(int x) { if (__builtin_constant_p(x)) return 1; return 0; } static __attribute__((always_inline)) int mux() { if (__builtin_constant_p(37)) return 927; return 0; } int bar(int a) { if (a) return foo(42); else return mux(); } Now outputs this code at -O1: bar: .cfi_startproc # %bb.0:...

...rmation is not preserved in llvm IR. This means, the llvm IR generated by llvm-gcc does not contain enough information to independently reproduce llvm code generator behaviors using stand alone tools like llc. The Inliner The GCC compiler supports inliner specific attributes, e.g. noinline, always_inline. These attributes instruct the inliner to take special actions for the function that specifies them. This information is not properly encoded in LLVM IR, which means the llvm inliner is not informed about such special requests, for example always_inline. Today, llvm-gcc respects GCC’s noinlin...

...n Fri, Jan 11, 2019 at 11:18 AM Davide Italiano via llvm-dev < llvm-dev at lists.llvm.org> wrote: > After yet another round of discussions, the plan is that of trying not > to slap another attribute on the members, instead going for making > OPTIMIZED_TLBGEN the default and removing always_inline. > I'll do some testing locally (for the Ninja and the Xcode build > generator). Pawel volunteered to take a look at the Visual Studio > situation. > I assume this is going to be the final plan we'll deploy unless > somebody comes with any fundamental objections or there are...

...Gesiak via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > > Hello all! > > > > I find that using lldb to debug LLVM libraries can be super > > frustrating, because a lot of LLVM classes, like the constructor for > > StringRef, are marked LLVM_ATTRIBUTE_ALWAYS_INLINE. So when I attempt > > to have lldb evaluate an expression that implicitly instantiates a > > StringRef, I get 'error: Couldn't lookup symbols: > > __ZN4llvm9StringRefC1EPKc'. > > > > As an example, most recently this happened to me when playing around >...

...l definition errors + * of extern inline functions at link time. + * A lot of inline functions can cause havoc with function tracing. */ #if !defined(CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING) || \ !defined(CONFIG_OPTIMIZE_INLINING) || (__GNUC__ < 4) -#define inline inline __attribute__((always_inline,unused)) notrace -#define __inline__ __inline__ __attribute__((always_inline,unused)) notrace -#define __inline __inline __attribute__((always_inline,unused)) notrace +#define inline \ + inline __attribute__((always_inline, unused)) notrace __gnu_inline #else -/* A lot of inline functions can caus...

...l definition errors + * of extern inline functions at link time. + * A lot of inline functions can cause havoc with function tracing. */ #if !defined(CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING) || \ !defined(CONFIG_OPTIMIZE_INLINING) || (__GNUC__ < 4) -#define inline inline __attribute__((always_inline,unused)) notrace -#define __inline__ __inline__ __attribute__((always_inline,unused)) notrace -#define __inline __inline __attribute__((always_inline,unused)) notrace +#define inline \ + inline __attribute__((always_inline, unused)) notrace __gnu_inline #else -/* A lot of inline functions can caus...

...l definition errors + * of extern inline functions at link time. + * A lot of inline functions can cause havoc with function tracing. */ #if !defined(CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING) || \ !defined(CONFIG_OPTIMIZE_INLINING) || (__GNUC__ < 4) -#define inline inline __attribute__((always_inline,unused)) notrace -#define __inline__ __inline__ __attribute__((always_inline,unused)) notrace -#define __inline __inline __attribute__((always_inline,unused)) notrace +#define inline \ + inline __attribute__((always_inline, unused)) notrace __gnu_inline #else -/* A lot of inline functions can caus...

...l definition errors + * of extern inline functions at link time. + * A lot of inline functions can cause havoc with function tracing. */ #if !defined(CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING) || \ !defined(CONFIG_OPTIMIZE_INLINING) || (__GNUC__ < 4) -#define inline inline __attribute__((always_inline,unused)) notrace -#define __inline__ __inline__ __attribute__((always_inline,unused)) notrace -#define __inline __inline __attribute__((always_inline,unused)) notrace +#define inline \ + inline __attribute__((always_inline, unused)) notrace __gnu_inline #else -/* A lot of inline functions can caus...