similar to: [LLVMdev] [GSoC] Optimizing for size

hi, In "LoopUnrollPass.cpp", when trying to reduce unroll count to meet the unroll threshold requirement in line 200 and line 206, variable "CurrentThreshold" is used in the computation, instead of the variable "Threshold", which is defined by: // Determine the current unrolling threshold. While this is normally set // from UnrollThreshold, it is overridden to

Hi, On 01/23/2013 11:30 PM, Jakob Stoklund Olesen wrote: > If you can find the place that creates the duplicate MBB edge, that would be great. > Found it :) It happens in lib/CodeGen/IfConversion.cpp at the very end in MergeBlocks. I attached a small patch that should resolve that issue. Our tests now compile sucessfully even without my previous patch. regards, Stefan --------------

On Jan 23, 2013, at 12:36 PM, Stefan Hepp <stefan at stefant.org> wrote: > However, an alternative option could be to simply disallow different edge weights for edges with the same source and destination, or to make the call to getEdgeFreq(Pred,BB) in BlockFrequencyImpl distinguish between the edges, which would eliminate the need for an additional PtrSet, but is not that easy to

Could we move this setting to function attributes? We already have OptimizeForSize / MinSize there, but not the other opt levels. We also have OptimizeNone, which seems to be completely unused. This would let us support __attribute__((optimize())) in the future, which is currently ignored. Another example would be an LTO link of objects compiled with different optimization settings. I'm not

We are developing a new backend for a custom processor using LLVM. After updating to LLVM 3.2, we run into an assertion in BlockFrequencyImpl.h. The offending test-case looks basically like this: for ( ... ) { switch (i) { case 100: // do something break; case 102: // do something else break; case 103: // do some more break; case 104: // now something different

So i have a testcase (see PR31792, and cond_br2.llin GVN) that current GVN can simplify because it replaces instructions as it goes. It's an example of a larger issue that pops up quite a lot I would appreciate thoughts on what to do about it it amounts to something like this (but again, it happens a lot): live = gep thing, 0 live2 = gep thing, 1 branch i1 provablytrue,, mergeblock, otherbb

Andrea_DiBiagio at sn.scee.net wrote: > So.. > I have investigated more on how a new function attribute to disable > optimization on a per-function basis could be implemented. > At the current state, with the lack of specific support from the pass > managers I found two big problems when trying to implement a prototype > implementation of the new attribute. > > Here are the

Good evening, Kenneth. Thank you to apply (and rewrite my naive code better) and to file the issue to http://llvm.org/bugs/show_bug.cgi?id=7304 I have checked r105528 at this morning. I think the pass must be still cleaned up and rewritten. There are my two proposals for enhancement. 1) To separate Specialization(and rewriting callsites) to other module. It would be better if new module were

On Fri, Mar 3, 2017 at 12:39 PM, Friedman, Eli <efriedma at codeaurora.org> wrote: On 3/3/2017 11:51 AM, Daniel Berlin via llvm-dev wrote: So i have a testcase (see PR31792, and cond_br2.llin GVN) that current GVN can simplify because it replaces instructions as it goes. It's an example of a larger issue that pops up quite a lot I would appreciate thoughts on what to do about it it

On Thu, Jul 18, 2013 at 8:23 AM, <Andrea_DiBiagio at sn.scee.net> wrote: > So.. > I have investigated more on how a new function attribute to disable > optimization on a per-function basis could be implemented. > At the current state, with the lack of specific support from the pass > managers I found two big problems when trying to implement a prototype > implementation of

So.. I have investigated more on how a new function attribute to disable optimization on a per-function basis could be implemented. At the current state, with the lack of specific support from the pass managers I found two big problems when trying to implement a prototype implementation of the new attribute. Here are the problems found: 1) It is not safe to disable some transform passes in the

Hello, As the title line says, I'm getting assertions on recursive JIT compiation, like this: opt: JIT.cpp:627: void llvm::JIT::runJITOnFunctionUnlocked(llvm::Function*, const llvm::MutexGuard&): Assertion `!isAlreadyCodeGenerating && "Error: Recursive compilation detected!"' failed. 0 libLLVM-2.7.so 0x012eb2c8 Stack dump: 0. Program arguments: opt

Hi, Looking at bugzilla PR11087, I'd like to conditionalise a transformation in ARMIselLowering.cpp based on whether we're compiling for codesize or performance. -Os doesn't actually exist for llc, and I can't see an obvious place where that condition would be set. Where do we specify if we're optimizing for codesize or performance? Cheers, James --------------

On 28 November 2013 13:31, David Tweed <david.tweed at gmail.com> wrote: > Indeed, a most of the bugs which > really need a debugger are manifest in big applications where even a > non-debug build can be very "not simple".) My example was a very crude example of simplicity. But the more complex your application is, the simpler you want the compiler to be for a debug

On Thu, Nov 28, 2013 at 1:11 PM, Renato Golin <renato.golin at linaro.org>wrote: > On 28 November 2013 00:00, Robinson, Paul > <Paul_Robinson at playstation.sony.com> wrote: > > In my experience, to a first approximation, anything > > that changes the CFG or that reorders generated code beyond source > > statement boundaries is likely to make things more

Hi, For a certain type of analysis I generate inline assembly which I insert into the LLVM IR code. This inline assembly code contains labels that should not be duplicated. Problem is that the tail duplication pass duplicates code. It checks isNotDuplicatable on a machine instruction however there is no such a flag on an IR instruction that I could set. Is there a way to tell in an IR pass that

Hi, I am trying to test if disabling function (entry) alignment has any effect on performance. On my x86 machine, all functions seem to get aligned to 16-bytes. I know that GCC provides a flag (-fno-align-functions) to disable function alignment. However, I could not find the similar flag for clang. According to the following quote from LLVM doc, clang delegates the job to the target in case no

Hello, In my reading over the last couple of days, I have read that in order for klee to work with "native" Linux programs, I need to install the uClibc posix support for klee. I am not finding the uClibc source in the llvm svn repository anywhere. Is this still necessary for testing native Linux applications, and if so, where do I get the uClibc source to compile? Thanks in

I'm getting unexpected results from the coxph function when using weights from counter-matching. For example, the following code produces a parameter estimate of -1.59 where I expect 0.63: d2 = structure(list(x = c(1, 0, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 1, 0, 0, 1, 0, 1, 0, 1, 0, 1), wt = c(5, 42, 40, 4, 43, 4, 42, 4, 44, 5, 38, 4, 39, 4, 4, 37, 40, 4, 44, 5, 45, 5, 44, 5), riskset =

I have an R function (about 1000 lines long) that takes more than 20 times as long to run under R Windows 1.9.0 and 1.8.1 than it does under 1.7.1. Profile results indicate that the $<-.data.frame operation is the culprit, but I don't understand exactly what that is (assignment of data frame elements to another variable?), or why it's only a problem under 1.8.1 and 1.9.0. Any advice?