similar to: Clang executable sizes and build stats

I'm sure the x86 scheduler models are causing bloat. Every time a single instruction appears on a line by itself like this in a scheduler model: def: InstRW<[SBWriteResGroup2], (instregex "ANDNPDrr")>; It causes that instruction to be its own group in the generated output. And its replicated for each CPU. We should look into better using regular expressions or taking

Thanks for raising this. This is something we've recently been looking at too at Sony, as over the course of PS4's lifetime so far we've seen our clang executable on Windows approximately double in size, which isn't ideal for things like distributed build systems. A graph of clang.exe size on our internal staging branch matches yours closely with it being more of a death by a

> On Mar 17, 2018, at 4:04 PM, Craig Topper via cfe-dev <cfe-dev at lists.llvm.org> wrote: > > I'm sure the x86 scheduler models are causing bloat. Every time a single instruction appears on a line by itself like this in a scheduler model: > > def: InstRW<[SBWriteResGroup2], (instregex "ANDNPDrr")>; > > It causes that instruction to be its own

I just knocked ~400k off the size of the x86 scheduler tables by reducing from 5k+ entries to 2k+ entries per cpu. ~Craig On Tue, Mar 20, 2018 at 6:34 PM, Andrew Trick <atrick at apple.com> wrote: > > > On Mar 17, 2018, at 4:04 PM, Craig Topper via cfe-dev < > cfe-dev at lists.llvm.org> wrote: > > I'm sure the x86 scheduler models are causing bloat. Every time

+Yundi Qian <yundi at google.com> +Eugene Brevdo <ebrevdo at google.com> , our team members from the ML side. To avoid formatting issues, here is a link to the RFC <https://docs.google.com/document/d/1BoSGQlmgAh-yUZMn4sCDoWuY6KWed2tV58P4_472mDE/edit?usp=sharing>, open to comments. Thanks! On Wed, Apr 8, 2020 at 2:34 PM Mircea Trofin <mtrofin at google.com> wrote: >

It turns out it's me, sorry. Let me see how I can sort this out. In the meantime, here is the csv: SPEC2006 data: binary,base -Oz size,ML -Oz size,ML size shrink by,,perf: base -Oz scores,perf: ML -Oz scores,ML improvement by 400.perlbench,2054200,2086776,-1.59%,,2.9,2.9,0.00% 401.bzip2,1129976,1095544,3.05%,,6.4,6.2,-3.13% 403.gcc,4078488,4130840,-1.28%,,11.6,11.7,0.86%

Sorry, I wasn't aware of that. I can make the google doc view-only, keeping the current comments. I'll wait a bit (few hrs) to see if there's any pushback to that. On Thu, Apr 9, 2020 at 9:57 AM Xinliang David Li <xinliangli at gmail.com> wrote: > One suggestion : should we consolidate the discussion into the main > thread? I know some folks are not willing to comment in

> Reading the bitcode reader while working on another issues I found > that we already have a version in the bitcode itself (not the darwin > wrapper) and it is used! It is stored with the > bitc::MODULE_CODE_VERSION. It is used to select relative ids, which > impacts the entire bitcode, and so it makes sense to be based on a > version. > > If we ever have a new feature

Hello LLVM, Does the community have bots or humans tracking code size for -Os builds? I've noticed troubling regressions lately. Sometime near Nov 5, the EEMBC bitmnp01 benchmark grew by 25% for ARMv7m and 35% for i586. That's ghastly. This week, the EEMBC matrix01 workload grew by 5% for ARMv7m and 3% for i586. Regards, -steve

i want to integrate a C source JITer into my application but the resulting executables are too large is it possible to reduce the resulting libs/exe some way? current VS2017/svn build example: llvm-build\Release\bin\clang-interpreter.exe ~36MB for now (that can change later) - i want to jit simple c-code - no std library or something - x64 only - no deep/full architecture optimization needed -

On Thu, Nov 19, 2015 at 1:10 PM, Renato Golin <renato.golin at linaro.org> wrote: > On 19 November 2015 at 19:08, Steve King via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> Does the community have bots or humans tracking code size for -Os >> builds? > > Hi Steve, > > I still haven't got around doing a CI for EEMBC or SPEC on ARM. I do > track

On Mon, Nov 24, 2014 at 7:53 AM, Rafael Espíndola < rafael.espindola at gmail.com> wrote: > > Right, that version number is used to resolve *ambiguities* in how to > > interpret some chunk of bitcode. It is not a generic bitcode version > > scheme, because most bitcode format changes involve things like adding > > new operands or opcodes, which are easily identified

I need a way to convert files that I save with Firefox as a 'print to file' to 'pdf' I tried 'convert' but that rendered the text as graphics which grew the file and wasn't what I wanted. How would someone accomplish this - or can I just print to a PDF? Craig

TL;DR; We can improve compiler optimizations driven by heuristics by replacing those heuristics with machine-learned policies (ML models). Policies are trained offline and ship as part of the compiler. Determinism is maintained because models are fixed when the compiler is operating in production. Fine-tuning or regressions may be handled by incorporating the interesting cases in the ML training

Hello, I worked on a code size analysis tool for a 'week of code' project and think that it might be useful enough to upstream. The tool is inspired by bloaty (https://github.com/google/bloaty), but tries to do more to attribute code size in actionable ways. For example, it can calculate how many bytes inlined instances of a function added to a binary. In its diff mode, it can show how

> On Oct 1, 2018, at 3:16 PM, David Blaikie <dblaikie at gmail.com> wrote: > > (my vote, somewhat biased - is that I'd love to see more investment in Bloaty (to keep all these sort of size analysis tools and tricks in one place), but sort of accept folks are probably going to keep building more infrastructure for this sort of thing in LLVM directly) I get where that comes

> On Oct 1, 2018, at 3:25 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > On Mon, Oct 1, 2018 at 3:24 PM JF Bastien <jfbastien at apple.com <mailto:jfbastien at apple.com>> wrote: >> On Oct 1, 2018, at 3:16 PM, David Blaikie <dblaikie at gmail.com <mailto:dblaikie at gmail.com>> wrote: >> >> (my vote, somewhat biased - is that

I have tried various mail clients to read the Rails mailing list for the past 12 months. As the list volume grew, it became utterly impossible to browse through the new messages and very hard to locate the useful gems I had previously found. After subscribing to a few more lists, I realized that there had to be a better way. I could not find anything to meet my needs, so I designed

Over time, the Wine wiki front page grew rather unwieldy, so I split the developer information off into two new pages, leaving only a simplified front page behind, mostly aimed at users. It's radically simpler. Hopefully it'll be more welcoming to new users. Comments?

On 01/15, Nicolai Hähnle via cfe-dev wrote: > On Tue, Jan 14, 2020 at 11:41 AM Renato Golin <rengolin at gmail.com> wrote: > > We rarely approve some patches and not others in a series, and when we > > do, we ask people to create a new series without the approved patch, > > or split them, so that we can continue reviewing the series. > > This has simply not been