search for: codesizes

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

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

Hi, On 2017-02-01 23:20:40 -0800, Andres Freund wrote: > > Can you give a pointer to the patch so that I can assess the rough > > complexity? If it's simple enough, I'd be happy to help get it > > reviewed and in. If it's more complicated, I probably won't have the > > time to assist. > > Patch (and a prerequisite) attached. Took me a while to get

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:

Having something like this available in tree would definitely be useful. For simplicity, why don't we start with support for the second style? This is the long term useful one and would be a good starting point for getting the code in tree. Can you give a pointer to the patch so that I can assess the rough complexity? If it's simple enough, I'd be happy to help get it reviewed

Hi, On 2016-12-29 13:17:50 -0800, Philip Reames wrote: > Having something like this available in tree would definitely be > useful. Cool. > For simplicity, why don't we start with support for the second style? This > is the long term useful one and would be a good starting point for getting > the code in tree. Works for me. > Can you give a pointer to the patch so that

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

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

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

...ich is not equal with report (simple) got with make. Cmake test-suite version has no features to run custom metrics and generate other report type, right? Are these features of make-version of test-suite planned to be added? The lit test-suite runner supports arbitrary metrics, it already features codesizes for different segments, compiletime, linktime, executable hash, execution time. I designed it be easily extensible with further metrics. Not all of these metrics are understood by LNT yet so they may get lost after submission to an LNT database. We do not use GenerateReport.pl and friends in the c...

...with report (simple) got with make. Cmake test-suite version has no features to run custom metrics and generate other report type, right? > > Are these features of make-version of test-suite planned to be added? > The lit test-suite runner supports arbitrary metrics, it already features codesizes for different segments, compiletime, linktime, executable hash, execution time. I designed it be easily extensible with further metrics. Not all of these metrics are understood by LNT yet so they may get lost after submission to an LNT database. > > We do not use GenerateReport.pl and frien...

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.

> Porting the outliner on ARM is in my plans for this year (as discussed > with other ARM folks at EuroLLVM last week), to avoid duplication is > it ok for you if I work on it, David, Jessica ? Sounds good to me; an ARM target would be great! - Jessica > On Apr 26, 2018, at 2:17 AM, Yvan Roux <yvan.roux at linaro.org> wrote: > > Hi, > > On 25 April 2018 at

On Apr 12, 2020, at 2:23 PM, Eli Friedman <efriedma at quicinc.com> wrote: > > Yes, the llvm::Smart* family of locks still exist. But very few places are using them outside of MLIR; it’s more common to just use plain std::mutex. > > That said, I don’t think it’s really a good idea to use them, even if they were fixed to work as designed. It’s not composable: the boolean

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