search for: always_inliner

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

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)':

...> Before any optimizations can be applied the function must be converted > into LLVM IR. In LLVM IR we have no equivalent for > "builtin_constant_p". > Thus the __builtin_constant_p is evaluated and found false as part of > converting the GCC trees into LLVM IR, then the always_inliner is > applied on the IR. Supporting always_inline as a type-safe macro which is always expanded early is a feature of GCC that people have found useful. It is a limitation of LLVM that this happens to be complicated to implement there. Dan

[ please CC: me as I'm not subscribed ] On Wed, Mar 11, 2009 at 04:13:34AM +0000, bugzilla-daemon at cs.uiuc.edu wrote: > http://llvm.org/bugs/show_bug.cgi?id=3756 > > Chris Lattner <clattner at apple.com> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- >

...'s not the problem. Before any optimizations can be applied the function must be converted into LLVM IR. In LLVM IR we have no equivalent for "builtin_constant_p". Thus the __builtin_constant_p is evaluated and found false as part of converting the GCC trees into LLVM IR, then the always_inliner is applied on the IR. If this particular optimization is of great interest to you, I suggest adding this folding to the simplify-libcalls pass. It can check whether the parameter to the call is constant and apply the range tests. For __builtin_constant_p support in general, I think the trick i...

...optimizations can be applied the function must be converted >> into LLVM IR. In LLVM IR we have no equivalent for >> "builtin_constant_p". >> Thus the __builtin_constant_p is evaluated and found false as part of >> converting the GCC trees into LLVM IR, then the always_inliner is >> applied on the IR. > > Supporting always_inline as a type-safe macro which is always expanded > early is a feature of GCC that people have found useful. It is a > limitation of > LLVM that this happens to be complicated to implement there. Okay. I find it hard to cal...

On Thu, Aug 20, 2015 at 7:17 PM, John McCall <rjmccall at apple.com> wrote: > > On Aug 20, 2015, at 5:19 PM, Evgenii Stepanov via cfe-dev < > cfe-dev at lists.llvm.org> wrote: > > Hi, > > > > There is a problem with the handling of alwaysinline functions in > > Clang: they are not always inlined. AFAIK, this may only happen when > > the caller is

Hi, There is a problem with the handling 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

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

On Thu, 2018-06-07 at 11:32 -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

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 is a bug fixing. So it needs go into 4.1. x86: add volatile prefix for cpuid asm clauses cpuid results are possible to be changed now. For example, changing CR4.OSXSAVE bit or setting MSR XCR_XFEATURE_ENABLED_MASK may change XSAVE related cpuid leave return values. The volatile prefix is required to avoid the second cpuid calls following some possible changing operations being optimized in

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

Here is a proposal that I mentioned sometime ago. Any thoughts,comments or suggestions on this proposal would be appreciated. - Devang // = = =---------------------------------------------------------------------- ===// // Function Notes (or Traits) // = = =---------------------------------------------------------------------- ===// This document describes the

On 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 >

On Sat, Dec 15, 2018 at 12:02 PM Vedant Kumar via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi, > > > On Dec 15, 2018, at 10:32 AM, Brian 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

4.4-stable review patch. If anyone has any objections, please let me know. ------------------ From: Nick Desaulniers <ndesaulniers at google.com> commit d03db2bc26f0e4a6849ad649a09c9c73fccdc656 upstream. 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+

4.9-stable review patch. If anyone has any objections, please let me know. ------------------ From: Nick Desaulniers <ndesaulniers at google.com> commit d03db2bc26f0e4a6849ad649a09c9c73fccdc656 upstream. 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+

4.14-stable review patch. If anyone has any objections, please let me know. ------------------ From: Nick Desaulniers <ndesaulniers at google.com> commit d03db2bc26f0e4a6849ad649a09c9c73fccdc656 upstream. 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

4.17-stable review patch. If anyone has any objections, please let me know. ------------------ From: Nick Desaulniers <ndesaulniers at google.com> commit d03db2bc26f0e4a6849ad649a09c9c73fccdc656 upstream. 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