similar to: [RFC] AlwaysInline codegen

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, Pete, I understand InstCombine may simplify bitcast to nothing, but the order matters. AlwaysInliner happens in very early stage, and we never call it again. if InstCombine works, can we invoke it before Inliner? thanks, --lx On Mon, Jan 5, 2015 at 5:40 PM, Pete Cooper <peter_cooper at apple.com> wrote: > Hi lx, Philip > > I've seen an instcombine which helps with this

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

Hi, I'm working on a tool (KLEE) that interprets LLVM bitcode. One of the things it does is it instruments the LLVM bitcode with checks for division by zero. It does this by injecting calls to a function "klee_div_zero_check(long long divisor)" just before every division instruction (e.g. SDiv). These checks are injected by a pass that has been implemented in KLEE. This

everyone-- The OCaml bindings need help again. diff -r a8c05e69647e import/llvm.org/llvm/bindings/ocaml/llvm/llvm.ml --- a/import/llvm.org/llvm/bindings/ocaml/llvm/llvm.ml Fri Dec 25 17:35:09 2009 -0800 +++ b/import/llvm.org/llvm/bindings/ocaml/llvm/llvm.ml Sun Dec 27 11:38:15 2009 -0800 @@ -42,13 +42,18 @@ | External | Available_externally | Link_once + | Link_once_odr | Weak +

So.. I have investigated more on how a new function attribute to disable optimization on a per-function basis could be implemented. At the current state, with the lack of specific support from the pass managers I found two big problems when trying to implement a prototype implementation of the new attribute. Here are the problems found: 1) It is not safe to disable some transform passes in the

Hi, I previously made a proposal for adding a pragma for per-function optimization level control due to a number of requests from our customers (See http://comments.gmane.org/gmane.comp.compilers.clang.devel/28958 for the previous discussion), however the discussion was inconclusive. Some of my colleagues recently had the opportunity to discuss the proposal with a number of people at and

Dropping opt level should not lead to ABI changes. Otherwise you won't be able to mix-match O2 and O0 objects either. David On Mon, Jun 17, 2013 at 10:59 AM, jahanian <fjahanian at apple.com> wrote: > Wouldn’t implementing this proposal be a red herring? By this I mean, it is > possible that > throughout the optimization phases, there is an implied assumption that all >

Andrea_DiBiagio at sn.scee.net wrote: > Hi, > > I previously made a proposal for adding a pragma for per-function > optimization level control due to a number of requests from our customers > (See http://comments.gmane.org/gmane.comp.compilers.clang.devel/28958 for > the previous discussion), however the discussion was inconclusive. Some > of my colleagues recently had the

On Jun 17, 2013, at 11:57 AM, Xinliang David Li <xinliangli at gmail.com> wrote: > Dropping opt level should not lead to ABI changes. Otherwise you won't > be able to mix-match O2 and O0 objects either. I was referring to “static functions”. Not that it happens, but something to consider. - Fariborz > > David > > On Mon, Jun 17, 2013 at 10:59 AM, jahanian

This email is just to summarize a bit of digging I did last night into our attribute inference.  Unfortunately, I'm not going to have time to implement any of the gaps I noticed, but I figured someone else out there might be interested. *Missing Attributes* argmemonly - influences AA, particularly relevant for libraries which wrap build in functions which are annotated, but don't

Wouldn’t implementing this proposal be a red herring? By this I mean, it is possible that throughout the optimization phases, there is an implied assumption that all functions are similarly optimized. An example would be under certain optimization flag, compiler changes calling convention of static functions. - Fariborz On Jun 17, 2013, at 8:58 AM, Andrea_DiBiagio at sn.scee.net wrote: >

Hello all, I have a question related to noduplicate attribute. For example, if I have the following source code: __attribute__((noduplicate)) __attribute__((always_inline)) void wait () { // some code barrier(); // some code } __attribute__((noduplicate)) void barrier (); void f () { // some code wait(); // some code } Sometimes I observed a phenomenon that

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

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

Thank you so much David! After thinking a bit more I agree with you that attempting to add 'target-features' to my functions seem to be the safest approach of all. I noticed that if I mark the clang++ function as 'AlwaysInline', the inlining is performed normally. Is this a potential bug, given what you said that LLVM may accidentally move code using advanced cpu features outside

This sounds right to me. If there is no objection, I will implement a patch to enforce this in langref and IR verifier. -----Original Message----- From: Friedman, Eli [mailto:efriedma at codeaurora.org] Sent: Tuesday, September 25, 2018 3:07 PM To: Pan, Wei <wei.pan at intel.com>; Reid Kleckner <rnk at google.com> Cc: llvm-dev <llvm-dev at lists.llvm.org> Subject: Re:

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

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