similar to: [LLVMdev] Optimization for size

On Mon, Oct 17, 2011 at 7:58 AM, James Molloy <james.molloy at arm.com> wrote: > 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

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 all, It’s been two weeks since I sent the last merge progress email, so here is an update. TL;DR: Almost done! Tim is considering suggesting making the final switchover sometime next week. This would be the final push, where AArch64 gets deleted and ARM64 gets renamed to AArch64, and would signal the end of the merge process. If any of you know of any reason why these two loving

Hello A 4.4% geomean codesize improvement is really impressive. That stuff is hard to come by, you usually have to nibble away at it bit at a time. I ran some codesize benchmarks we have and they were in the same ballpark. Some of these are quite small so had less opportunity for outlining, but the average was still over 3% with some as high as 9-10%. All the tests I ran were fine, although we

Hi, On 25 April 2018 at 14:02, David Green via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Hello > > A 4.4% geomean codesize improvement is really impressive. That stuff is hard to come by, you usually have to nibble away at it bit at a time. I ran some codesize benchmarks we have and they were in the same ballpark. Some of these are quite small so had less opportunity for

Zachary, Thanks for the help on IRC earlier. I've got code that can capture a stack trace and then discover for each address, its module, function, source index, line, and column. I still have a couple of loose ends though. Do you know what's going on here? 1. There appears to be 8 bytes before every LineFragmentHeader. Here's some of my own debug output, which matches

For the first and third questions, the easiest thing to do would be run llvm-pdbutil under a debugger and step through the code. Code that looks simple and innocuous can often have a lot of stuff hidden behind it. For example you could step through that loop that iterates the debug subsections and look at the value of Reader.getOffset() every time, and see if it matches with your own code

Hi, Sanjay/all, I noticed in rL331486 that some compare-select optimizations are disabled in favor of providing canonicalized cmp+select to the backend. I am currently working on a private backend target, and the target has a small code size limit. With this change, some of the apps went over the codesize limit. As an example, C code: b = (a > -1) ? 4 : 5; ll code: Before rL331486:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chris Lattner wrote: > Finally, there is still a lot that can be done to reduce code size. For > example, building a JIT links in the .s file printers in, and they have > non-trivial size (big string tables etc). It would be great to refactor > the code to avoid things like this. I wouldn't be surprised if we could > shrink the

Hello, Matthijs > There is some code in llvm-config which fixes the library problem for the > TargetNameAsmPrinter library, but that isn't really the clean way IMHO. Is > this also meant for cleanup, or is there another reason why the AsmPrinter > should be in a seperate library? The main reason of such split was codesize concerns for JIT users: they don't need asmprinting at

On Mon, Feb 16, 2015 at 12:06:07PM -0800, syslinux-bot for Gene Cumm wrote: > Commit-ID: 9d33f23c9bbb0f308ca6dab3fca16a128247e283 > Gitweb: http://www.syslinux.org/commit/9d33f23c9bbb0f308ca6dab3fca16a128247e283 > Author: Gene Cumm <gene.cumm at gmail.com> > AuthorDate: Mon, 16 Feb 2015 14:27:35 -0500 > Committer: Gene Cumm <gene.cumm at gmail.com> >

On 17 October 2011 15:58, James Molloy <james.molloy at arm.com> wrote: > -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? The pass manager builder has an option for Os (0, 1, 2). But all it does, AFAICR, is to disable one explosive optimization pass.

You can use CallInst::hasFnAttr(). It checks for attributes in the instruction and in the function decl. http://llvm.org/docs/doxygen/html/Instructions_8cpp_source.html#l00345 Nuno ----- Original Message ----- > Hi, > > Building the following C code I get a call instruction that has no > noreturn > attribute, while the function itself does have it. > > void foo(void **b)

On Wed, Oct 15, 2008 at 11:09 PM, Mike Stump <mrs at apple.com> wrote: > On Oct 15, 2008, at 10:11 PM, Chris Lattner wrote: >> Eli, I don't disagree with you on any specific detail here. I think >> there are decent solutions to this if anyone cares enough. My only >> point is that this is an existing problem with other compilers. On >> darwin, for example, x

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

Hi, Building the following C code I get a call instruction that has no noreturn attribute, while the function itself does have it. void foo(void **b) { __builtin_longjmp(b, 1); } define void @_Z3fooPPv(i8** %b) noreturn nounwind uwtable { entry: %0 = bitcast i8** %b to i8* tail call void @llvm.eh.sjlj.longjmp(i8* %0)

Hi Seb, The ARM instruction set is a fixed-width 32-bit instruction set that has been around since the early days of ARM. Modern (armv4t onwards) cores mostly have another instruction set that can be used in tandem, the "thumb" instruction set. This is a variable width (16 or 32 bit) instruction set that provides a subset of the ARM instruction set and was intended to provide the

Hi everyone, The code layout that TailMerging (inside BranchFolding) works on is not the final layout optimized based on the branch probability. Generally, after BlockPlacement, many new merging opportunities emerge. I did an experiment of adding additional BranchFolding and BlockPlacement after the existing BlockPlacement (i.e., -block-placement -branch-folder -block-placement) targeting

I linked the wrong patch review. Here's the patch that was actually committed: https://reviews.llvm.org/D48508 https://reviews.llvm.org/rL335433 On Tue, Jul 3, 2018 at 4:39 PM, Sanjay Patel <spatel at rotateright.com> wrote: > [adding back llvm-dev and cc'ing Craig] > > I think you are asking if we are missing a fold (or your target is missing > enabling another hook)

> On May 25, 2016, at 1:54 AM, Elena Lepilkina via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi Matthias, > > Thank you for your answer. > But can you answer for some more questions? > First of all, now LNT uses make-style of running tests and parse results from result csv file. Are there any plans to go to cmake? As James already said "lnt runtest