similar to: Proposal for O1/Og Optimization and Code Generation Pipeline

Awesome start. Back when I did a similar project at HP/NonStop, the class of optimizations we turned off for our O1 (Og equivalent) tended to be those that reordered code or otherwise messed with the CFG. In fact one of our metrics was: - The set of breakpoint locations available at Og should be the same as those available at O0. This is pretty easy to measure. It can mean either turning

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

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'm not sure which passes exactly drop debug info, but it's likely that most of them do. If you're interested in working on this problem, I suggest experimenting with the debugify utility in opt. This tool can be used to identify passes which drop debug info and to generate targeted/reduced test cases for specific problems. To use it, you can add the '-enable-debugify'

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

Hello Paul, François and Vedant, Thank you all for your answers. And sorry for this late reply. I wanted to dig more into the LLVM source code to get a better understanding of the debug part of it before replying/asking more questions. I have came across this https://llvm.org/docs/SourceLevelDebugging.html#debugging-optimized-code which stated that "*Basically, the debug information allows

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

Hi Mark, It is not clear to me at all that preventing the merging is the right solution. There are a large number of analysis, including alias analysis, and optimizations that use GetUnderlyingObject, and related routines to search back through GEPs. They only do this up to some small finite depth (six, IIRC). So reducing the GEP depth is likely the right solution for InstCombine (which has the

(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 think it would make sense for (1) and (2). I am not sure if (3) is feasible in instcombine. (I am not too familiar with LoopInfo) For the Octasic's Opus platform, I modified shouldMergeGEPs in our fork to: if (GEP.hasAllZeroIndices() && !Src.hasAllZeroIndices() && !Src.hasOneUse()) return false; return Src.hasAllConstantIndices(); // was return false;

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

Hi Eric & Orlando, It’s great to see interest in a lot of different aspects of debug info. At the same time, I’m concerned about a risk to making the topic so broad that we don’t have time to get through all the things people want to get through. I’m thinking there’s a different way to slice the topics, hopefully without much overlap, but that will allow a bit more focus. No doubt a lot of

Hi, I'm trying to autotune a good sequence of IR optimization passes and I seem to run into segfaults in opt (in LLVM5) with certain pass orderings. Is this expected behavior? If so, what would be the recommended way of determining pass dependencies so that I can encode them into the tuner? The test program can be found here: https://gist.github.com/kavon/92d153cdd54ce9b77162af3af47d4c95

Hi all, I haven't seen a proposal for an optimised-code debugging experience Round Table yet so here goes! Please let me know if you are interested by emailing me at: orlando.hyams at sony.com Below is a non-exhaustive list of possible topics. Feel free to include any preferences and suggestions in your response. a. Line tables: 1. Can we fix is_stmt? 2. Is prologue_end

Hi everyone, We're doing some compile-time instrumentation according to the following scheme: llvm-gcc -O1 -g $in -emit-llvm -S -o $name.ll opt -O2 -load Instr.so $INSTR_FLAGS $name.ll -S -o $name-inst.ll llc $name-inst.ll -o $name.S g++ -c $name.S However it turns out that the code instrumented this way is missing frame pointers (e.g. backtrace() and/or libunwind cannot unwind

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 Jan 7, 2018 8:46 PM, "toddy wang" <wenwangtoddy at gmail.com> wrote: @Sean, here is my summary of several tools. Format: (ID,tool, input->output, timing, customization, questions) 1. llc, 1 bc -> 1 obj, back-end compile-time (code generation and machine-dependent optimizations), Difficult to customize pipeline, N/A 2. LLD: all bc files and obj files -> 1 binary

Hi James, We've indeed passed the appropriate (and even excessive) flags to the appropriate pipeline parts, that is: llvm-gcc -O1 -fno-omit-frame-pointers -g $in -emit-llvm -S -o $name.ll llc --disable-fp-elim $name.ll -o $name.S g++ -fno-omit-frame-pointers -c $name.S , but that didn't work Alex On Tue, Apr 5, 2011 at 4:40 PM, James Molloy <James.Molloy at arm.com> wrote:

No, I meant LLD, the LLVM linker. This option for LLD is relevant for exploring different pass pipelines for link time optimization. It is essentially equivalent to the -passes flag for 'opt'. Such a flag doesn't make much sense for 'llc' because llc mostly runs backend passes, which are much more difficult to construct custom pipelines for (backend passes are often required

@Sean, here is my summary of several tools. Format: (ID,tool, input->output, timing, customization, questions) 1. llc, 1 bc -> 1 obj, back-end compile-time (code generation and machine-dependent optimizations), Difficult to customize pipeline, N/A 2. LLD: all bc files and obj files -> 1 binary (passing -flto to clang for *.bc file generation), back-end link-time optimizations and