similar to: [IDF][analyzer] Generalizing IDFCalculator to be used for Clang's CFG

A polite ping, could someone please share a thought about this? On Sat, 8 Jun 2019 at 21:21, Kristóf Umann <dkszelethus at gmail.com> wrote: > A polite ping on this matter :) > > On Tue, 4 Jun 2019 at 01:51, Kristóf Umann <dkszelethus at gmail.com> wrote: > >> Hi! >> >> As the title suggests, I'd like to generalize llvm::IDFCalculator to be >>

Hi Jakub! On Mon, 17 Jun 2019 at 17:01, Jakub (Kuba) Kuderski <kubakuderski at gmail.com> wrote: > Hi Kristóf, > > >> 1. I read the article IDFCalculator is based on[1], but I found no >> references to IDFCalculator::setLiveInBlocks, and the file header seems to >> confirm that it's an implementation specific thing. Could I get away >> restricting the

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

It seems to be down again for me, anyone experiencing the same? https://bugs.llvm.org/show_bug.cgi?id=18159 On Tue, 23 Jun 2020 at 14:54, Aaron Ballman via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Tue, Jun 23, 2020 at 8:28 AM Xing GUO via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > > > Hi folks, > > > > It seems that bugzilla is

On Mon, Apr 4, 2016 at 11:49 AM, David Callahan <dcallahan at fb.com> wrote: > > I may have not correctly used the IDFCalculator. I passed in the > PostDominator tree and then changed the loop over successor blocks to also > be able to iterate over predecessors. I did not see anything in the > interface that would let that happen but perhaps I don’t understand the API > so

Hi Jakub, On Tue, Jul 7, 2020 at 6:25 AM Jakub (Kuba) Kuderski <kubakuderski at gmail.com> wrote: > There's a lot of heavily templated code in generic DomTee construction/updater, MemSSA updater, and GraphDiff that has become really hard to modify. For the context, Alina (cc'd) was recently looking into making the domtree code work with 'CFG views'; the basic idea is to

Hi all, This is a request for comment on a series of patches which introduce a new way of writing algorithms that are generic over different types of CFG. What is this? ============= This series of patches introduces a set of classes and templates for: 1. Working on basic blocks and values generically, in particular with the same algorithm implementation on both LLVM IR and MachineIR (in SSA

Some question: 1. IDFCalculator already allows reverse graphs, and gets used for that, so what did you have to change? (this change was made in the past year, so i wonder if you were working on a branch or something). 2. What are the actual numbers here in terms of calculation of IDF vs your method. IDF calculator is linear time (Well, depends on priority queue impl, but we could fix that

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

Hi, As part of an ongoing work to extend the GraphDiff (this models a CFG view), I came across the need to have a common interface for accessing successors/predecessors in various IR units, such that a type such as `typename NodeT::succ_iterator` could be used in templated code. In particular, the need arose for BasicBlocks, MachineBasicBlocks, VPBlockBase and clang::CFGBlock. The least invasive

Hi Dave, It may be possible to do this with the current API, but what I was looking for is a common API for existing block types. For example there is no succ_begin for Machine BasicBlock. I'm looking to make the CFGSuccessors and CFGPredecessors classes in CFGDiff.h templated, and this needs a common API for all types instantiations. Does this clarify your question or did I misunderstand

Now that FLAC has officionally joined the Xiph family, there are three different free audio codecs, which can be stored/transported using the ogg container. Would it be possible to create an API and/or a library that would cover them all? If my understanding of the situation is correct, if an application wants to support vorbis, speex and flac, it has to use three different interfaces.

Now that FLAC has officionally joined the Xiph family, there are three different free audio codecs, which can be stored/transported using the ogg container. Would it be possible to create an API and/or a library that would cover them all? If my understanding of the situation is correct, if an application wants to support vorbis, speex and flac, it has to use three different interfaces.

Now that FLAC has officionally joined the Xiph family, there are three different free audio codecs, which can be stored/transported using the ogg container. Would it be possible to create an API and/or a library that would cover them all? If my understanding of the situation is correct, if an application wants to support vorbis, speex and flac, it has to use three different interfaces.

Hi, I have read your message about building a VirtualGL server in a xen domU at http://www.mail-archive.com/virtualgl-users@lists.sourceforge.net/msg00088.html . I plan to do exactly the same. Could you please share some of your experience? What HW have you chosen? Have you succeeded? According to the information at http://wiki.xensource.com/xenwiki/XenVGAPassthroughTestedAdapters ,

Hi all, I would like to get my system to work with IOMMU. (The long-term goal is VGA passthru.) System is as follows: CPU: Core 2 Duo E6600 MB: Foxconn G9657MA-8EKRS2H (w. latest bios: 631F1P61) Virtualization support is enabled in BIOS. (These is only one option.) Hypervisor: xen 4.0.0 from Debian, AMD64 Xen config: iommu=verbose output of xen dmesg is attached. HVM domains work (lasd tried

[please cc the answers to me, because I'm not on this list!] Hi there! Yesterday I downloaded the CVS version of icecast and ices. There are several example config files provided for ices in the conf/ directory. The ices-playlist.xml specifies encoding for one of the instances: <encode> <nominal-bitrate>64000</nominal-bitrate>

On Tue, Mar 10, 2020 at 2:30 PM David Blaikie <dblaikie at gmail.com> wrote: > > > On Tue, Mar 10, 2020 at 8:31 AM Alina Sbirlea <alina.sbirlea at gmail.com> > wrote: > >> Hi Dave, >> >> It may be possible to do this with the current API, but what I was >> looking for is a common API for existing block types. For example there is >> no

Hi, all: This is the basic implementation of tf-idf scheme (basic scheme used in SMART) that can be used in the Xapian. It might still need some futher revision, but I believe it works anyway.:) I modified the weight.h to define a subclass Tf_idfWeight and add a new file tf_idf.cc in ../weight in the repo, to implement Tf_idfWeight. Here is the git diff patch: https://gist.github.com/2422049

Hello guys :) I have sent a pull request for the Tf-Idf Weighting scheme incorporating as many normalizations as I could with the help of statistics currently available from Xapian::Weight . Please let me know what you'll think about it. I used the weighting scheme in a simple searcher and it did a fine job with it. I have no experience with writing tests for features like this.Please give me