similar to: llvm-profdata determinism

On Thu, Jun 29, 2017 at 7:03 PM Xinliang David Li <davidxl at google.com> wrote: > On Thu, Jun 29, 2017 at 6:27 PM, David Blaikie <dblaikie at gmail.com> wrote: > >> I haven't tested it, but it looks to me like llvm-profdata merge (well, >> InstrProfWriter specifically) would not have deterministic output. >> >> Certainly the textual output iterates

On Thu, Jun 29, 2017 at 7:26 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > On Thu, Jun 29, 2017 at 7:03 PM Xinliang David Li <davidxl at google.com> > wrote: > >> On Thu, Jun 29, 2017 at 6:27 PM, David Blaikie <dblaikie at gmail.com> >> wrote: >> >>> I haven't tested it, but it looks to me like llvm-profdata merge (well,

Hi, On 2020-10-01 15:29:12 -0700, Lang Hames wrote: > 24bytes / object -- Looks like I managed module ownership correctly but > leaked the ThreadSafeModule container. This should be fixed in 5044196b412f. That helped a bit, but not yet fully. Looks like it might be still reachable memory, so leakcheck isn't that helpful. Oooh. I think I see. For various reasons the symbol names we

Duncan, Justin, I'm about to submit a series of patches that add writing capabilities for sample profiles in both text and binary formats. Soon, I'll add a third format (to make it interoperable with GCC). I would like to add some profile maintenance utilities as well: merging, dumping and converting. It seems like the best place would be tools/llvm-profdata. But that means that I need

Hi, On 2020-09-30 21:31:33 -0700, Lang Hames wrote: > I've taken a first shot at hooking RTDyldObjectLinkingLayer up to the > ResourceTracker API in 7436b2ab2428. Could you let me know whether that > fixes the leak you were seeing? It did improve the situation significantly, thanks! There's still a smaller leak, unfortunately. The function comments for modules say that: /** *

Hi all， Clang use a hash table to store all its identifiers. The hash table definition is: typedef llvm::StringMap<IdentifierInfo*, llvm::BumpPtrAllocator> HashTableTy; HashTableTy HashTable; Can anyone explain the mechnism of handling the name string key collision for me? Is there a IdentifierInfo objects chain or list for variable or function with the same name? Thanks very much!

I wrote some program using DensMap like this: =============================== SmallDenseMap<Value*, StringRef, 4> OpResult; Value *VP = GEP->getPointerOperand(); OpResult[VP] = parseVariable(VP); for(User::op_iterator sId = GEP->idx_begin(), eId = GEP->idx_end(); sId != eId; ++sId) { Value *VI = *sId; if(dyn_cast<ConstantInt>(*sId)) OpResult[VI] =

This series of patches address several issues causing memory usage to grow indefinetely on a long lived process. These are not convenional leaks -- memory would have been freed when the LLVM context or/and JIT engine is destroyed -- but for as long as they aren't the memory is usage effectively ubounded. The issues were found using valgrind with '--show-reachable=yes' option: 1.

Hello, Due the trees, I can't see the forest. I understand the concept of home directories on the file server becoming a share for the user on the smb-client computer. I have a vague idea of "profiles", but I'm lost at "profdata". How does that last one fit in? Where can I read more about it? (profdata is common keyword on the search engines) Is there a document

Hi! UBSan bootstrap bot fails with error report on 5 llvm-cov and llvm-profdata lit-tests: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap/builds/4526/steps/check-llvm%20ubsan/logs/stdio Also see http://llvm.org/bugs/show_bug.cgi?id=20815. The error reports look vaild: in general it's incorrect to load uint64_t, or even structures like "RawHeader" or

This week I migrated out main server from Fedora 8 to Fedora 11. It has been a stressful time, but things are mostly working. Samba and LDAP weren't really a problem, but I've beat down the list of problems to something Samba related. (For the benefit of anyone else going this route, the biggest problem by far was iptables. Maybe we had it turned off under FC8, but I suspect

Hi all, I am working on adding PGO to LDC (LLVM D Compiler). The current implementation 1) uses LLVM's InstrProf pass to generate an instrumented executable 2) links to compiler-rt/lib/profile for the runtime functionality to write a raw profile data file 3) uses llvm-profdata to merge profile data and convert from profraw to profdata format 4) uses llvm::IndexedInstrProfReader to read-in

Hi! I'm trying to build a fast Clang for myself to use for debug builds on Clang itself, but I've been struggling for a very long time on it. Could you please help? I've been following this guide: https://llvm.org/docs/HowToBuildWithPGO.html I've quickly learned that its outdated, because the script it talks about doesn't work with the monorepo layout at all, but in any

Yes, that was it! Now that I took a closer look, the guide also states that I should use the stage2 build. Silly me. Thanks! On Tue, 3 Sep 2019 at 19:31, David Blaikie <dblaikie at gmail.com> wrote: > I /guess/ you actually want /path/to/release_build/llvm-profdata because > the profiles are generated from binaries compiled with the release build, > so it's the release build

Hi Andres, Ok -- I've added some API for this in 438db0719681: You can get the string pool from the execution session with LLVMOrcExecutionSessionGetSymbolStringPool, then clear that with LLVMOrcSymbolStringPoolClearDeadEntries. -- Lang. On Thu, Oct 1, 2020 at 5:34 PM Lang Hames <lhames at gmail.com> wrote: > Hi Andres, > > Oooh. I think I see. For various reasons the symbol

On Sat, Oct 15, 2011 at 9:49 PM, Chandler Carruth <chandlerc at google.com>wrote: > On Sat, Oct 15, 2011 at 9:20 PM, Talin <viridia at gmail.com> wrote: > >> I recently updated my version of LLVM from revision 140108 to 142082, and >> several things broke, most of which were easily fixed. However, I'm now >> getting a "pure virtual method called"

We can use the setfiles(8) command to relabel the guest filesystem, even though we don't have a policy loaded nor SELinux enabled in the appliance kernel. This also deprecates or removes the old and broken SELinux support. This patch isn't quite complete - I would like to add some tests to the new API. I'm posting here to garner early feedback. Rich.

v1 -> v2: - Add simple test of the setfiles API. - Use SELinux_relabel module in virt-v2v (instead of touch /.autorelabel). - Small fixes. Rich.

Interestingly, I also get a similar error in a different executable (my unittest): pure virtual method called terminate called without an active exception 0 tartc 0x00000001010a8265 PrintStackTrace(void*) + 53 1 tartc 0x00000001010a88cc SignalHandler(int) + 364 2 libSystem.B.dylib 0x00007fff831341ba _sigtramp + 26 3 libSystem.B.dylib 0x7261742e65637365 _sigtramp +

On Mon, Nov 16, 2020 at 6:14 PM Sean Silva <chisophugis at gmail.com> wrote: > > > On Mon, Nov 16, 2020 at 4:48 PM Mehdi AMINI <joker.eph at gmail.com> wrote: > >> >> >> On Mon, Nov 16, 2020 at 4:10 PM David Blaikie <dblaikie at gmail.com> wrote: >> >>> On Mon, Nov 16, 2020 at 2:44 PM Mehdi AMINI <joker.eph at gmail.com> wrote: