similar to: -O1 with clang and gcc

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:

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

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"

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

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

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

On 2 December 2013 20:12, Philip Reames <listmail at philipreames.com> wrote: > Would it make sense to separate our a flag for preserving full and exactly > stack traces? Using -O1 is one option, but it would be nice to move beyond > -O1 with reasonable confidence that stack traces would be preserved. Would > others be interested in such a feature? I can't say I'm

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

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 >

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

(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

I'd support disabling tail merging of calls at -O1. The other CFG simplification doesn't seem like that big of a deal though for general debugging, though. On Tue, Nov 26, 2013 at 3:57 AM, Evgeniy Stepanov <eugeni.stepanov at gmail.com > wrote: > Hi, > > there are optimizations, mostly dealing with hoisting/merging common > code including function calls, that breaks

On 27 November 2013 19:36, Robinson, Paul <Paul_Robinson at playstation.sony.com> wrote: > That's correct, -g must not affect code generation. This is a > fundamental mantra among debug-info people. I think you both got me on the wrong side, though I admit my email wasn't clear. I didn't mean to suggest changing codegen for debug purposes only, but on -O1 to be less

> AFAIU, it's not OK for -g to affect code generation. I agree with the > rest of your plan. That's correct, -g must not affect code generation. This is a fundamental mantra among debug-info people. > > > On Wed, Nov 27, 2013 at 2:16 PM, Renato Golin <renato.golin at linaro.org> > wrote: > > On 27 November 2013 08:43, Evgeniy Stepanov >

When I worked on the HPE NonStop compilers for x86 (we used Open64, not LLVM), we adjusted our -O1 to make sure the source display didn't "bounce around" based on feedback from users. We disabled any optimization that would move things across statement boundaries. We also disabled/de-tuned dead store since our DWARF location list support was pretty basic and with the removed store,

Hi, I would like to run the -O1 pass sequence followed by -reg2mem from an out of tree project which uses llvm. I am using the following code snippet to do so but in some cases, my method is also vectorising the code, which doesn't happen when running the same sequence(-S -O1 -reg2mem) through opt. Can someone please help me find what I am missing? Thanks, Akash. *

> > > > - Dead code elimination (ADCE, BDCE) > > > Regarding BDCE: The trivialized values might indeed be irrelevant to > later calculations, but might harm the debugging experience? If BDCE > only was applied at O2 and higher, that's likely not a huge loss. > Regular DCE (meaning without the bit-tracking parts) is probably fine > for O1. > > >

Hi Everyone, We caught a report for a failed self test when using Clang 5.0 and 6.0 with -DDEBUG and -O1 (i.e., a "debug build"). The code is question is located at https://github.com/weidai11/cryptopp/blob/master/cham-simd.cpp . It is the SSSE3 code path for CHAM64. Other optimizations levels are OK for Clang. GCC, ICC and MSVC are OK. The code is valgrind, Sanitizer, Coverity and

On 11/26/13 3:57 AM, Evgeniy Stepanov wrote: > 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; > } >

Renato, I'm not sure I follow. By #pragma, do you mean a C-level thing? By table of flags, some hypothetical place where the proposed "Simple|Speed|Space|Aggressive" setting lives, accessible by IR passes? Sounds like what Philip needs is a more specific PreserveStackTraces setting in the same place, that's on by default at -O1, and overridable by some find of