similar to: Tool to help hunt down binary size regressions

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

> 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

Hi all, I think we've reached a state where we're ready to enable debug entry value production by default for the x86_64, ARM, and AArch64 targets. For context, this is a debug info feature that allows debuggers to recover the value of unmodified optimized-out parameters by 'going up' a stack frame and interpreting spilled values, constants, etc. to work out what was passed to the

Yep, TAG_call_site_parameter and its children shouldn't require any extra relocations. Thanks! vedant > On Feb 7, 2020, at 2:01 PM, David Blaikie <dblaikie at gmail.com> wrote: > > For that sort of small growth, if it doesn't add more relocations (I think the call sites need them (but they're already emitted/that's not what we're discussing enabling here), but

The actual DWARF emission for call site parameters is gated inside of DwarfDebug::constructCallSiteEntryDIEs by `tuneForGDB() || tuneForLLDB()`. However, we are creating+updating CallSiteInfo (basically, in-memory only bookkeeping used by the backend to keep track of call sites) even when the debugger tuning is set to the Sony debugger. If this creates problems, feel free to file a bug and

Hi, Thanks you all for the collaboration! :) Paul, > This is not how tuning-controlled features are supposed to work. I will comment on the review. I see, I am working on addressing the comments from the [1]. I will update the diff asap. Thanks. Vedant, There are no entry values generated at -O0 level, but I will add a test case for it. Thanks. Best regards, Djordje On 8.2.20. 02:41,

This buildbot seems to have been failing for a while (though it's hard for me to identify the root cause in the logs, as I mentioned in another thread, so it's hard to say if it's the same failure, or if the failure is consistent, etc) - anyone watching it/caring aobut it? ---------- Forwarded message ---------- From: <llvm.buildmaster at lab.llvm.org> Date: Wed, Sep 30, 2015 at

Vedant, Thanks for building the packages before. Could you detail what's required to build these binaries on macOS so that someone else could replicate it? Thanks, Tobias On Mon, Oct 14, 2019 at 8:29 PM Vedant Kumar via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi Gio, > > I prepared the macOS packages for the past few releases, but have less time to keep up with

Should the binaries included in an LLVM release be generally useful to a wide audience of toolchain users, or is it OK to ship tools that are only really useful for LLVM development? If the former is the case, can we consider not shipping tools which are exclusively for testing the compiler? E.g removing these 5 binaries from 5.0.2-rc1 would have saved over a hundred megabytes in uncompressed

> On Sep 22, 2017, at 11:36 AM, Vedant Kumar <vsk at apple.com> wrote: > > Ah, the problem goes away once I build clang-func-mapping. > > I stripped some stuff out, but here's pretty much what clang/test/lit.cfg.py says my PATH is: > > ** PATH **: /Volumes/Builds/llvm.org-coverage-braces-RA/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin > > I wonder how

Hi, I'd like to announce a new code coverage bot: http://lab.llvm.org:8080/coverage/coverage-reports/clang/index.html The purpose of the bot is to make high-quality coverage reports available to llvm developers, and to provide additional testing for clang's code coverage implementation. The coverage data clang generates allows the reporting tool to render execution counts for code

> On Mar 16, 2018, at 2:30 PM, Son Tuan VU <sontuan.vu119 at gmail.com> wrote: > > Hi Vedant, > > Thank you for your reply. I think I can make this debugify-each mode, but I guess this is reserved for your GSoC project ? No, there's no reserved work. If you'd like to work on this I encourage you to do so. There's plenty of other work slated for the GSoC project.

Mhm I see now, thanks for your explanation! Son Tuan Vu On Fri, Mar 16, 2018 at 10:58 PM, Vedant Kumar <vsk at apple.com> wrote: > > On Mar 16, 2018, at 2:30 PM, Son Tuan VU <sontuan.vu119 at gmail.com> wrote: > > Hi Vedant, > > Thank you for your reply. I think I can make this debugify-each mode, but > I guess this is reserved for your GSoC project ? > >

Hi vedant, The program didn't pass the checking "OF->getArch() != Triple(Arch).getArch()" loadBinaryFormat in CoverageMappingReader.cpp and returned an error. It's because "OF->getArch()" returned null and "Triple(Arch).getArch()" returned XXXX(name of my arch). The returned value of " OF->getArch()" is decided by "

Hi vedant, 1. First, I think your theory is right that llvm’s object file reading libraries do not “understand” the architecture I’m working on. Since I’m using binutils as assembler which means llvm can only provide asm and object file is provided by biutils. I think these ELF header information is provided by my binutils now, so maybe I have to modify binutils code to provide ELF header

Hi Vedant, Thank you for your reply. I think I can make this debugify-each mode, but I guess this is reserved for your GSoC project ? However, if I understand correctly, we do not want to take the output of the first check-debugify (I mean the .ll file with potentially all the WARNINGs and ERRORs after the first pass) as input for the second debugify. What we need is to take the fresh output of

What Vedant said -- the profiler runtime provides buffer API for profile dumping. Note that value profiling dumping is not yet supported for buffer API, but since you are using Front-end based instrumentation/profile-use, value profiler is not turned on by default anyway. David On Tue, Dec 19, 2017 at 5:29 PM, Vedant Kumar <vsk at apple.com> wrote: > > On Dec 19, 2017, at 5:16 PM,

> On Dec 18, 2016, at 3:48 AM, Dmitry Golovin <dima at golovin.in> wrote: > > > > 16.12.2016, 18:23, "Vedant Kumar" <vsk at apple.com>: >>> On Dec 16, 2016, at 7:06 AM, Dmitry Golovin via llvm-dev <llvm-dev at lists.llvm.org> wrote: >>> >>> I want to build LLVM-based toolchain with Musl, I have LLVM sources with clang and

Hi vedant, 1. The definition is from llvm/Supprot/ELF.h. But this machine information(e_machine) is given to compiler at lib/MC/ELFObjectWriter.cpp. I greped the whole llvm project and found that e_machine was assigned at only two files. One was lib/MC/ELFObjectWriter.cpp(there was an comment said “e_machine=target”) and the other was tools/obj2yaml/elf2yaml.cpp(GDB stopped only at the