similar to: RelWithDebInfo vs Release optimization level?

> On Apr 7, 2017, at 4:45 PM, Matthias Braun via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I think the idea is to keep NDEBUG out of headers when possible. So I think this should better be something like: > > -#ifndef NDEBUG > void dumpUses(unsigned RegNo) const; > -#endif > > to be inline with various other dumpers (like MachineInstr::dump(),

> On Apr 10, 2017, at 12:37 PM, Matthias Braun <mbraun at apple.com> wrote: > > The situation is not consistent. Yes there are several places where we have the #if in the headers however there are far more cases where it is not. Some points here: > > - This whole LLVM_DUMP_FUNCTION/LLVM_ENABLE_DUMP is about enabling the linker to strip (or not strip) the dumping function in

Hi Matthias, >Jingu: Why do you even want a configuration that has LLVM_ENABLE_DUMP but does not have asserts enabled at the same time? My colleague and I am doing custom project using clang/llvm. We have always wanted to use the IR Value's dump() to check our implementation correctly with Debug, Release and another builds. We thought the LLVM_ENABLE_DUMP is for it. If Chris fixes

Hi All, I have tried to build llvm tip as following: cmake -DCMAKE_CXX_FLAGS:STRING="-DLLVM_ENABLE_DUMP" -DCMAKE_BUILD_TYPE=RelWithDebInfo ../llvm After running 'make', I have got error messages like below. llvm/lib/CodeGen/MachineRegisterInfo.cpp:462:67: error: no ‘void llvm::MachineRegisterInfo::dumpUses(unsigned int) const’ member function declared in class

Presently several of our headers have definitions like: #if !defined(NDEBUG) || defined(LLVM_ENABLE_DUMP) void dump() const; #endif Would it make sense to modify the build system to define LLVM_ENABLE_DUMP in config.h on debug builds? Then we could wrap dump methods just based on LLVM_ENABLE_DUMP instead of two variables. -Chris > On Apr 10, 2017, at 1:34 PM, Robinson, Paul via llvm-dev

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

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

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:

I see the BackendUtil.cpp of Clang creates the TargetMachine with the optimization level based on below mentioned logic CodeGenOpt::Level OptLevel = CodeGenOpt::Default; switch (CodeGenOpts.OptimizationLevel) { default: break; case 0: OptLevel = CodeGenOpt::None; break; case 3: OptLevel = CodeGenOpt::Aggressive; break; } As per my understanding, the correspondence between

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

On 2018-04-04 22:00, Mehdi AMINI wrote: > Le mar. 3 avr. 2018 à 12:47, via llvm-dev <llvm-dev at lists.llvm.org> a > écrit : > >> All, >> A recent commit, D43040/r324557, changed the behavior of the gold >> plugin >> when compiling with LTO. The change now causes the codegen >> optimization >> level to default to CodeGenOpt::Default (i.e., -O2)

Le mar. 3 avr. 2018 à 12:47, via llvm-dev <llvm-dev at lists.llvm.org> a écrit : > All, > A recent commit, D43040/r324557, changed the behavior of the gold plugin > when compiling with LTO. The change now causes the codegen optimization > level to default to CodeGenOpt::Default (i.e., -O2) rather than use the > LTO optimization level. The argument was made that the LTO

On Thu, Apr 5, 2018 at 8:44 AM, via llvm-dev <llvm-dev at lists.llvm.org> wrote: > On 2018-04-04 22:00, Mehdi AMINI wrote: > >> Le mar. 3 avr. 2018 à 12:47, via llvm-dev <llvm-dev at lists.llvm.org> a >> écrit : >> >> All, >>> A recent commit, D43040/r324557, changed the behavior of the gold >>> plugin >>> when compiling with

Hello, I'm trying to minimize the processing time for llc -O3 by using a three step compilation process of 1. llc input.bc -stopafter=targetlibinfo -o input.mir 2. llc -run-pass={....min passes...} input.mir -o opt.mir 3. llc -startafter=machine-opt-remark-emitter -filetype=obj opt.mir -o final.obj Examining the passes produced by llc for O1,O2,O3 I compared (with XXX = {1,2,3}): llc

On Thu, Apr 2, 2020 at 11:35 AM Itaru Kitayama via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Setting LLVM_PARALLEL_LINK_JOBS > did not help a week or two weeks ago’s lld. > > But recent commits to lld might reflect the variable correctly. > FYI: the variable has nothing to do with lld itself (not commits to lld would change the behavior of this flag), as far as I know

All, A recent commit, D43040/r324557, changed the behavior of the gold plugin when compiling with LTO. The change now causes the codegen optimization level to default to CodeGenOpt::Default (i.e., -O2) rather than use the LTO optimization level. The argument was made that the LTO optimization level should control the amount of cross-module optimizations done by LTO, but it should not

> On May 17, 2016, at 1:33 AM, Shi, Steven via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hello, > Let me ask a LTO simple question again. For the llvm LTO example in the link:http://llvm.org/docs/LinkTimeOptimization.html <http://llvm.org/docs/LinkTimeOptimization.html>, I use below build commands to generate three different optimization level binary: -O0, -O1, -O2.

> If 3.9 shipped with these issues (assuming these are not false positive), it would be interesting to 1) know why the sanitizers didn’t catch it, and 2) add valgrind to the release qualification process (CC Hans). Yes, I'd be interested to see some corroboration. Note that the issue here is pretty specific: it only happens during optimized compile using Clang-3.9. This is all I did:

On Fri, Apr 6, 2018, 1:56 PM Peter Collingbourne via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Thu, Apr 5, 2018 at 8:44 AM, via llvm-dev <llvm-dev at lists.llvm.org> > wrote: > >> On 2018-04-04 22:00, Mehdi AMINI wrote: >> >>> Le mar. 3 avr. 2018 à 12:47, via llvm-dev <llvm-dev at lists.llvm.org> a >>> écrit : >>>

@Craig and @Michael After installing clang-5.0 (download from http://releases.llvm.org, does not have Flang build's slowdown mention above), 1. clang++ -O0 -Xclang -disable-O0-optnone -Xclang -disable-llvm-passes -c -emit-llvm -o a.bc LULESH.cc; opt -O3 a.bc -o b.bc; llc -O3 -filetype=obj b.bc -o b.o ; clang++ b.o -o b.out; ./b.out 20 runtime: 2.354069e+01 2. clang++ -O1 -Xclang