similar to: [LLVMdev] Adding function attributes

Hi Duncan, thanks for the quick answer. Yes I'm sure the runOnModule is being called, and when I dump the functions before exiting the method I can see the AlwaysInline attribute. I'll check InlineAlways.cpp and will reimplement as last resource but I still wonder why this is not working. On Mon, Nov 5, 2012 at 5:03 PM, Duncan Sands <baldrick at free.fr> wrote: > Hi Arnaldo,

Hi Arnaldo, > I am coding a ModulePass in which I want to add an AlwaysInline attribute to > every function so that they can be later inlined by the -always-inline pass. why not just do the inlining yourself. The always inliner code is at lib/Transforms/IPO/InlineAlways.cpp, and it's pretty short. > However, the changes to the function seem to be lost after exiting my pass >

Hi Arnaldo, On 05/11/12 10:02, Arnaldo wrote: > Hi Duncan, thanks for the quick answer. > > Yes I'm sure the runOnModule is being called, and when I dump the functions > before exiting the method I can see the AlwaysInline attribute. > > I'll check InlineAlways.cpp and will reimplement as last resource but I still > wonder why this is not working. if you want more

Below is a stripped down version of the pass. The compile line is: clang -O0 -S -emit-llvm -o test.S test.c && opt -S -mem2reg -load <path to extract lib> -extract < test.S > test_opt.S #include "llvm/Analysis/DependenceAnalysis.h" #include "llvm/Analysis/LoopInfo.h" #include "llvm/Analysis/LoopPass.h" #include

I have the following code: static inline void foo() __attribute((always_inline)); int a; static inline void foo() { a++; } int main(int argc, char *argv[]) { foo(); return 0; } However, the code generated by llvm 2.4 toolchain does not inline this function. opt retains the function call. Here is the output when I try to compile with -debug-only=inline:

Hi, I am instrumenting the stores in a program by inserting a function call (store_prologue) before every store instruction in the IR file. I set the prologue function's attribute to "AlwaysInline" using addFnAttr(). In the program the prologue function is defined as static inline. I am using opt to generate an optimized (inline the calls to the store prologue) using the

Thanks for your message. However, even with using version 2.5 of llvm the function is not inlined. Can you try this with your llvm with the same opt flags, which are as follows? -O3 -debug-only=inline -mem2reg If it does work for you, can you tell me the exact flags you used for clang or llvm-gcc to produce the .bc file and the exact flags you specified when you invoked opt? Does the inlining

If I understand correctly, you're saying that the C source definition of the prologue function is declared as static. If you compile that function to LLVM IR, it will get interal linkage and will not be visible to functions in other compilation units; instead, it will get renamed if there is a function defined with the same name. As such, it will never get inlined as the instrumented code

On Sep 16, 2009, at 6:55 PM, madiyaan wrote: > > I have the following code: > > static inline void foo() __attribute((always_inline)); > > int a; > static inline void foo() > { > a++; > } > > int main(int argc, char *argv[]) > { > foo(); > return 0; > } This works fine in current sources. You should upgrade; 2.5 has been out for a while and

Hi, I'm trying to inline function defined in another bitcode module via bitcode modification. I'm linking multiple bitcode modules, setting inline related attributes, applying -always-inline pass, but then debug info error occurs. It seems debug info metadata isn't properly updated on inlining. How can I fix it? I'm using LLVM 3.8.1 on OS X (On below example target is Android but

Every inlinable call in a function that has debug info (F->getSubprogram() returns non-null) must have a DebugLoc associated with it that has a scope chain that ends in that same DISubprogram. https://llvm.org/docs/SourceLevelDebugging.html discusses some of the debug info IR metadata in LLVM. On Fri, Feb 2, 2018 at 1:03 AM Ku Nanashi via llvm-dev < llvm-dev at lists.llvm.org> wrote:

> Every inlinable call in a function that has debug info (F->getSubprogram() returns non-null) must have a DebugLoc associated with it that has a scope chain that ends in that same DISubprogram. Thank you for the comment! I don't know if this is a proper way to fix, but after I add DebugLoc same as inserting position instruction, no error occurs.

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

Hello all, I have a custom allocator, and would like to teach LLVM about its semantics. In particular, I would like LLVM to kill allocations that are "dead", similar to dead new in C++. Consider this example: ; ModuleID = '<stdin>' source_filename = "Module" ; Function Attrs: inaccessiblememonly noinline norecurse nounwind declare i8* @alloc(i64)

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

On 01/08/2010 02:10 PM, John McCall wrote: > 'llc' is an IR-to-assembly compiler; at -O3 it does some pretty neat > machine-code and object-file optimizations, but it does not apply > high-level optimizations like CSE or inlining. 'opt' is the tool > which does IR-to-IR optimization. A vital clue, but I'm still not getting it: --- gemini:~/Projects/Nil/nil(0)$

On Tue, Nov 20, 2012 at 11:03 AM, Meador Inge <meadori at codesourcery.com> wrote: > > On Nov 13, 2012, at 12:20 AM, Bill Wendling wrote: > >> IR Changes >> ---------- >> >> The attributes will be specified within the IR. This allows us to generate code >> that the user wants. This also has the advantage that it will no longer be >> necessary to

Consider this program: @globalSideEffect = global i32 0 define void @tobeinlined() #0 { entry: store i32 3, i32* @globalSideEffect, align 4 musttail call fastcc void @tailcallee(i32 3) ret void } define fastcc void @tailcallee(i32 %i) { entry: call void @tobeinlined() ret void } attributes #0 = { alwaysinline } Clearly, if this is processed with opt -alwaysinline, it will lead

Dustin Laurence wrote: > On 01/08/2010 02:10 PM, John McCall wrote: > > >> 'llc' is an IR-to-assembly compiler; at -O3 it does some pretty neat >> machine-code and object-file optimizations, but it does not apply >> high-level optimizations like CSE or inlining. 'opt' is the tool >> which does IR-to-IR optimization. >> > > A

Hi all, When using "make check" with the DejaGNU test collection, I encounter two unexpected failures (they seem to be closely related). My question: are they well known, and if so what's the problem and how can I fix it? This is the error text I get: FAIL: /var/data/common/trunk/llvm/test/FrontendC/2008-05-19-AlwaysInline.c Failed with exit(1) at line 1 while running: