search for: leb128s

On Mon, Jul 10, 2017 at 4:13 PM, Rui Ueyama via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Sorry for the belated response. I was on vacation last week. A couple of > thoughts on this patch and the story of webassembly linking. And I'm about to be on (mostly) vacation for next 3 weeks :) > > - This patch adds a wasm support as yet another major architecture besides >

Dan Gohman <sunfish at mozilla.com> writes: >> Sorry, I meant why that didn't work with ELF (or what else didn't). >> > > The standard executable WebAssembly format does not use ELF, for numerous > reasons, most visibly that ELF is designed for sparse decoding -- headers > contain offsets to arbitrary points in the file, while WebAssembly's format > is

Introduction ============ This RFC proposes a mechanism to dump arbitrary messages into object files during compilation and retrieve them from the final executable. Background ========== We often need to collect information from all object files of applications. For example: - Mircea Trofin needs to collect information from the function inlining pass so that he can train the machine

Hi All, We have a local change in the X86AsmPrinter that outputs a section containing metadata on function stack sizes. We use this to measure changes to stack size between versions of the compiler and it also allows our licensees to do the same for their code. The section simply contains pairs of function symbol references (8 byte) and stack sizes (unsigned LEB128). We would like to

I think that we should think about the relationship between this proposed mechanism and the existing mechanism that we have for emitting and capturing optimization remarks. In some sense, I feel like we already have a lot of this capability (e.g., llc has -remarks-section).  -Hal On 8/5/20 5:51 PM, Johannes Doerfert via llvm-dev wrote: > I like the ability, not sure about the proposed

Changing a header file somewhere and having to spend 10 minutes waiting for a build leads to a lot of wasted developer time. The real culprit here is tablegen. Can we split support and ADT into two - the parts that tablegen depends on and the parts that it doesn't? >From what I can gather, Tablegen currently depends on these headers and all of their transitive dependencies. #include

On Wed, Aug 5, 2020 at 3:51 PM Eli Friedman <efriedma at quicinc.com> wrote: > I’m not a fan of keeping important data outside the IR in an analysis. If > we’re planning to emit it, it should be represented directly in the IR. Is > there some reason we can’t just stick the data in a global variable? > The analysis in the scenarios here is external to LLVM - ML training, for

On Mon, May 29, 2017 at 9:25 AM Zachary Turner via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Sun, May 28, 2017 at 8:54 PM Mehdi AMINI via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> 2017-05-26 17:47 GMT-07:00 Zachary Turner via llvm-dev < >> llvm-dev at lists.llvm.org>: >> >>> Changing a header file somewhere and having to

...tion of the format of the profile > data file. > > The Clang user guide here describes it as an ASCII text file: > http://clang.llvm.org/docs/UsersManual.html#sample-profile-format > > Whereas the posts above and the referenced link describe it as a stream of > bytes containing LEB128s: > http://www.llvm.org/docs/CoverageMappingFormat.html > > From experimenting with the latest trunk I can see the latter is correct > (well, at least the file I get is not ASCII text). > Should we update the Clang user guide documentation? > Or am I just getting confused? Are ther...

2017-05-29 9:25 GMT-07:00 Zachary Turner <zturner at google.com>: > On Sun, May 28, 2017 at 8:54 PM Mehdi AMINI via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> 2017-05-26 17:47 GMT-07:00 Zachary Turner via llvm-dev < >> llvm-dev at lists.llvm.org>: >> >>> Changing a header file somewhere and having to spend 10 minutes waiting

2017-05-26 17:47 GMT-07:00 Zachary Turner via llvm-dev < llvm-dev at lists.llvm.org>: > Changing a header file somewhere and having to spend 10 minutes waiting > for a build leads to a lot of wasted developer time. > > The real culprit here is tablegen. Can we split support and ADT into two > - the parts that tablegen depends on and the parts that it doesn't? >

...bit confused about the documentation of the format of the profile data file. The Clang user guide here describes it as an ASCII text file: http://clang.llvm.org/docs/UsersManual.html#sample-profile-format Whereas the posts above and the referenced link describe it as a stream of bytes containing LEB128s: http://www.llvm.org/docs/CoverageMappingFormat.html >From experimenting with the latest trunk I can see the latter is correct (well, at least the file I get is not ASCII text). Should we update the Clang user guide documentation? Or am I just getting confused? Are there two formats, one used f...

It would be better, because a debug tablegen is slower than an optimized tablegen, but it's still slow and it doesn't address the problem that tablegen runs *at all* when it doesn't really need to. I think if tablegen wasn't running all the time we could incremental builds down from 15 minutes (and that's on my really powerful machine) to under 5, which seemed like a big

I thought we already did write tablegen output to temporary files like X86GenAsmWriter1.inc.tmp first and then diffed them with the real .inc file and conditionally copied. ~Craig On Sat, May 27, 2017 at 11:02 AM, David Blaikie via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On Fri, May 26, 2017 at 8:06 PM Zachary Turner via llvm-dev < > llvm-dev at

...gt; data file. > > > > The Clang user guide here describes it as an ASCII text file: > > http://clang.llvm.org/docs/UsersManual.html#sample-profile-format > > > > Whereas the posts above and the referenced link describe it as a stream > of > > bytes containing LEB128s: > > http://www.llvm.org/docs/CoverageMappingFormat.html > > > > From experimenting with the latest trunk I can see the latter is correct > > (well, at least the file I get is not ASCII text). > > Should we update the Clang user guide documentation? > > Or am I j...

It's that TableGen depends on Support, so if you change one file in support, support gets recompiled into a new static archive, which triggers a rerun of tablegen on all the tablegen inputs, which is extremely slow. On Fri, May 26, 2017 at 5:56 PM Hal Finkel <hfinkel at anl.gov> wrote: > > > On 05/26/2017 07:47 PM, Zachary Turner via llvm-dev wrote: > > Changing a header

In my experience the buildsystem works fine in combination with tablegen (at least this aspect of it). The real problem here is that tablegen is just slow. Some of the X86 tables take indeed Last time I looked at it tablegen had still room to optimize the way it resolves class hierarchies and the variables within which it did basically one at a time, so it needed to traverse the hierarchies

...> > The Clang user guide here describes it as an ASCII text file: > > http://clang.llvm.org/docs/UsersManual.html#sample-profile-format > > > > Whereas the posts above and the referenced link describe it as a stream > of > > bytes containing LEB128s: > > http://www.llvm.org/docs/CoverageMappingFormat.html > > > > From experimenting with the latest trunk I can see the latter is correct > > (well, at least the file I get is not ASCII text). > > Should we update the Clang user guide documentation?...

On 04/29/2013 15:53, Keith Walker wrote: > It sounds like you are trying to load the DWARF sections into target memory .... and if so I guess I would have to ask you why as they are not normally loaded into target memory? You are right, debug sections aren't normally loaded into the memory together with the sections needed for running. However, I am mostly focusing on the (lightweight)

Hi Folks, I am building LLVM 3.9.1 using the Yocto build system for a cross build. The compiled bins/libs work totally fine on the target machine however there seems to be an intermittent race condition during the build which causes a build failure. On the failed builds I usually see things being linking/compiling twice e.g. Linking CXX static library ../libLLVMSupport.a cd