search for: o1s

Hello, I encounter a bug that pumped during execution of "clang -O1". However the bug cannot be reproduced by using "clang -O0 + opt -O1". It seems that "clang -O1" is not the same as "clang -O0 + opt -O1". According to the generated LLVM IRs are large, I would like to use bugpoint with "clang -O1" directly instead of using "clang -O0"

Dear R community, I do know, that an R function is constructing a copy of any object passed as argument into a function. I program on a larger S4 project for a package, and I arrived at a point where I have to think a little harder on implementation style (especially to spare users complex object handling). I have a function foo(), taking as input arguments two S4 objects of different class

Dear R useRs, i try to compute the posterior mean for the parameters omega and beta for the following posterior density. I have simulated data where i know that the true values of omega=12 and beta=0.01. With the function postMeanOmega and postMeanBeta i wanted to compute the mean values of omega and beta by numerical integration, but instead of omega=12 and beta=0.01 i get omega=11.49574 and

Hi Mayur, > On 24 Nov 2014, at 07:00, MAYUR PANDEY <mayur.p at samsung.com> wrote: > In the assembly generated with O0, we are getting the "blx" instruction whereas with O1 we get "bx" (in 3.4.2 we used to get "blx" for both O0 and O1). > > Is this because of this patch: [llvm] r214959 - ARM: do not generate BLX instructions on Cortex-M CPUs

The parts of klibc specific to the sparc architecture. Signed-off-by: H. Peter Anvin <hpa at zytor.com> --- commit 1b5c93603ed3460ed1fba9e5d453a6fa54d0ccce tree 7fb0a134b3add408c02b470616d440ad398d86d3 parent 94473ed85b00ec45ff8ee6cac62f60a368ff4534 author H. Peter Anvin <hpa at zytor.com> Sun, 25 Jun 2006 16:58:47 -0700 committer H. Peter Anvin <hpa at zytor.com> Sun, 25 Jun

Hello all, I've found an old post (November 2016) http://lists.llvm.org/pipermail/llvm-dev/2016-November/107006.html which discussed debug information for optimized code. At the end of that discussion, Adrian broached the interest in making -O1 only enable optimizations. I see in the code ( *clang/lib/Frontend/CompilerInvocation.cpp*, in function *getOptimizationLevel*) that *-Og* option is

> -----Original Message----- > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Mehdi > Amini via llvm-dev > Sent: Friday, January 06, 2017 11:10 AM > To: Sumanth Gundapaneni > Cc: LLVM Developers > Subject: Re: [llvm-dev] LLVMTargetMachine with optimization level passed > from clang. > > > > On Jan 6, 2017, at 10:56 AM, Sumanth

Here is a problem scenario. I want to enable a backend pass at -O2 or above. if (TM->getOptLevel() >= CodeGenOpt::Default) addPass(&xxxxx); This pass will be run at -O1 too since clang is creating the TargetMachine with CodeGenOpt::Default for -O1. --Sumanth G -----Original Message----- From: mehdi.amini at apple.com [mailto:mehdi.amini at apple.com] Sent: Friday, January 6, 2017

Hi I am seeing an issue (compiled application seg faults) when llc is used at -O1. I first need to triage out which optimization/pass is responsible for the seg fault. As such I am following this strategy: disable gradually those passes at -O1 which do not exist at -O0. For this I used -pass-debug=Structure. [ diff pasted at the end for reference] The problem is I have used almost all -disable-*

Hi, The binary gotten via clang's `-O1` runs much slower (3x) than that gotten via GCC's `-O1`. Reproducible with: https://github.com/m-chaturvedi/test_valgrind_slowdown We are seeing this difference between gcc and clang at other places as well. The `-O0` and `-O2` times are comparable, however. Are there some compile time flags one could add to make the `-O1` times comparable?

On 20 November 2012 15:10, Anitha B Gollamudi <anitha.boyapati at gmail.com> wrote: > Hi > > I am seeing an issue (compiled application seg faults) when llc is > used at -O1. I first need to triage out which optimization/pass is > responsible for the seg fault. As such I am following this strategy: > disable gradually those passes at -O1 which do not exist at -O0. For >

(Remembering to +llvm-dev this time…) There has been some progress in the direction of improving debuggability of optimized code, in the past year. There have been a number of patches to improve tracking of debug info in various passes, and some more general improvements such as work on the LiveDebugValues pass. I don't think anyone has done a specific analysis to identify passes that lose

Hello, I m trying to test individual O3 optimizations/ replicating O3 behavior on IR. I took unoptimized IR (O0), used disable-o0-optnone via (*clang -O0 -Xclang -disable-O0-optnone*). I read somewhere about *clang -O1 -Xclang -disable-O0-optnone,* so I also tested on this initial IR. I have observed by using individual optimizations, the performance (i.e time) is better when the base/initial

Since we are in the area, what *should* O1 do? It's basically good for nothing, since it doesn't tune for size or performance. The only good I personally ever have for it is once in a while there is a miscompile at -O1 which narrows the problem. Would it be crazy to make -O1 equivalent to -Os? - Daniel On Wednesday, September 16, 2009, Chris Lattner <clattner at apple.com>

Hi, there are optimizations, mostly dealing with hoisting/merging common code including function calls, that breaks stack trace symbolization in a very bad way. int f(int x) { if (x == 1) report("a"); else if (x == 2) report("b"); return 0; } For example, in the above function (at -O1) both calls to report() are done from the same PC. As a result, stack trace

Thanks for the quick reply. `-O0` is too slow with Valgrind and `-O2` is not recommended. We use `-O1` in Valgrind runs. > Use of -O2 and above is not recommended as Memcheck occasionally reports uninitialised-value errors which don't really exist. http://valgrind.org/docs/manual/quick-start.html On Thu, May 31, 2018 at 5:34 PM, Michael Kruse <llvmdev at meinersbur.de> wrote:

I want the optimization to be turned on at -O1 and above. In my case, it is a target independent back-end pass. (Eg: MachinePipeliner) On 2017-01-04 18:10, Mehdi Amini wrote: >> On Jan 4, 2017, at 4:03 PM, Sumanth Gundapaneni via llvm-dev >> <llvm-dev at lists.llvm.org> wrote: >> >> I see the BackendUtil.cpp of Clang creates the TargetMachine with >> the

My experience is that just running mem2reg (while disabling virtually all other passes ) in O1 will substantially improve debuggability while giving acceptable performance. On Mon, Jan 29, 2018 at 11:39 AM, via llvm-dev <llvm-dev at lists.llvm.org> wrote: > (Remembering to +llvm-dev this time…) > > > > There has been some progress in the direction of improving debuggability

getOptLevel() gets the level from TargetMachine which is created by the Backendutil in clang with either "Default", "None" or "Aggressive". Threre is no correspondence for "Less". This boils down to , if I pass "-O1", the Target Machine is created with CodeGenOpt::Default. I am available on IRC @ sgundapa. -----Original Message----- From:

What are you trying to achieve? If faster runs is the goal, why not compile with -O2? Michael 2018-05-31 16:27 GMT-05:00 M. Chaturvedi via llvm-dev <llvm-dev at lists.llvm.org>: > Hi, > > The binary gotten via clang's `-O1` runs much slower (3x) than that gotten > via GCC's `-O1`. > > Reproducible with: > >