search for: optimizeforsize

...from UnrollThreshold, it is overridden to a smaller value if the current // function is marked as optimize-for-size, and the unroll threshold was // not user specified. unsigned Threshold = CurrentThreshold; if (!UserThreshold && Header->getParent()->hasFnAttr(Attribute::OptimizeForSize)) Threshold = OptSizeUnrollThreshold; As a result, the OptimizeForSize attribute is ignored when the pass calculating the reduced count, which is not I expected. Am i correct or i missed something? If i am correct, i am going to fix this. best regards ether ps: the code contains typo...

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

...LLVM should optimize for size even at the expense of speed. I'm still working on my proposal, but I'd like some advice on the technical parts and overall project plan. First, I would add a way to determine which parts of the code should be optimized for size. This is currently done with an OptimizeForSize attribute on functions, which is added by clang with -Os. I would add a more flexible method that determines whether a given BB should be optimized for size, depending on profiling information (if available) and -Os and other options. I could put this in ProfileInfoT, since it would interact closel...

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

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

...h the verifier pass that 'noopt' is a function attribute; Add checks in method VerifyAttributeTypes() (File lib/IR/Verifier.cpp): * NoOpt is a function-only attribute; * Assert if NoOpt is used in the same context as alwaysinline; * Assert if NoOpt is used in the same context as OptimizeForSize (needed?); * Assert if NoOpt is used in the same context as MinSize (needed?). 4) Add a LLVM test in test/Feature to verify that we correctly disassemble the new function attribute (see for example file cold.ll); 5) Teach the AsmParser how to parse the new attribute: * Add a new token for t...

...'noopt' is a function attribute; > Add checks in method VerifyAttributeTypes() (File lib/IR/Verifier.cpp): > * NoOpt is a function-only attribute; > * Assert if NoOpt is used in the same context as alwaysinline; > * Assert if NoOpt is used in the same context as OptimizeForSize > (needed?); > * Assert if NoOpt is used in the same context as MinSize (needed?). > 4) Add a LLVM test in test/Feature to verify that we correctly disassemble > the new function attribute (see for example file cold.ll); > 5) Teach the AsmParser how to parse the new attribute...

...that 'noopt' is a function attribute; > Add checks in method VerifyAttributeTypes() (File lib/IR/Verifier.cpp): > * NoOpt is a function-only attribute; > * Assert if NoOpt is used in the same context as alwaysinline; > * Assert if NoOpt is used in the same context as OptimizeForSize > (needed?); > * Assert if NoOpt is used in the same context as MinSize (needed?). > 4) Add a LLVM test in test/Feature to verify that we correctly disassemble > the new function attribute (see for example file cold.ll); > 5) Teach the AsmParser how to parse the new attribute:...

Hi, I previously made a proposal for adding a pragma for per-function optimization level control due to a number of requests from our customers (See http://comments.gmane.org/gmane.comp.compilers.clang.devel/28958 for the previous discussion), however the discussion was inconclusive. Some of my colleagues recently had the opportunity to discuss the proposal with a number of people at and