similar to: [LLVMdev] recreate optimized clang output

On Jan 24, 2011, at 10:36 AM, Hendrix_ at gmx.net wrote: > I was using "clang -O3 -S -emit-llvm" got some very optimized output. > > Then I did "clang -S -emit-llvm" (without optimization) and wanted to optimized the code in a > separate pass. The llvm program "opt" did not do anything. > > How can I invoke the optimizer on some un-optimized

On 26.01.2011, at 04:39, John McCall wrote: > On Jan 24, 2011, at 10:36 AM, Hendrix_ at gmx.net wrote: >> I was using "clang -O3 -S -emit-llvm" got some very optimized output. >> >> Then I did "clang -S -emit-llvm" (without optimization) and wanted to optimized the code in a >> separate pass. The llvm program "opt" did not do anything.

On Jan 27, 2011, at 12:02 PM, Hendrix_ at gmx.net wrote: > OK, I am looking for "LTO"/global optimization. So the function definition will remain "somewhere else" (externally), and the optimizer will find in some other module to possibly inline it later on. > > I am planning to concat all the *.ll (eg "link" the files) and pass them to the

On 27.01.2011, at 21:12, Devang Patel wrote: > > On Jan 27, 2011, at 12:02 PM, Hendrix_ at gmx.net wrote: > >> OK, I am looking for "LTO"/global optimization. So the function definition will remain "somewhere else" (externally), and the optimizer will find in some other module to possibly inline it later on. >> >> I am planning to concat all the

On Jan 27, 2011, at 12:37 PM, Hendrix_ at gmx.net wrote: > > On 27.01.2011, at 21:12, Devang Patel wrote: > >> >> On Jan 27, 2011, at 12:02 PM, Hendrix_ at gmx.net wrote: >> >>> OK, I am looking for "LTO"/global optimization. So the function definition will remain "somewhere else" (externally), and the optimizer will find in some other

On 27.01.2011, at 21:12, Devang Patel wrote: > > On Jan 27, 2011, at 12:02 PM, Hendrix_ at gmx.net wrote: > >> OK, I am looking for "LTO"/global optimization. So the function definition will remain "somewhere else" (externally), and the optimizer will find in some other module to possibly inline it later on. >> >> I am planning to concat all the

While we're talking about this, I'd just mention again that the same issue arises for *normal* functions too, when linked into a shared library: int foo() { return 1; } int bar() { return foo(); } Now, compare: clang -fPIC -O1 -S -o - test.c gcc -fPIC -O1 -S -o - test.c GCC will refuse to inline foo into bar, or use any information about foo in compiling bar, because foo is

Hi all, This is something that came up in the "RFC: Add guard intrinsics to LLVM" thread; and while I'm not exactly blocked on this, figuring out a path forward here will be helpful in deciding if we can use the available_externally linkage type to expression certain semantic properties guard intrinsics will have. Let's start with an example that shows that we have a problem

Couple of other problematic transforms: # undef refinement After thinking about this a bit, I think undef refinement happens a lot more often than I initially thought, and it happens implicitly. Consider the following case: void @foo(int* ptr) available_externally { int k = *ptr; if (k == 1 && k == 2) print("X"); } void main() { int* ptr = malloc();

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 Mon, Feb 22, 2016 at 11:18 PM, Chandler Carruth <chandlerc at gmail.com> wrote: >> # step A: Introduce an `interposable` function attribute >> >> We can bike shed on the name and the exact specification, but the >> general idea is that you cannot do IPA / IPO over callsites calling >> `interposable` functions without inlining them. This attribute will

> On Feb 24, 2016, at 9:41 PM, Chandler Carruth via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Wed, Feb 24, 2016 at 9:35 PM Hal Finkel <hfinkel at anl.gov <mailto:hfinkel at anl.gov>> wrote: > ----- Original Message ----- > > > From: "Chandler Carruth via llvm-dev" <llvm-dev at lists.llvm.org <mailto:llvm-dev at

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

Hal Finkel wrote: > That summary needs unnecessarily broad. So far we've learned that: a) There are issues with atomics b) there are issues > with a safe-to-speculate attribute we don't yet have c) there might be issues with folding undefs independent of the > previous two items, but we thus-far lack a concrete example. We don't yet have enough information. I don't

Couple of other examples: void @foo(i32* %ptr) available_externally { %discard = load i32, i32* %ptr } void bar() { call @foo(i32* %x) } ==> void @foo(i32* %ptr) available_externally { } void bar() { call @foo(i32* %x) } ==> void @foo(i32* %ptr) available_externally { } void bar() { call @foo(i32* undef) ;; non optimized @foo will crash } ;;

Hi Sanjoy, These are both very interesting examples, and demonstrate that the problems extends beyond function attributes (encompassing dead-argument elimination, etc.). I'm beginning to think that the best solution, at least when optimizing for speed, is the one that David Li suggested: we need to internalize functions that have been optimized in certain ways (e.g. instructions with

Dear Sirs, I have a problem with the garchOxFit output. I want to display only the value of max.like.est and the information criteria. How can I do that; I enclose a part of GarchOxFit output, which is what I want to display. Best regards, Vasilios Ismyrlis GarchOxFit output No. Observations : 1000 No. Parameters : 2 Mean (Y) : -0.05511 Variance (Y) : 1.06869

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

----- Original Message ----- > From: "Mehdi Amini" <mehdi.amini at apple.com> > To: "Chandler Carruth" <chandlerc at google.com> > Cc: "Hal Finkel" <hfinkel at anl.gov>, "llvm-dev" > <llvm-dev at lists.llvm.org> > Sent: Thursday, February 25, 2016 12:02:16 AM > Subject: Re: [llvm-dev] Possible soundness issue with

----- Original Message ----- > From: "Chandler Carruth via llvm-dev" <llvm-dev at lists.llvm.org> > To: "Philip Reames" <listmail at philipreames.com>, "Duncan P. N. Exon > Smith" <dexonsmith at apple.com>, "Sanjoy Das" > <sanjoy at playingwithpointers.com> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org>